Michael Aivaliotis

Do a test to see if C:\Program Files (x86) exists using the "Check if File or Folder Exists.vi". If it does exist, it means you are running 64bit Windows.

Added a LabVIEW Wiki page that covers this. Anyone can edit and improve it if they desire: http://labviewwiki.org/Development_Environment_Event_Callback_VIs

I would think twice before generalizing like that. User events are at the top of my list and many others I've talked to, when it comes to inter-process communication. Also, using the timeout frame is a common use-case for reading other data that needs polling or other updates between events. In fact, at the CLA summit, there were many requests by other CLAs to extend the capabilities of the Event Structure even further, since handling user events is simply not enough. Even though, at the end of the day, I'd really like NI to find a solution to this problem which allows me to register for events all willy nilly-like and only selectively create cases to handle them - my gut tells me that, If I I don't need to react on an event then I shouldn't really be registering for it in the first place, should I. For now, I would chalk it up to: "Hey, I just learned something cool and I really should spread the word about this 'best practice' to my colleagues and warn them about it." Education is important. I really like the option of having a right-click menu toggle in the future that would allow you to enforce that you must have a case for every registered event. The default behavior should be as it is now. This way, anyone relying on the old behavior doesn't get screwed during an upgrade. However, I would also like an options switch to allow setting the default mode for event structures. Similar to the auto-grow option. At least, this way there would be a documentation entry which the user can browse to find out more.

I dunno man. It sounds like you need a database instead of a file. Just load the data you need based on a query. But that's a whole other thread perhaps.

Don't use any type definitions inside your class data. I'm not sure I'm following what your final implementation looks like. You're letting LabVIEW load the object with the binary read function and then fixing your index if it's bad? Is the index a scalar value that requires some logic to determine its value? I would probably use the class version number to determine what code to execute on the data to fix the index. At the end of the day, you still need to do some "fixing". When I've had to do this. I use a multi-stage sequential conversion routine. based on what version I'm reading. So if you have 3 versions of your file then you would do 1->2->3. Needing 2 conversion routines. I've stayed away from using the class versioning system for saving object data because I tend to use typedef clusters in my objects. Ya, I know, bad - bad Michael. I'm slowly trying to ween myself from this habit.