MikaelH

Thanks

I've just noticed a strange thing (LV2010SP1-LV2012), that when I run my application first, the default cursor icon for the mouse over a picture controls is the hand with the pointing finger. But then if I go into the icon editor, that application changes the icon over the picture control depending on what tool you have selected. After this, when I run my application now, it uses the last tool from the icon editor over all my picture controls. That must surely be a bug, don't you think? There is scripting property node I have to use to get around this in my VI, that sets the default icon of the picture control, it took me a while to find it. Cheers, Mike

I would solve it with OO :-) I would probably create a singleton DataBase Objects that handles and stores an array of Queue-Objects. I would create a abstract Queue Objects, and in different sub classes I would store the specific LV Queue type. This is how a UML diagram could look like:

Unless you use referenced based OO, like GOOP3 or GOOP4 ;-)

Chris, that could be solved if you right click on the property node and select this option: ...but of course you need to have LabVIEW 2013 Alpha installed

And if you want better precison you can use this VI: \LabVIEW XXXX\vi.lib\Utility\High Resolution Relative Seconds.vi

Nice work. Regarding renewing the CLA certification, do you all architect out there renew your certification every 2 years? Cheers, Mike

Congrats, when can we buy these from the LAVA shop?

And you will probably soon create an enable and disable VI to save block diagram space. //Mike

You will always get the Scrolling Event, but I've seen this VI being able to report an absolute value of the scrolling wheel on some computers. Check the Process.VI and the timeout case where I query the Mouse info.

I would create a small spawning VI that polls the Scrolling info and then generate events. Something like this: ScrollWheel.zip When I tried this on my computer I only got relative Scroll info from the LV VI, I know that some system only gives you relative and some absolute. I'm not sure why but you have to support both. Cheers, Mike

I like that book as well and recently bought my LV team a book each, the perfect valentines present :-) I have also implemented the Decorator Design pattern using referenced based objects with the DVR. (Symbio’s GOOP4). DecoratorPattern.zip You can read this design pattern here for free: http://oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf Cheers, Mike

Thank you

Thanks, so maybe this command would work: command.com /C Myexefile.exe -- arguments And why not, I can create a DLL also...or convince them to migrate to a real programing language ;-)

It could be that the devlopers are senior enough...

Hi Guys Sorry for using such a bad word as LabWindows here on LAVA, but I have a development team in Fremont and Shanghai that develop all their code in LabWindows. Since you can't do all cool stuff there I had to write the intelligent code in LabVIEW, and have them to call my LV exe file. I let them control the behaviour to my exe file with arguments so they can call it like this: MES_Finish.exe --PreCure or MES_Finish.exe –PostCure But the developers say that LabWindows can't call exe files with arguments. Does anybody know if this is true? A work around that didn't work either, was for them to call 2 batch files with the argument syntax in. Cheers, Mike

I would use OO to solve your problem and use a picture control to draw all your objects. The Top level application just keeps track of an array of objects that could be of different types but they are all inheriting a common base class. The main application calls the BaseObject.Draw method(VI) on all the objects when you need to update the screen. When you click on the picture control, the main VI goes through all Objects and calls a method(VI) to see if the Mouse coordinate is within the objects boundary. I like this approach since all object could have different state and if you right click on them and would like to display a drop down menu, all objects can decide what menu options are valid for this object.

I can't wait to try it.

One more

Too bad you weren't involved in the FileIO/driver design from the start, then LV might have been a pure data Flow language. But maybe we need to start with a Pure DataFlow operating system to get it working properly.

Chris, you looked a bit confused the first couple of hours when I taught you the course 10 years ago. Now it's of course Symbio's GOOP course, and we're about to release a new version of GOOP Development Suite any day now. Anti-Flow Is Reference Objects, Anti-flow? I guess it is, but it's also how you use it, this picture below is a reference singleton class that I call in a data flow sequence. Should you try to avoid Anti-flow? Good luck and try. All very simple applications could be done in pure Data-Flow, but as soon as you use any advanced features such as: File-IO, DaqMX, Vision, Queues, Semaphores, DVRs, Instrument References you are using references. In my opinion, if you are an advanced user and ready for classes in LabVIEW, you already know the difference between Data-Flow and By Reference, and you know when to use the different techniques. Cheers, Mike

All the best wishes on your new role.

I'll do it as well, you're not alone. One example is when initializing communication with instruments that can be configured for different baud rates.

No, do you have any extra "debugging keys setup in your LabVIEW.ini file.