Shaun Hayward

Awesome!

Just a thought... but could there be any possiblility to allow "special VIs" for classes kind of like "Ability" VIs for XControls. That way, a developer could specify how a class should behave when it gets serialized, etc? ...oh... I've just realized whilst typing this... this would also open a whole other fun bag of worms - Operator Overloading

Yep, came across that sneaky little one! The work around I used (which while not the "nicest" approach, worked quite well) was to have a field in my class that I would always change. In the case that I'm thinking of right now it was the filename - unnecessary, for the most part, but did come with the benefit of allowing for a "save" versus "save as" type of functionality.

I know its a subtly different case, but I will often flatten to XML first so that I end up with a data store that is automatically mutating (especially useful when it comes to "preference" objects) but at the same time is human readable / editable*. Shaun *Manually editing XML files can lead to the file getting corrupted so I usually will give a user a UI to change all settings, but it can still sometimes be very useful when debugging an application out in the wild

...well... in that case:

Sorry for not getting back to this until now... but in short, that was exactly what I was trying to do before finding out that it wasn't allowed. I'll head over and add it to the idea exchange and see what happens... thats for affirming I wasn't completely crazy!

If polymorphic VIs are "compile time polymorphism" and LVOOP Dynamic Dispatch VIs are "runtime polymorphic"... is there any reason (besides the fact that LabVIEW doesnt let me) combine the two? As an illustrative example: I may have a database that must be initialized with either a connection string, or a UDL file path. If no classes were involved, the ideal way I would implement this is with a auto-selecting polymorphic VI. However, if I then want to be able to create optimized database libraries for particular database types, the logical way (to me at least) would be to create a Database.lvclass:initilizeString.vi and a SQLServer.lvclass:initializeString.vi, with the SQLserver.lvclass, overiding the generic initialize method. However, this approach destroys the polymorphic capability as my Polymorphic VI cannot handle dynamic dispatch VIs. I guess my work around is to create a bunch of static VIs calling dynamic dispatch equivalents (a la DVR classes) but, as with DVR classes this seems a little bit hacky and a bunch more work than it should be. Am I alone in thinking that (a) this would be something useful, and (b) is there a fundamental reason this shouldn't happen? Shaun PS. I was thinking about adding this to the idea exchange, but wanted to get the opinions of you guys on here first!

I have actually done that many times - it makes coding up the application much quicker than having to go and find each VI separately (and can be very neat when you use ":" characters in the menu names to create nested selections)

As always, there is a middle ground (IMHO): Create a lvlib, make the AE VI private and create public "Accessor" VIs for each of the actions. This has the advantage of keeping the "simple" AE paradigm whist restricting uses of the internal VIs. In addition, the accessor VIs can have the proper connections for the action involved (named, typed, and with appropriate required statuses), making them a little easier to use (and to avoid having to remember what inputs are needed for what actions). Note: I personally am not such a huge fan of action engines everywhere for the simple reason that they are global structures which means that you cannot easily modify your system to deal with a second "thing", and your "thing" can be used absolutely anywhere, not just in the part of your program that does use it.

It may be "costlier" but I ended up doing the two control thing (ie a strict type def of a dial and a numeric) because I was sending out a bunch of RS232 data each time the control was changed (and at 9600 baud, I didn't want to flood any buffers). This ended up being pretty simple to implement, and the only major downside I had was having to manage two event cases per control (value change on numeric, and mouse up on dial). I know it might have been tidier to wrap this up in an X control, but that seemed like more hassle than it was worth. Shaun

The Windows Registry has more permissions controls in Vista+ but if you put your settings where Microsoft would like you to, then all should be fine. In particular, if you keep your application settings in HKEY_CURRENT_USER\Software\<Company Name>\<Application Name>... you should have no problem. One of my personal pipe-dreams with the registry access is to create something that could work similar to the (Un)Flatten class to XML VIs, whereby it could take a LabVIEW object and create an appropriate hierarchial bunch of keys/values in the registry automatically (and ideally, cope with version changes - probably leveraging the XML VIs to let LV deal with the mutation).

Yeah, I have always wondered why that was the case as well... In the past I have just ignored it (as they were the same basic datatype)

Thats very good to know...

If your new PC is coming with Vista, bear in mind that the NI only supports LabVIEW 8.5+ on Vista.

In the New... Dialog, there is a section under VI called "From Template". This is automatically populated with the contents of your C:\Program Files\National Instruments\LabVIEW XXXX\Templates folder - adding control and VI templates files to this folder will make them appear in this menu. You can also add folders and even preview images to help with this, have a look at the existing templates to get an idea. Shaun

To join your XControls event registration with some other event registration (ie whatever else the user may have), the use of your XControl could always bundle the two registrations together:

Would a SEQ whose datatype is a private cluster effectively block external code from gaining a reference to the Q?

Here's my two cents: [sidenote] Its funny, I was thinking about possible ways to explain benifits of LVOOP techniques on the way into work this morning (for internal training) and one of the things I was coming up with was explaining the drawbacks of functional global VIs (aka Action Engines), with particular reference to maintainability (ie what happens when you need a second "thing")... In that case the answer to me seams clear - functional globals may be easy to implement and provide a clear bottle neck for debugging and testing but can cause all kinds of maintenance nightmares, such as the example I just mentioned, or even remembering which inputs should be connected for a given action (although this can be mitigated by creating "wrapper" VIs, but by that point the only thing separating your action engine and a class is that you data is on an uninitialized shift register instead of a class wire). [/sidenote] Now a global within a class I'm more torn over... I personally think that a functional global VI could be a valid technique for static class data (say, for example, a settings/state repository or whatever) but that said, there are probably better ways of achieving that same functionality, for example, an aggregation class. I guess that even with classes one still needs to think carefully before making any data element global (and if it can be avoided, all the better), however a private/community global at least has the advantage of being able to limit the global's scope and add the necessary protection. One example where I did use a global within a class was to keep track of serial ports in use - we had a "motor framework" that allowed the system to use motors from different manufacturers over a variety of different interfaces. What we wanted to do was make sure that only one kind of motor driver could use a serial port at a given time but if that driver supported daisy-chaining then there could be multiple instances of that class sharing the port. The solution was for the Motor Framework class to have a registry global, keeping track of what motors were initialized (with port names, device IDs, and driver names), that way when a motor class attempts to initialize it has to request a port from the motor's global (through a properly typed accessor VI). Shaun

One thing to bear in mind is that SQL Server now comes in a free "Express" version. It offers some limitations such as a maximum database size of 4Gbs, but in our test systems, I have never hit the limits. Whats also nice is that if those limits are hit in the future, it is seemlessly compatible with the other not-so-free versions of SQL Server, meaning that you can easily upgrade the back end and your test system software will not even know the difference. Shaun

When dealing with larger files, you could do the same basic method but just reading in a chunk of lines at a time - e.g: Read, say. 100 lines Check to see if required line is in the chunk, and make change if necessary Write that chunk do new file See if any lines remain Also, if the line is always a fixed number of characters you could also use the Set File Position VI to move to the specific location in the file and then just overwrite that portion.

Congratulations!

Thank you! It works really well in a little internal project I have on the go, where the host application has many "modules" of which some have a user interface and some don't (or where a particular module launches an external app instead of displaying in the subpanel). For example, if a module wanted to launch Notepad.exe as it's "user interface" instead of displaying a VI in the subpanel, that child's "display UI" VI, would use the subpanel ref to clear the subpanel and then use System Exec to launch notepad, all the while the OO-ness of the interface nicely decouples the host application from the module's user interface. Obviously this has limits and checking to make it smooth and robust, such as the parent class having functionality to ensure that if a child wants to display in the subpanel then it should be of an appropriate size for the subpanel etc, but it seems to be promising.

For inserting an object's UI into a subpanel, I have used the reverse approach successfully - I have a DD VI that accepts a reference to a subpanel called something like "Insert UI", then its up to the individual class to decide what VI gets inserted and give the opportunity for the class to do any housekeeping before actually displaying its UI to a user. Here's a pic:

One thing that might help speed things up would be to use a non-.NET implementation. An example that I have used in the past is to use the FileVersionInfo.vi in vi.lib\Platform\FileVersionInfo.llb - this uses Win32 API calls to get the same information which are normally faster than their .NET counterparts (at least in LabVIEW anyway). Shaun

There is an example project directory template available as a download from the Bloomy Controls LabVIEW Style Book Companion Website (www.bloomy.com/lvstyle) that could give you a starting point.