Francois Normandin

When you close your application, you can use the "Panel Close?" event to ascertain the conditions of closing and decide what are the actions you need to do before closing. When using "Panel Close?", you'll notice that you can choose to discard the event on the right side of your event case. If you choose to discard it, the "Panel Close" event will be filtered out. By doing so, you will handle all the cases required to close your app the way you want and decide which case will effectively stop your loop(s). Or do you really need the Application Close event?

In these difficult economic times, every effort is appreciated. <object width="640" height="385"><param name="movie" value=" name="allowFullScreen" value="true"></param><param name="allowScriptAccess" value="always"></param><embed src=" type="application/x-shockwave-flash" allowfullscreen="true" allowScriptAccess="always" width="640" height="385"></embed></object>

Hi Norm, of course, you are totally right. I've failed to even consider this possibility. However, the code does it and doesn't do it at the same time. From what I can tell at first glance, there are two caveats: 1- "Properties.All Supported Properties" doesn't return the full property name. I mean, take XControl, it contains "Is XControl?" and a cluster of "Container Bounds". I thought the property returned "XControl:Is XControl?" and "XControl:Container Bounds". Rather, it returns "IsXControl?" and "Container Bounds"... so in the successive for loop, I get values for the property "control/Container Bounds" instead of "control/XControl:Container Bounds" and therefore gets the wrong property value for all properties that share the same datatype. This wil happen in hierarchies like Cursors, Plot, XControl, and so on... (Name collisions) 2- And the same "Properties.All Supported Properties" returns the property names inside hierarchical structures up to the first separator. We can see that from the "Caption" property. The first property is "reference", and then the first separator. So this is all that gets thrown in the file: a reference number which is totally worthless the next time you would load the application. Here, I guess I should try to detect the reference type and add it to the list of "control references" to sort though. There would most probably be issues with naming convention in the file to prevent name collisions here as well. I don't see how this can be done safely without using recursivity. To tell the truth, this is more of a fun experiment in scripting than it is a real need (for me anyway). Like Chris mentioned, save the control directly to a file ad save yourself a lot of trouble!

Because I just noticed it existed late yesterday PM (see my status on front page). It's already replaced in my programs.

Hi Gan, As stated earlier, I don't know if you have any performance changes with the coercion dot you're dealing with. Read this post to help decide if it applies to you in this case. It seems to me that both types are strings, but the coercion dot is inserted to help you recognize a typedef change, similar to numeric vs knob, not a real typecast.

Annoying it is, but I don't think that's gonna be changed. Let's think of how it might affect appending to text file. Indeed it does. OpenG to the rescue (as usual).

I understand you feel nasty about that red dot, but I don't think you lose any speed over that. If you want, you can use the "type cast" primitive ans get rid of the dot, but it doesn't accept the array input, so you'll have to use it in the loop anyway. BTW, thanks for pointing to DAQmx Flatten Channel String.vi. I just realize that's just the thing I needed for solving one of my problems!

You think it's a bug? It's been adding a line at the end since I can remember. Or has it? I can't find conclusively information about if EOL is a standard termination for spreadsheet formats... Yes, I tried to connect the string directly and it didn't change a thing. I think there's a slight no difference between string and DAQmx channel/task/whatever, something I've seen only when using variants to propagate them tells me it's a XControl with string state. HEX Display is the same when you cast it to string. ***** Talk about coincidences... this VI will do it for me.

After a decade of programming LabVIEW, I have to admit I still get bitten by stupid mistakes. Today's mistake is one I'd like to share because it's so simple and yet, I had to take a long lunch break to clear my head before I finally nailed it. In the pic above, I simply give the user a list of available ports and lines for a selected DAQmx device. The user selects one or multiple lines and I pass it down to create a task. And this is the solution: Using the Array to spreadsheet primitive adds a end of line at the end, which was carried an couldn't be filtered later down the road by DAQmx "Create Virtual Channel.vi". I hope to save you some pain by sharing my misfortune!

I changed the hierarchy. Check out the top-level VIs in this llb saved for 8.6. I had to include the OpenG VIs in the llb to prevent breaking the links. I got wet last time I backsaved... SaveProps.llb

I had started this last time a similar question was asked, just for fun. So I finished it. It's only the "save to file". You'd have to do the same for "loading" the properties... but I think it's a good start. Scripting involved, of course. Keep both VIs in the same directory and call "Save All Properties to INI.vi" with inputs wired. No error checking and no user interface done. saveprops.zip

Invoke Node >> LabVIEW Class >> Open

I think you're right and it's an error in the documentation.

Hi Mircea, it seems you're almost there. All you need is a XY Graph and a correctly bundled data cluster. First, your cluster needs to be bundled in the correct order. First, wire the data representing your initial time (t=0). Then the uniform spacing on your X-scale (dt) and finally, your vector containing Y values. Feed this cluster into a XY Graph. These graphs are polymorphic and will adapt to the correct format if it's a valid one. The above mentioned cluster is a valid format. The XY Graphs should be easy to find in your LabVIEW palettes. Do the same with phase data (t = 0; dt; phase vector). PS. You can post your VIs directly instead of uploading compressed bitmaps...

Patience, you'll probably get a fix in 2011...

I agree those error messages are far from optimal to say the least. I've stuck my head a few times too. Hopefully we'll see improvement in error documentation with LV2010...

Congratulations Dan. Humm. I thought it was the "Discard?" Event filter.

Hello Mike, A descendant class cannot call a private VI from its parent class. If you've overridden the private VI, I guess the error is that you can't call the Parent implementation with "Call Parent Method" primitive in the Child. If you have to call its parent implementation as part of the child's code, you should probably make both of them "Protected" instead of Private.

Great digging Scott! Using Scripting Workbench, I noticed the TagSet class possesses very few methods: Set & Get Tag; and no properties. Aything could be stored in those variant tags, but most likely nothing necessary for our own customized Preference Pages anyway. Based on your description, I got to put my own page there in minutes. Thanks for clearing the way.

This is why I didn't do it yet. I developed it in LV2009 and would need to make sure the directory structure is the same. This work is done at home on my spare time and since I don't have 8.6 installed on my personal computer, that's not my priority right now. With the beautiful season coming back, I anticipate even less time for that. Sorry.