jgcode

Here's some info on the post build hook.

http://forums.jkisoft.com/index.php?showtopic=839

I don't know if there is similar hooks for post install. I didn't know that VIPM supported post install hooks, are you sure you mean post install?

Remember that the post build VI does not get brought to the front, or focused when it is ran, so if there is some user interaction you'll need to use a Windows DLL to bring it into focus.

Hi Hooovah, thanks for the VIPM link.

I use these VIs and have them as templates in my library.

But yes, I am chasing information on Post Install Hooks.

The reason is I am trying to install files in a path that must be resolved at the time of installation.

If the path is resolved at the time of the build then the path is set to the computer that builds the package.

And this is a problem.

I want to package up the files but then get access to them and install them myself in the resolved location.

Given that is what I am trying to do, is there a better way, or is Post Install Scripts the way to go?

Alternatively I am thinking a Pre Install script may work, where I can edit the .OPGB file with the resolved path.

But I was hoping for a lead into any data that is passed between the Installer (VIPM) and the Hook VIs.

As they are included in OGPB I assume VIPM supports them. Maybe it is a good idea that I post there and ask!

Cheers

JG

Not sure if there is a better way. But if you try to load it into a sub-panel and it is already in one, you will get

Error 1145

Possible Reason(s)

Labview: Cannot open VI because it is already in a subpanel control.

If its not in memory, it will succeed, and if its already running but not in a sub panel you get

Error 1144

LAbview: Cannot insert VI in subpanel because VI is already open.

Cheers, but its not that I want to load it, I just want to know when the VI tests itself - is it the "active VI" in the subpanel out of a possible number of VIs at a given time. So if it isn't I don't want any actions to be performed, so unfortunately this will not work for my task. Thanks tho.

<edit>

Ok had a thought and it worked

The Front Panel:Open property is True when the VI is loaded in the subpanel

False otherwise

Easy!

Problem sorted

Cheers

</edit>

Is there a way for a VI to tell if it is currently loaded in a subpanel?

Maybe a property?

Anyone know?

Cheers

JG

Thanks Ton

Are you able to eloborate on this?

Checking the pre- and post - install VIs should be done with the source code of OpenG commander.

However I think that VIPM tries to read the 'error in' and 'error out' controls if they are available.

Post Install Script info is what I am chasing.

Have you done one before?

Is there any way to access to the package file path (or is this done relative to the Script VI)?

Would anyone be kind enough to post any links to documentation etc.. about the OpenG Package Builder.

I am particularily interested in Script VIs (or hooks) and if there is a template available and if there is/what information is passed to the template.

Regards

JG

Why choose? You could decide to study scripting LVOOP!

Just out of interest to you program for NI on a Mac?

I don't want to be JUST a curmudgeon but, as the OP, I'd like to remind everyone that we began this thread with the following problem, after a "successful build".

No, I believe the thread began with this:

OK, so has anyone else had problems with transferring projects from 8.6.1 to LV 2009?

Sorry you haven't got your original questioned answered yet, but I believe the above was healthy discussion on issues regarding the build script, changes to the internal structure in 2009, and problems with transferring an 8.x to a 9.0 build.

I tried to start another topic, but it was answered here so, I in turn, responded here. The mods can move it if they want. Just wanted to let you know there was no intentional high-jacking (well at least on my part )

Cheers

JG

HP's are notorious for bloatware. Mine included.

Great point! I stay away from their peripherals too due to this reason about their device drivers.

I had a VIAO that served me well for 6+ years, but I think they are a little expensive for what you get.

We had Lenovo's at my last work place and they were great (although again a little expensive compared to Dell).

We currently use Dell at this job and they seem to run fine and are cheap. The boss and admin use Apple.

One LAVA topic that comes to mind is that when people discussed this they said you should make sure you work PC has the same res as your home/remote PC (in this case both laptops). Makes coding life easier.

In practice we haven't needed to create SVs from scratch at run-time yet.

I thought you might have, as this method of generation lends itself very well to an OOP architecture.

Having said that, I haven't had the chance to design any apps like this, but I have been lucky enough to do maintenance on ones that have.

And I can see the benefits are really cool.

What do you mean by your source tree is well defined? What I suggested doesn't require you to change your source layout. All you'd need to do is change the destination directory in the build spec to a shorter location (ex. C:\temp). That should reduce the destination path lengths. If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location.

Yes sorry, we have been evaluating 2009 (and it looks like we are going to upgrade now) so I have been playing with stuff so that is why I did a drag and drop to the desktop and was happy that it solved the problem.

As for the Source Tree comment yes, sometimes (if thats how I want to do it for that project) I want to keep my (latest) build under my dist folder which happens to be a defined folder structure under the Source Tree. I would prefer to avoid the build to C:\temp (or where ever) and copy and paste back under the Source Tree to check the build in, or for other reason mentioned.

However, from all the discussion and even more playing around I have been doing, I have come to the same conclusion as you - so I think the solution above is the way to go. The reason for this is, even though I still think it adds to a problem, the benefits of having a cleanly built EXE in LV2009 do out way the above (for me anyway). By human nature, I would prefer not to have change the way we do stuff but I think I can overcome that inertia with a little time.

Coz at the end of the day, having no external files in my exe - is just way too sexy (hey that rhymes)

Thanks for your back and forth dialog on this Gmart. It helped me get my head around this new feature.

Is LabVIEW getting slower and slower or my Quad-cores PC?

I have time spare now for LAVA while waitting for my LabVIEW to load, Project to load and creating Executable...

Some people getting coffee while wait, some getting

If i have to do some development on the slow production PC P4 1G RAM sometimes i just want to or

Really?

For me - I have found LabVIEW 2009 to be more faster.

Load time (without palettes) is so quick it blew my socks off.

(I tend load the palettes tho, for Quick Drop etc... so I am happy to wait)

Only thing I have noticed is Dialogs take a little time to open.

But e.g. once the IE has been opened once, it is quick after.

Class Templates Dialog seem a little slower, but I like the new features, plus you can do multiple methods - so it is cool for me.

BTW - Does anyone know if there is a way to load the IE at start up?

How are others finding the speed?

The word "corruption" is scary and not really what is happening during the build. We get an error while building due to OS limitations. Nothing is corrupted. Words mean things and the last thing we need is someone googling this problem and seeing the word "corruption" .

Regarding the long path names, one thing you can do to mitigate the problem is to change your destination directory to something shorter. I know that may not be possible in all cases, but that will buy you some extra characters. Alternatively, you can quit being so descriptive with path names and go back to the DOS days of 8.3 filenames .

While I understand your point on the correct terminology for the masses, IMHO if the build was failing due to errors when porting between PCs then it has become corrupted.

The reason wasn't clear originally and was very frustrating.

Once I understood the issue, I was able to solve it by dragging the top level to the desktop and the build compiled without errors.

Unfortuneatly, our Source Tree is already well defined, so I can't so this, and I state this again, I can see this being a huge PITA.

Whilst I love the change that everything is packed inside of the exe, spending an additional 68 characters to define this file: LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb from LV8.x to LV9.0 when there already is a known limitation of characters is just fixing one problem but adding to another.

As for 8.3 filenames it seems NI prefers to promote descriptive files names

Do not use names like VI #1.vi or Untitled.vi when something like Save Data to Spreadsheet File.vi or Convert Voltages to Engineering Units.vi will do the better job. Try to include action words like Open, Close, Save, Calculate, Update, etc. for subVIs that do something. Use words like Display, Panel, View, Screen, etc. for user interfaces.

http://zone.ni.com/devzone/cda/tut/p/id/5560

I also have no clue as to what the Values property is or what it is used for - all I know for sure is that it is an I32 but when I created an indicator from this property I got a duplicate of the original MC Listbox component but this indicator does not reflect any editing changes done to the original MC Listbox component.

The I32 is the current value of the listbox - it is its datatype.

E.g. if the 3rd row is selected then the listbox = 2 (as LabVIEW counts from zero).

So if you write 5 to a listbox indicator - the listbox will highlight the 6th row.

Answers posted by Gmart in original topic:

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

This is great news wrt to the build.

Internally LabVIEW does not have the same restrictions as e.g. Windows OS.

So whilst the build process may become corrupted, once the EXE is build and if it gets moved LabVIEW can handle the long path names.

Cool

To avoid this problem I would say use the advanced build option of Use 8.x layout.

Are you kidding me! No more files outside the EXE, all those class methods hidden, - I am never going back...never I tell you....

But seriously, the build process failing all the time with long files names is starting to annoy me.

And thats just from evaluation. I am really worried when if comes to out Source Tree too, if it going to be quite deep already.

I can see this being a huge PITA.

Ah, yeah forgot about that. I've updated the code and included a build.

Seems in LabVIEW 2009 VIs will not be remove due to constant folding.

E.g. this VI will be included in a 2009 build, it was not in 8.6.1

destination file paths to get long while building

As always thanks for replying Gmart

What I am trying to establish is - is it just the build were long file paths may be a problem?

And if it passes the build the exe will always be fine?

Or could a situation arise that if LabVIEW tries to resolve a path in an executable (depending on where it is in a folder hierarchy) it could be corrupt due to the limitation of characters in the Windows OS?

[Cross Posted to NI]

I made a post in this topic regarding build errors in LabVIEW 2009.

After thinking about it a bit more I thought it may be worth a topic.

I had some code that worked fine on my home PC, when I moved it to work, the exe would not build due to errors.

The errors coming back weren't that good at explaining the problem

Until I got this one:

Look at the path in the error:

C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb

That path is referring to a VI inside my executable!

This may be a bigger issue that I first thought

So my question is:

If a have a path inside my build that would be relative to the executable and LabVIEW needs to resolve it, could that process fail depending on where the exe sits in a folder hierarchy?

I guess this could have happened before? but it would be more likely now due longer paths!

I am getting this annoying one.

Another project with the same VI builds ok!

<edit>

B*st*rd

Seems it was to do with looong file paths - not that the above told me that

This error info did tho:

Problem sol-ved.

I am wondering if this has anything to do with the new way exe's get built?

Look at the path in the error:

C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb

That path is referring to a VI inside my executable!

This may be a bigger issue that I first thought

They also have huge caveates (e.g cannot be dynamically created at run-time)

It should be noted that the DSC allows this.

There is a question, why use agent? Could you like to tell me the reason?

This is what I was referring to in my post.

Certain functions do not operate in the Run Time Environment.

Therefore you can still create an EXE but you need to use Development Environment (LabVIEW IDE) to do the work.

E.g. Creating/editing a MNU file.

The Agent VI does just that.

Hi Crelf,

My VI is used for modify "Item Path" programmely of an existing MNU file.

Have you tried to build any VI that contains "Write/Read Palette"?

Hi unCLAD

A work around for this would be to build you VI into and EXE so you have a nice GUI for distribution as you are doing, but when you want to do the actually work of editing the menu file, you will need to call an instance of LabVIEW and run the working VIs in the development environment. This will get around having no support for those functions in the run time engine.

Other products do this e.g. VIPM, Sciware GOOP Wizard etc...

Some people call the working VIs Agent VIs and the link might be a good example for you to check out.

Is there a "right way" (or any way for that matter) to call child class methods on a parent object that was stuffed into a DVR?

Like everyone else I've been playing around with DVRs lately, focusing primarily on ways to use object references to simplify various design pattern implementations. Today I identified a behavior that has been giving me fits for weeks. If you create an object reference to a parent object, after dereferencing the parent object there does not appear to be any way to downcast it to a child object or use dynamic dispatching to call child class methods. I built a simple example project with a parent class and a child class to illustrate this.

These show a simple implicit downcast and upcast to static dispatch methods. The downcast not working isn't surprising since wiring the parent object directly into a static dispatch child method breaks the wire also.

Here I tried explicitly downcasting to the child class before calling the static method. There are no bad wires but the run arrow is broken with the error, "Although you can modify the class object inside a reference, you cannot substitute the class object for another object, even if the object belongs to the same class. This restriction prevents you from changing the data type of the object in the reference."

This limitation did surprise me, although I suppose it is consistent--bundling the parent in a cluster and using the in-place structure's unbundle/bundle elements generates a runtime error. The difference is the in-place unbundle/bundle elements can easily be replaced with regular unbundle/bundle nodes. There's no equivalent for DVRs.

This is as close as I could come to regular unbundle/bundle nodes when using DVRs The downcast gives me a runtime error. What's really odd is that the downcast works despite the error. If I clear the error the child class correctly updates its private data in the static method and a new object reference is created for the parent. I'm not sure if I'll be able to use this for my purposes but at least it's an avenue to explore. I'm also curious which is the bug: the runtime error or the downcast actually working.

I tried several other techniques as well, but I always either got a broken run arrow or a runtime error. Are there other solutions I've missed?

Hi Daklu

I have been playing with LVOOP and DVR also! It is very cool stuff. I had a look at your post as it is very interesting. I think removing the references to investigate the problem may help to solve the issue. Below is what I have come up with.

Parent cannot downcast to Child as Parent cannot run extended Child methods (Child can always run all Parent Methods) so you get a broken run arrow and that makes sense, any other casting will generate a run time error (see attached png top).

The downcast gives me a runtime error. What's really odd is that the downcast works despite the error. If I clear the error the child class correctly updates its private data in the static method and a new object reference is created for the parent.

When you use the Preserve Run Time Class function I don't think you are getting a new parent, I think you are getting a new child: When the error occurs, all data on the wire is lost and a new child is created. You can then do what you like with the child (see attached png middle). I think the references may be hiding all this in the example you posted as you can have a parent reference pointing to a child object (see attached png bottom).

Therefore I do not think it is a bug either way?

Would you agree or am I totally off!

It appears that if your own post is the last post in the topic, you cannot add another reply. Instead it becomes an edit to your previous post.

Is this a bug or a feature?

Feature for sure.

Stops people from double posting.

They have there place in LabVIEW I guess.

For the stuff I do I rarely use them.

Except for the File Dialog Express VI, I always use that.