jgcode

No worries - it was a bit late, but I posted in case it helped. I can't post the VIs but can you PM me your email and I will get them to you. I also have been working on a build script that you might find useful (as I am guessing that is what you are doing?). Its all in LV 8.6 - let me know what version you are using as well and I will try to convert down if needed. Cheers JG

At work we had "dirty" installs from the first 8.6 (or 8.6.1 - can't remember) dev suite installer discs. It seems Kaspersky on VISTA was to blame, along with some super long file paths that results when we stored the discs on our server. Also, I have to turn Kapsersky off just to build an installer.

This is how I auto increment an executable's version (build # only) in my build script. The child reference of the BuildSpec[] is passed to the Executable Auto Increment Build VI. The Get and Set just read or writes to the XML tags.

Ha! Maybe he thinks it should looks something like this?

Is that what they are calling it now?

Certainly my good man! English, with Norton 360v2 (hey its not that bad )

Hello Anders I am running 8.6.1 and 2009 at Home on Vista Ultimate 32bit. I am not running the others you mentioned. The reason being, as far as I am aware 8.2 is not compatible with Vista. 8.2.1 was the compatiabilty changeover. Cheers

I have been wanting to do this for ages - so I just wrote a RCF plugin that does this. But this is great this has been opened up to the public. Awesome!

Yep Shaun is correct NI Rio 3.2.1 (Aug 09) is up on the ftp. We have just downloaded and are installed now. Cheers

Thanks! Thought as much. I wanted to know, so I can plan ahead for the future Cheers JG

Hi Ton I am fairly new to OOP but would still like to suggest the following from my current experiences: Using the verification statement for inheritance can help: Ask yourself, or jot down on paper, if the subclass (e.g USB) IS A more specific type of the superclass (e.g. GPS) USB is a GPS (makes sense from a DAQ-type POV) Serial is a GPS (makes sense from a DAQ-type POV) TDMS is a GPS (does not makes sense) CVS is a GPS (does not makes sense) Therefore TDMS and CVS should not inherit from GPS. You may want to create another superclass that these two classes inherit from - e.g. a Log Interface - and this class could be have a association with GPS (either through aggregation or composition relationship etc...). I have been told (in other posts) that design pattern knowledge is the way to go to improve class hierarchy design - this is something I am trying to achieve at the moment. I have had similar issues as you along the way learning this (as I am sure others have too). Its all part of the fun IMO (Endevo) Mike H mad a recently great post regarding Interfaces in LabVIEW - it is work checking out. And of course AQ's Design Patterns Document on ni.com.

You're Welcome!

Guessing - is the VI you're pointing to idle?

Hi Gmart Will this ever change in the future (64bit being able to produce a 32bit build) or is it forced by the nature of the OS. Cheers JG

Sweet!

Great job Crelf

Hi Shaun DAQmx for 2009 is now available for download from ni.com drivers and update page Similiar options as before, but with cooler names DAQmx 9.0 http://joule.ni.com/nidu/cds/view/p/lang/en/id/1278 DAQmx 9.0 Run Time Engine http://joule.ni.com/nidu/cds/view/p/id/1388/lang/en DAQmx 9.0 Run Time Engine Core http://joule.ni.com/nidu/cds/view/p/lang/en/id/1368

In this post I mentioned that some 2009 Modules and Toolkits were available for download. However, you can find LabVIEW 2009 and all Addon Modules and Toolkits here: http://www.ni.com/labview/family/ You can download for 30-days evaluation or activate if covered under you SSP (or whatever license). More specific links include: NI LabVIEW Modules and Toolkits for Control Design and Simulation https://lumen.ni.com/nicif/us/evaltlktcds/content.xhtml NI LabVIEW Modules and Toolkits for Embedded Design https://lumen.ni.com/nicif/us/evaltlktembdes/content.xhtml NI LabVIEW Modules and Toolkits for Image and Signal Processing https://lumen.ni.com/nicif/us/evaltlktsigproc/content.xhtml NI LabVIEW Modules and Toolkits for Industrial Measurement and Control https://lumen.ni.com/nicif/us/evaltlktindctrl/content.xhtml NI LabVIEW Modules and Toolkits for Report Generation and Data Storage https://lumen.ni.com/nicif/us/evaltlktrepgen/content.xhtml

Ok its seems to be up... go for it https://lumen.ni.com/nicif/us/evaltlktcds/content.xhtml

I tried to point the LV8.6 installer to LV2009 folder during the install - but no luck Now that LV2009 can be activated is there any talk on a LV2009 license release for scripting? I was thinking the API may have been an feature of 2009. Cannot find anything searching online and LV Help. Cheers JG

Mine just when though too. It took a bit of toing and froing with the Activation Server though but it finally went though. Only had to reboot LV2009 not my PC tho.

I have been searching for it on NI's support downloads page - but no luck at the mo. LabVIEW Embedded Module for BlackFin Processors 2009 - Windows Vista x86/XP is out tho, so it maybe real soon.

I recommend everyone getting into it - as now I don't think I would want to code an app without it. It was (and still is) a lot of fun to learn and program with. The only issue I have is that my dev environment crashes alot (and I mean alot) when using it and I hoping this may have been fixed in 2009 (or occur less frequently). In order to learn it I thought the best way was just to dive in head first do all the examples, read all the white papers, watch all the on demand videos and just start using it! Around last year, I thought to myself that LVOOP was the way that NI had chosen to go with its OOP implementation so I decided I wanted to get into it and use it seriously for client apps. At the time I was confident that LV8.5.1 was a very stable release for LVOOP - I had heard of some issues with its initial release around LV8.2. We then moved up to LV8.6.1 internally and LVOOP had more features and improvements - which made it even better. Its great to see once again that LVOOP has evolved a lot in 2009, and that it is starting to get used all over the place within LabVIEW. So I am very confident that NI will continue to support it and will keep improving its implementation. Along with all the new property additions to the .lvclass file - this addition of a native ByRef scheme (for any datatype in LabVIEW) looks awesome. Plus NI have fixed up the conflicting file names get moved outside executable problem which usually comes up from using .lvclass files, (rather then .lvlib for me). Therefore, from my point of view, I couldn't have asked for more in a release, from what I have seen: 2009 is a great release for me, as it covers my biggest issues/concerns/problems/gripes that I was facing as a LabVIEW developer using LVOOP on PC targets. LVOOP moving to RT sounds sweet too. Also wrt ByRef LVOOP - I can't wait to see the examples the community comes up with. Cheers Kudos to NI, (and of course AQ) for their brilliant work

Cheers for the summary!

Thanks Jim. I missed out on the Beta Testing and this is all new to me. And it's very exciting stuff thats for sure. I have just been checking out Christian's Stuff (from this post), which looks awesome and is a great read. AQ was correct in saying that LVOOP is used a lot in 2009 - even the new plot controls are LVOOP. As you must know there seem to be alot of LVOOP additions - stuff thats I have seen been mentioned on LAVA is in there too (Friend Classes). Since you have been using the DVR LVOOP objects for a while are you able to comment about what you have found on their implementation compared to ByRef GOOP toolkits (e.g. Sciware, Endevo, DqGOOP, OpenG etc..)? Cheers!