Path Control Disable Text Entry

[Hooovahh]

If I have a path control on my front panel for the user to interact with, I will always show the browse button.  This button makes selecting a path easy from a user perspective, and from a developer I know that the path they selected has some level of validity.  So for instance I know that the path they selected must exist and be a valid path otherwise Windows won't let them select it, and the value change won't be triggered for the control.

But the user can manually type in text into the path control, and when focus is taken off the value change event will take place.  The problem with this is the path they entered might not be valid, or may contain characters my platform doesn't support.

I doubt a user will manually type in text in the control often, they will use it as an indicator showing the path they selected using the browse button, but on the off chance that they type somthing and it isn't valid, my code might crap out throwing errors.

I can add code to check for a valid path, and I can add code to check for illegal characters in the path, but I'd have to do this for every path control on every UI the user sees.  I could also write an XControl for this with a decent amount of work and hopefully meet my needs, but it would be nice if this were a native feature.

So what I'm suggesting is that the path control have an option, possibly in the browse options dialog, which makes the interaction with the control, only available by using the Browse button.  This would ensure that any value change event will be from the user picking a valid path with the browse button.

[crossrulz]

I would also allow for the drag and drop a file/folder into the path control.  I use that feature all the time.  But I really like the idea of limiting the user from being able to type into the path control.

[Hooovahh]

Oh great point, I use drag on drop all the time too, but again here the validity of the data is some what done.  My main consern is that a user can just type "?" press enter, and then my value change is triggered, and that path will try to read a file by that name, or do some other File I/O.

Checking for valid, and exists is fine, and can revert the control back to the old value, but this just seems like such a universal thing that it could be an option.

[crossrulz]

Oh, I fully agree with you.  I did not hesitate to give the idea a kudo.  I just wanted to make sure NI knew to keep the drag and drop.  The idea that we don't want the user to just type something into the control is all we are asking to be disabled unless some sort of auto validation of the data is done.

[AristosQueue (NI)]

Easy workaround: Drop a path indicator on top of the path control. When one changes, write to the other. Now they can only use the browse button.

Personal opinion (not speaking for R&D generally here): This is one of those cases where I'm on the fence about the idea overall. Yes, I want a robust path control that supports lots of use cases well, but there is a point where the level of variation and gradiation is such that the answer really is, "Go write an XControl." I don't know if this crosses that threshold or not.

[chris_d754]

I'm not sure if I like preventing the user from typing, I know I sometimes like to type out a path depending on the situation. I am in favor of doing some preventing of illegal characters. This type of validation is already done with some other data types, e.g. numerics don't allow for non-numerals to be typed. Yes, you could still end up with an invalid path,  but at least some safety good be build in. Full-blown checking would be great as well, and possible not letting the user leave the control unless the path is valid, but this is probably better suited for an XControl as AQ suggested.

[AristosQueue (NI)]

If users hit the Browse button ON WINDOWS, then they can type into the dialog that pops up. They cannot type in on Mac... not sure about Linux. The string they type on Windows does get checked to be a valid path, so that may cover the bases for Hooovahh.

[Darren]

> Easy workaround: Drop a path indicator on top of the path control. When one changes, write to the other. Now they can only use the browse button.

I've had to implement this "easy workaround" about a dozen times over the years. And it's not so easy once you factor in resizable dialogs, font size changes on different platforms, etc. In fact, there's a LabVIEW 2015 feature where we had to do exactly what Hooovahh describes, and I have a 2016 CAR on the fact that we didn't get it quite right when you look at the UI on Mac/Linux because of the different fonts. 😛

I'd love for this to be native functionality of the path control (that I could enable/disable). Kudos.

[JW-JnJ]

Kudos and...

Crazy idea, what about giving path controls "Update Value while typing" ? More coding, but possibly better flexibility. Hear me out for a bit.

Right now you have to focus away from the path, which for me involves hitting a run button. Then I have to interrupt flow, error out, and potentially clear out a state queue. It's not smooth feedback for the user. When updating real-time, I can have the checking happen right in the event structure as the value changes. For new files, all I have to do is check for illegal characters via "Is Name Multiplatform.vi". For existing, I just have to pipe it into "Check if File or Folder Exists.vi". Those can also feed  run button enabling/disabling and even a nice check/X indicator next to the path control.

Yes, I can do this with a string control currently with even more coding to add the browse button. Tempting.

[AristosQueue (NI)]

Update Value While Typing would seem to contradict this entire request since the request is to only allow validated values for the path. If every partial path the user types in is accepted as a Value Change, I don't see how that helps solve the problem. Can you explain how one connects to the other?

(To be clear, having Update While Typing on a path is not a bad idea, I just don't see how it relates to this.)

[JW-JnJ]

You're correct. I reread and it seems my brain skipped over the fourth paragraph. His main problem was adding the code for each GUI path instance, not that the error occurs in a hard to manage way. Sorry.