03-24-2011 09:05 AM - edited 03-24-2011 09:07 AM
I am using a file dialog VI to open a windows file dialog. I have defined custom file extensions to be displayed, but they do not all show when I drop the box down. I can't add a carriage return because it takes those literally. Is there any way to
1. Expand the box
2. Make the File of type drop down "word wrap" so the user can see them all.
As a final option, is there a way to make multiple custom patterns like shown below? I'm assuming so and may have missed it in the context help, but I didn't see anything about it.
Solved! Go to Solution.
03-24-2011 10:12 AM
Yes, this has been covered already here
03-24-2011 07:42 PM
03-25-2011 03:58 AM
@for(imstuck) wrote:
Call me crazy but this seems to be a very cryptic way of doing something that I feel should be built in functionality for a file open dialog VI.
I completely agree with you there!
03-25-2011 04:19 AM
@for(imstuck) wrote:
Call me crazy but this seems to be a very cryptic way of doing something that I feel should be built in functionality for a file open dialog VI. It, however, works and thanks to snippets I don't have to rewrite a wrapper :)
It is cryptic and complicated and most likely an unintended functionality that happened by accident, since that is the way you have to put the data buffer into the data structure when passing it to the Windows API function for the file dialog. What seems to happen is that LabVIEW simply puts the pointer to its string handle contents into that structure and just goes on. In that, it is actually a potential security risk since one could try to devise a string that might cause some sort of buffer overrun or similar in the Windows function.
It also most likely is something that only works on Windows (and might actually cause even havoc on other systems), since the file dialog API on other platforms is very different (in Linux it still uses it's own LabVIEW specific dialog only). If someone really had made this on intention they would rather have spent time on making this a user friendly option of the diagram node, than trying to support this Windows specific string format on non-Windows versions.