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.

[AristosQueue (NI)]

No problem. If you want to add that suggestion as a new Idea, go for it. I just wanted to make sure I wasn't missing something here. 🙂

[blacknight]

I am a very new user to labview, only 2 months working with it, but have already encountered this issue on the job. I created a small vi for it and posted it up for others to use on the company's source control.

I created a small example, and didn't know how to post it directly on a comment, here's the link to where I posted it. https://decibel.ni.com/content/docs/DOC-43498.

This essentially approaches the problem by disallowing users to tab into the path control or left click on the path control text box (leaving right click untouched in case a shortcut menu was desired). It should still leave drag and drop/browse button functionality working as desired.

The only real problem with this is that the cursor still changes as if the user could perform an action. Solving this problem would, I believe, require using a custom vi or two that isn't available in basic labview 2014.

PS - The module copies the file selected into the same folder with " - Copy" added to the name.

PPS - Thank you OpenG for strip extension. I copied the code over so OpenG strip extension vi is not required in order to run.

[LV_Pilot]

If you read the OP carefully, you notice the motivation for this idea is to save extra checks for the validity of the path. As a serious developer, you can *never* save these checks. And here is why:

• The user selects an existing file.
• The user deletes the file, removes the disk, cuts the network cable, ...
• The user hits the "run"-button in your application and there you are, "crapping out throwing errors".

The actual problem is: The control behaves differently when entering something via the browse button or when entering something via typing or via drag-dropping.

When selecting a path via the browse-button, things are checked. Why are they not checked when the user enters a path by typing or by drag-dropping? That would be the actual solution to the problem the OP has. When I define "only existing" files I want the control not to accept a typed path if it does not exist. If I select "only existing folders" I do not want the control to accept a drag-dropped existing file instead of a folder.

So can someone please make an XControl, that does exactly that?

[Hooovahh]

Yeah you missed my point.  The point is to validate the path and know that it contains a valid path.  Not that the path is pointing to an existing file, but that the path doesn't contain any "?" characters, or the file name doesn't have any ">" or "<" in it on the Windows platform.  The rules to check will vary by platform and performing unique checks (or using vi.lib functions) every time there is a path control seems like a bit of a pain.

[LV_Pilot]

Oh, of course. The dialog also checks the well-formedness of the entered path, even for non-existent (new) files/folders. So yes, definitly, this functionality should also be ported to the other ways users can enter data into a path control.

[Raagul]

Yeah, its pretty good idea. now i'm managing the same requirement by keeping 2D picture control on top of the text entry with full transparency and disabled it. so that no one can edit the text area of path control 🙂 .

[Hooovahh]

That's a good solution but do you then have a UI that resizes? Do you make sure that when the path control resizes the picture control goes with it covering only that part of the control?  Also I do like having the ability to drop a file from an explorer window and for that we'd either need to drop on the browse button, or have the picture control be enabled or disabled to support this.  Basically I'm saying your solution works, but a native NI solution is preferred for these other cases.

[wiebe@CARYA]

@Raagul: Why a 2D picture control? A decoration makes more sense.

In the past I've used a Boolean with a browse image, and used a path indicator next to it. Pressing the Boolean can trigger a (dynamically started) file dialog.

I agree, a native solution would be better.

[AristosQueue (NI)]

Re-reading this thread, it strikes me that this is something that someone could build an XControl for. I don't think the community needs NI's help to build this functionality. XControl would encapsulate the functionality, handle resizeability, and be reusuable.

The idea is still good, so I will recommend NI continue to leave it open, but maybe someone could work up the workaround in the meantime.