Jump to content

Prompt for directory


Recommended Posts

Hello Thang,

I don't have LabVIEW on this computer, so everything I will tell you won't have any example attached... Sorry!

You can configure the "File Dialog" to browse only for an "Existing Directory" (at least with 7.1 so the "old" files functions...) and you will have one of your solution (a new button called "Select Current Dir"), you can also right click on the folder button of a Path control, and configure the way to browse.

Don't forget, as well, that you can put *.dir as a pattern to see only the Directories when you browse!

I hope that will help you.

Good luck!

Laurent

Link to comment

QUOTE(Dirk J. @ Jul 20 2007, 01:44 PM)

(as you'll find, the BrowseInfo structure, which is a cluster of pointers, that is I32 is not filled in in this example. any ideas on how to accomplish this?)

The only one you really need is the window handle and that's easy - you just need to call FindWindow from User32.dll and give it the window name (for a VI, this can be accessed using the FP.Title property).

The only other option which has some importance is the uFlags parameter, which should be managable by creating a cluster of the boolean options and then converting it to a number. The numeric values of the different options are specified in the shlobj.h header file.

Link to comment

From a UI perspective, it would be nice to specify the title as well.

QUOTE(yen @ Jul 20 2007, 01:27 PM)

The only one you really need is the window handle

Here's a modified version which makes the calling VI owner of the dialog, and displays a custom title.

Link to comment

QUOTE(Dirk J. @ Jul 20 2007, 02:51 PM)

Here's a modified version which makes the calling VI owner of the dialog, and displays a custom title.

And here's a VI you can use to select the parameters. Now we just need to bundle them together nicely and we're good to go.

BTW, I had this VI on my hard drive for a long time, but I avoid it because it's not pure G. To get it play nicely would require only loading it dynamically if you're in Windows and testing for each Windows version, etc.

Link to comment

QUOTE(yen @ Jul 20 2007, 02:55 PM)

...it's not pure G...

If you allow for using a lot of Call Library Function Nodes, then this one is.

User inputs: owning VI, title of the dialog, root item of the dialog, browse options

Outputs: selected directory and it's display name.

PS: I didn't solve the 'image' issue, but on the other hand, that will only return an index for the system image list - which should be accessable in some mysterious way)

Link to comment

QUOTE(Dirk J. @ Jul 20 2007, 05:03 PM)

If you allow for using a lot of Call Library Function Nodes, then this one is.

How is that one any more pure G than the other version?

The problem is that uses OS API functions, which in this case will only be available on Windows. I did all my LV work until now on Windows (some of which included interacting with .NET, which is definitely purely Windows so far), but I prefer to avoid OS calls if they are not necessary. In this case, I consider LV's dialog to be good enough, but if I wanted to use this one, I would probably wrap it in a dynamic call.

Link to comment

QUOTE(Dirk J. @ Jul 20 2007, 09:03 AM)

If you allow for using a lot of Call Library Function Nodes, then this one is.

User inputs: owning VI, title of the dialog, root item of the dialog, browse options

Outputs: selected directory and it's display name.

PS: I didn't solve the 'image' issue, but on the other hand, that will only return an index for the system image list - which should be accessable in some mysterious way)

I think this has a memory leak. The IDList returned by SHBrowseForFolder is a memory buffer that should be freed with the (originally undocumented) ILFree function in shell32.dll. And for OSes before XP or 2000 this function was not exported by name, but only as ordinal number 155.

A little known feature of the Call Library Node is that you can also reference functions that are exported by ordinal by entering the ordinal number as function name. LabVIEW seems to attempt to convert function names that only consist of numbers into an ordinal and try to load the function as such.

Rolf Kalbermatter

Link to comment

QUOTE(Dirk J. @ Jul 23 2007, 10:49 AM)

which other version?

I was refering to the one you posted earlier, which was essentially the same thing, just without the uParam cluster.

Even if you are confindent that the application will run only on Windows, encapsultaing the functionality is recommended so that you can at least replace\change it easily if the need arises.

Link to comment

QUOTE(yen @ Jul 23 2007, 08:14 PM)

I was refering to the one you posted earlier, which was essentially the same thing, just without the uParam cluster.

Even if you are confindent that the application will run only on Windows, encapsultaing the functionality is recommended so that you can at least replace\change it easily if the need arises.

Ah, but that was deeplinked to the NI forums, it wasn't mine :)

Regarding encapsulation, I agree. The way I use it, is implemented in a LVOOP class. Some problems may arise however if a developer decides to fork the wire, which will create a new class with the same pointers. Still, that, or maybe an OpenG-by-ref class is the best way to go.

Link to comment
  • 1 month later...

I'll throw my hat in the ring with a neat util that I got some asstance from G Zou getting together. Only works on windows but doens't use any API calls.

It allows you to have multiple items in the drop down list using the standard LV file dialog.

It demo's well simply by placing on a blank BD and running it. You'll see the below dialog

http://forums.lavag.org/index.php?act=attach&type=post&id=6798

Enjoy

http://forums.lavag.org/index.php?act=attach&type=post&id=6799

Link to comment

QUOTE(lraynal @ Jul 20 2007, 09:23 AM)

QUOTE(crelf @ Jul 20 2007, 01:56 PM)

That's got to be the tip of the day - thanks Laurent!

I'd rather think this is the misunderstanding of the day. :P

If you put *.dir in the pattern field, the file select box will show you all the directories and all the files that match this pattern.

I named some files test1.dir and test2.dir and - of course - they were visible with this parameter.

Of course, you could try using something like *.salflsdhflkasflsdjlfdjfl to achieve the effect of a "directory only file select box". But be aware, that this mask will always be shown in the file type field of the dialog and the user can always change it back to "*.*".

Link to comment
  • 2 weeks later...

Thanks a lot. I noticed a problem with this vi when I ran it with the Root input set to anything other than Desktop (item 0). In Labview 8.0 I receive an exception error from Call Library Function Node SHBrowseForFolder 0xB70 of my sub-vi. Is there any way to specify the start directory to be anything other than the Desktop? Can I specify it as some random folder (that I know exists)?

Thank you,

Stetve

Link to comment

There appears to be a conflict with the 'new dialog style' flag.

If you uncheck that, you should be able to use all root options.

QUOTE(steveg417 @ Sep 10 2007, 09:01 PM)

Thanks a lot. I noticed a problem with this vi when I ran it with the Root input set to anything other than Desktop (item 0). In Labview 8.0 I receive an exception error from Call Library Function Node SHBrowseForFolder 0xB70 of my sub-vi. Is there any way to specify the start directory to be anything other than the Desktop? Can I specify it as some random folder (that I know exists)?

Thank you,

Stetve

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.