jgcode

I have also gone the path of (very simple) LabVIEW installers. It works quite nice and when I did it in LabVIEW 7.1 I even could make it self contained by only copying a handful of LabVIEW runtime files into the same folder as the executable itself, so that it would work even with no LabVIEW runtime installed. Doing the same in newer LabVIEW versions gets however increasingly difficult and having to run an installer first for the LabVIEW runtime to be able to run an installer then for your application is not a good option .

Hi Rolfk - the LV7.1 installer sounds cool.

Any application is going to need a LabVIEW run-time, so having it installed before you run the install would be all that would be needed.

I don't think that is much of an issue. You can't really get around it with LabVIEW (although it seemed you did with an older version! )

Wow sounds like you have set yourself a big but very impressive target

I like to think big

Its not that hard. I have already done some of it and it works sweet.

The other ideas I have had for a while.

It just about getting the time.

Yes a BOM is Build Of Materials, it tend to just be used for a QA satifaction / audit point of view. It can be useful to see easily what files have change between build as it included's the source control system version info for each file.

Ok, cool. So you request this from your SCC then create a text file or HTML document or similar?

Out of interest - do you have an example document of what this looks like?

Cheers

JG

I had to delete your vi from my computer--I was worried it would be a bad influence on my vis.

I'll take one for the team - here is the image in case anyone else is too scared to download it

I am really please with the results of this and must pass on my thanks to you in showing my another way to do this.

Thats great news, it is rewarding to hear that. This place is great for learning new stuff, I don't know where I'd be without LAVA/Internet. Definitely behind the 8-ball.

I must admit I am quite sad as I have after about 2 years finally abandoned the OpenG builder. But I have now decreased my build times from well over half an hour to around 5 minutes and my final built executable is around 6M smaller than it used to be. I do as a result loose the OpenG VI rename/ mangle options during build, but as all our software stays internal it was part of the openG builder I never used.

I haven't ventured down that track. Have heard some feedback from Daklu thats its a bit complicated to learn but pretty neat.

NI works fine for me. But I still wouldn't mind taking a look.

We do have a automated build system here and have had one for 2 years or so. Until this last month or so it was all based around the openG builder, until I looked at your code and found BuildTargetBuildSpecifications VI. So I have only really used from the code the case for building executables and built my own code around it.

On our executables we have a 'Help About' VI that we populate with things like build time, who built it, our ClearCase Configuration Specification and label. So most of the code I have added is my own ClearCase control VI's to check files out, update info and after the build to tidy all this up again. also I create a BOM of my builds.

Thanks for replying with what you do.

I am part way through implementing the following (which will be dependent on the project):

Check Out/In Project with updated Build Versions (I use Perforce)

Download installers (drivers, support software etc...) and extract files (zips) when building a Full Installer (usually as a CD)

Convert .bat files to exe (I have to see if this is possible with 3rd Party Software)

Create ISO image (For CD Installers) (have command line interface for my burning app so this should be fine)

Output text or image of Version for CD Label (I would like to automate this but I don't think my CD Label app has any hooks)

Move deliverable (Zip/ISO etc...) to Server

Label src code after save and build

And off course all this will be reusable.

A bit of work, but it is definitely worth it.

Also what is BOM (Bill Of Materials?) and how do you use it in your workflow?

In the days of LabVIEW 5, 6 and 7 when the LabVIEW Application Builder was pretty basic I used InstallShield Express to build professional installations. However this package costs extra money and you have to learn and manage a whole new package in parallel with LabVIEW's Application Builder.

I basically used the LabVIEW Application Builder to create the EXE and InstallShield Express to create things like Splash Screen, Licence Info, Shortcuts, Extra plugins etc.

However it now seems that most of these features are included in the LabVIEW 2009 Application Builder and I can only assume/hope that this is going to improve and have more features in the next release.

So personally I don't think it's worth going down the path of using Third Party Installers.

Chris

VIPM has a LabVIEW-built installer that looks really sweet.

This approach would be quite powerful and flexible (no need to learn another language/protocol and no need for additional costs)

Of course there would be the overhead in developing such a thing

It would have to be reusable/configurable and used across multiple projects for it to be worthwhile (to me) ...if only I had the time...

For now NI's one is great.

Maybe that is an option?

Hi,

I have been playing with your build script and I really like the potential of it.

Unfortunately our code base is written in LabVIEW 8.2 and I have been playing around trying to get the build script working in 8.2, so this is just a quick not to anyone who may be interested, the build script CAN be run when saved back to LabVIEW 8.2.1, but the project must be closed for it to work.

It appears in LabVIEW 8.2.1 the call to AppBuilder\BuildTargetBuildSpecification.vi will fail with an error 1025 if the project is open. However close the project and the call works.

Extra note in LabVIEW 8.2.1 if you open the project then open your build.vi and close the project, the build.vi VI will also close. So first ensure that your project is closed, open your build.vi and run it.

cheers

Dannyt

Hi Dannyt

I just saw this sorry! (subscribe to updates wasn't checked!)

Glad you like the potential of the script, it really can simplify things.

I have one for creating packages e.g. creates the correct size icon, updates dependency list from .vipc file, builds code using NI BUILDER and then the package using OGPB, then zips it up with all the LAVACR stuff (readme, examples, .vipc file etc...).

It just removes human errors during that process, so running the end product is much more reliable.

To confirm your post - the code is actually in LV8.2 for the Project API VIs (and most other internal libs).

But I really only use it for LV2009 personally.

To add in support the Project Tags need to be updated when they change between versions.

And I have only tested the Tags for LV2009.

I choose LV8.2 because that what most of my reusable code is in - and support for LV8.2 if I ever wanted it.

I upgraded the Project API package over this weekend as part of abstracting functionality in the script for reuse-ability.

Even things such as resolving the output path of the dist or exe is different between 8.2 and LV2009 (discussion of this is related to Ton's Post here)

So there is a bit more work to support all versions.

Have you implemented a scripting process in your work?

Do you have any feedback or examples to add?

Look forward to hearing what you've done.

Cheers

-JG

Dropbox rocks!

Attached is the repackaged Icon Editor API if any wants just that.

Cheers

-JG

jgcode_rpk_ni_icon_editor_api-1.0-1.ogp

Version History (Changelist):

1.1-1 2010 05 02

- New(): Added support for preserving layers after Icon Editor API upgraded.

- New(): Select Layer Tag UI added which allows user to specify Layer Tag when it is not found. This Layer can be made the default when searching next time.

- Fix(): Clean error handling for when non LVOOP Member VI is quick drop'd on.

I have added the Icon Editor API so that now layers are supported.

The package contains a repackaged version of the Icon Editor API compiled for user.lib

I also did updated the GET and SET polymorphic VIs icon's and added a MNU file so its neat.

This package is contained in the .vipc file (all other dependencies are listed only)

If you have any feedback please post!

Cheers

-JG

Aauuuuugggghhhh... please... make it go away...

(Ironically, women pull it off much better than men.)

What in the world was the competition for?

Speaking of Vulcans, can you do a mind meld? I have a horrifying image I need removed from my memory.

The competition was to video "The most amazing thing you can do in 7 seconds" and stick it on youtube.

It was tied in to The Watchmen release and about being a Superhero.

I didn't think that much of the movie, but after winning the prize I thought I should at least watch it, but I feel asleep (and had to rewatch the ending!).

The radio station bought the prize from a global events company so there were people from all around the world in New York for the this event.

We had to Race The Doomsday Clock (which is tied to the movie plot) around New York doing certain tasks to get evidence/clues etc... all tied into the movie.

There were costumed superheros from the movie around New York and we had to find them.

We climbed the Empire State building, rode the subway, had a helicopter flight over the Statue of Liberty, tours through Central Park, etc...

The assigned us a Tour Guide which was great, we got to see a lot in a short time.

I think mine was the most bizarre entry there, other country had artistic competitions, or random-draws

We got to meet Dave Gibbons, the author of the graphic novel too.

He did us a drawing and chatted to us.

Dave was really cool and interesting to talk to.

The other cool thing is that the hotel where we were staying (The Empire) was being filmed for Gossip Girl.

So we got to see some of the cast in action.

Yes I do follow that show

Dude... I'm feeling like totally disrespected.

If you want to be, like, totally disrespected check out my vid

I have not managed to go viral like Popcorn Tweets but I think my prize was much better - this was the winning entry for national radio competition and I won a $25K trip to New York last September.

I really should have done something with my hair.

Damn impromptu video!

Hi there,

Our company is shortly going to be making the jump from 8.2 to 2009 (yipee). I'm just being asked if there are any known issues either with making the jump or with 2009 itself. Any tips?

Thanks very much,

Martin

Other have mentioned some negatives, I can think of a few positives (off the top of my head):

Classes:

Oh, man. If you like using classes, you are going to love 2009.

8.2 was when they were launched and they were a bit raw.

In 2009 they are quite refined.

Executables:

You also have a new build model for exes which is nice

So if you use libraries (.lvlibs, .xctls, .lvclass) your build will be neat - no more external files

Project:

The project is much better, more functionality at your fingertips etc...

For example - I can really do some cool this when creating source distributions

Cheers

-JG

Another option is to switch over to classes. You are proposing writing an instruction vi that will load various back-end processing vis depending on the run-time conditions. You want the interface to remain the same (so client scripts don't break) but you need to be able to change the implementation. Classes excel at this.

I concur.

I have had success with LVClass Plugins e.g. supporting different file types after deployment.

Check out Tomi blog for a simple demo:

http://expressionflow.com/2008/06/02/extending-labview-built-applications-with-lvoop-plugins/

Is this what you mean?

OMG! I hope I haven't inadvertently disrespected and LAVA'ers, that was not my intention!

I've got one LabVIEW book and I can't remember when was the last time I found something in there I didn't know. Books tend to start off with the beginning and well, stop whenever the topics get too particular or advanced. These books are probably as good as any for someone getting started with LabVIEW, but for veterans like you, it seems to me that a book you'd get interested in wouldn't sell much because of the reduced audience. By the time books are published, you'll probably have gotten all the good juicy new stuff from reading LAVA assiduously.

I know what you mean, but I always seems to find some decent nugget in a book/manual - stuff I don't get, have forgotten or never seen.

Plus I like seeing things from other peoples perspective.

Referring to what you stated above, I do know that some of my favourite publishers have tight timescales of <6 months to turn out technical books due to this reason (as opposed to 12+ months a few years back).

So the content is not that old.

But yes I will concur the latest and greatest is LAVA

I noticed that LAVA set a new record number of people on line at one time yesterday.

Why How whatever...

LAVA is indead back.

Ben

Go Team LAVA!!

Hi

These LabVIEW books are new on Amazon.

I am always interested in reading new stuff.

Does anyone know if they are any good?

Cheers

-JG

Thanks for the tip. I guess I was hoping there was a way to do this natively within the project, but I guess writing automation code is the only way. I will give your project a try.

No probs, if you do anything cool, please post

Ok, so now I can turn on a feature in LV 2009 that outputs a log file when I build an exe. And that log file contains a line that tells me the version number.

Now, what I really want is the installer that installs this EXE to display the version number when the installer runs, so the use can see what version they are about to install. Anyone know a way to make this happen?

Hi John

I like to use a build script to update the Installer Version to the Application's Version so they are always synchronized.

I use the tags of the project to retrieve this information, I have not tried the log file.

Anyways, once you have the Version Info you could update the Project XML file of the Installer Build Spec to include it in say, the Welcome Title or Window Message?

Is that what you are thinking?

Here are those properties:

<Property Name="WindowMessage" Type="Str">Test Test Test</Property><Property Name="WindowTitle" Type="Str">Hello</Property>

Alternatively I normally name my distribution, including the Version Number.

If the final product is a CD (which is usually the case) then I name the CD accordingly

(And I think you maybe able to overwrite the name of a CD in a autorun.inf file - so you could update that programmatically too if that is the case).

And I like to use Dot NET within the application to show the Version Number (although then Dot NET becomes a dependency of the app)

Here is an example of using the Project XML to get Version Information and what I tend to do with it.

Cheers

-JG

If you choose to check DropBox out, use this link and I'll get a little extra storage for the referral.

https://www.dropbox....als/NTM2MjI0Njk

Sorry mate, I signed up last night when I read your post.

If I can still hook you up with more space somehow (now that I have an account)? please let me know.

I liked what I saw last night, am going to test it at work today.

I'm starting to think about a fallback strategy for our current test report storage. We subscribe to a service that has been fairly reliable and offers some great statistics, but their support levels combined with our smaller size may not survive the budgetary process.

I've used and like DropBox as a personal service and think it's great. I read that DropBox is based on Amazon's S3 (Simple Storage Service) and I wondered if anyone has experience using S3 with LabVIEW and/or TestStand.

Nice post. The Drop Box video you linked to looked like a Plain English video. I love those guys.

I tried something similar with a Microsoft Beta, but never really got into it.

I think I am going to give Drop Box a go for home-to-work file transitions

You might already know this but I figure it is worth mentioning...

Negative! I did not know this - so kudos.

I normally use the same color banner if I want to maintain a theme through to child classes, but what you are describing sounds much nicer, thanks.

In fact I have never see this effect before because I always use the default banner size.

I just had a play and it is beautiful

(sorry, I love icons)

Does your theme editor maintain the inherited icon layer behavior?

I did not have access in the icon API to do this.

However, I requested it on the weekend and Tom has delivered again (he is a very nice, young man).

The API now supports passing in a .lvclass reference and getting all the layers.

Therefore I should be able to preserve existing layers and only update the NI_Library layer

I will have a go at integrating it tonight and see how I go.

I will also have to investigate what you are saying.

But from my initial testing, it seems that if I update a .lvclass and refresh the icons, then the memberVIs automatically update to include the parent banner (or part of) without me doing anything different.

I think it will be ok because the child icon does not "see" the parent icon when using the Icon Editor on a class.

It is only the memberVIs that do and they only have one NI_Library layer.

Cheers

-JG

<edit>

If anyone else hasn't see the effect here it is:

</edit>

Yeah, all of them unsuccessful so far.

Damn. I am running into cases where passwords will be a pain, but I really like that I set it all from the build spec.

I am thinking that maybe using a universal password for each library/vi in the release.

That way I get the nice effect of "warning! - this is a reuse library enter a password"

They then will be able to enter it - but then it is on their head.

You're the scripting guru, isn't that property exposed?

Ah, negative! I only have my ninja yellow belt

(Probably ought to be on the idea exchange, eh?)

I reckon

I have some code here written by a previous developer. Once in a while I'll stumble upon a vi that can only be opened with a password. And of course, I don't know the password. I have to delete the vi and recreate it the best I can.

Trust me. Judging by what I can read from this guy he wasn't that clever.

Well, if your company is using passwords internally then of course they need to be managed.

Too late now for you tho!

Even if you do not like them, there is still the use case of distributing code external to your company (i.e as a product) and the need to protect your IP that needs to be addressed.

Passwords seems like the only viable option (at this stage)

Nope, I don't use passwords at all. I do lock the libraries, but no passwords. Nothing I distribute to users contains confidential IP they are not allowed to see. If a user wants to get in and muck around with the code... that's on them. I can't protect them from their own stupidity.

If the time comes when I do need to use passwords, I would likely start with random passwords. If someone needs to see a block diagram I can always rebuild that module with a specific password for that user.

I had a play with just locking, but I found it wasn't that great for what I was after:

• It seems I can edit a VI if the library is locked without a warning (so a library member does not inherited that property from the library) - I have to lock the VI
• I cannot alter these settings at build time - meaning I have to manually lock everything then build, which is a pain during edit-time
• Adding passwords is easy because I can do this at the top level folder and it is inherited down the chain in the build spec

Do you have any experiences getting around this?

Cheers

-JG

Nice! I hate trying to get the colors to match up.

Edit: There are a couple package dependencies you didn't set.

OpenG's numeric library

JKI's State Machine toolkit

Cheers!

They are in the .vipc file in the zip file, but I forgot to add them to the .ogpb file!

No problems, I have a VI for that, I will do the fix now.

<edit>

Done!

</edit>