Aristos Queue

Did you tell the project to put the class files inside the EXE? The only ones that are inside the EXE are those that are used by the Source files. If you want other files to be included in the EXE, add them to the bottom section where it says "Always Included".

QUOTE (paracha3 @ Jan 21 2009, 01:33 PM)

I have base class with two child classes following the factory pattern and use of "Get LV Class Default Value.vi" for dynamic loading. For my built app, i include two base classes into EXE (under "Source Files:Always Included" section). What i am seeing is that after the app is built, i see two folders next to exe with only dynamic VIs in them but no .lvclass which is what i need to load the class by its path name.

Where is child1.lvclass and child2.lvclass are? in exe? I need path so i load it in exe.

The .lvclass file is inside the .exe, along with all the other VIs. You should be able to do dynamic loading of it by taking the current path from your top level VI and appending "..\classname.lvlcass" onto it, just as you can for creating the path to any VI inside the .exe.

*grumble grrr*

LabVIEW's expected behavior is "if we detect two VIs of the same name in different classes then just assume that those go in a folder next to the EXE, with subfolders for each class." You shouldn't have to specify any paths to save the VIs to special locations -- including the class in the build should be sufficient and LV should handle the saving to a folder beside the EXE. And you will get the build warning that the VIs were put next to the EXE instead of inside the EXE.

Disadvantages 1 and 2 are thus expected behaviors and there's nothing you can do about it.

As for disadvantage #3 QUOTE

3 can't really good call dynamicaly some VIs, have always to check if it's a standalone or IDE execution

Now, having said that, I am sick and tired of this behavior, and I will seriously contemplate doing everything I can to hold the LV CD from being shipped to customers if the next version of LabVIEW doesn't allow multiple VIs of the same name to be stored in the EXE. The feature/bug fix (depending upon your point of view) is finally getting attention. I still can't promise it will be fixed because unforseen difficulties can put the kabosh on any new development, but I'm putting all the pressure I can to get this fixed.

Yes, as of 8.6 I have also noticed it acting odd... it would seem that some spots on the frame of the subpanel will actually open the block diagram still, however finding those spots can be a pain. Most of the time when you bring up the menu and select Open Block Diagram it just acts unresponsive. I haven't gone thru the buglist yet, so it may be documented already.

Yes, as of 8.6 I have also noticed it acting odd... it would seem that some spots on the frame of the subpanel will actually open the block diagram still, however finding those spots can be a pain. Most of the time when you bring up the menu and select Open Block Diagram it just acts unresponsive. I haven't gone thru the buglist yet, so it may be documented already.

I asked your question of the person who developed the File I/O functions for LabVIEW. The answer:

"Unfortunately there isn't any built in way to do that. The suggestion he already got (to use system exec.vi) is the easiest way I know of."

For the OS itself, shortcuts are files.

For the OS itself, shortcuts are files.

Please post the CAR here so I can track it. Thanks!

Please post the CAR here so I can track it. Thanks!

Another NI employee who read this post has just let me know that, yeah, he saw something like that once, in LV8.6. He also cannot reproduce the issue, although in his case, it happened to many classes when he did some batch processing on them.

This isn't enough info for me to even file a CAR much less debug the problem, but I'll keep my eyes open when I'm working on other CARs related to saving and/or property editing for problematic code snippets.

Another NI employee who read this post has just let me know that, yeah, he saw something like that once, in LV8.6. He also cannot reproduce the issue, although in his case, it happened to many classes when he did some batch processing on them.

This isn't enough info for me to even file a CAR much less debug the problem, but I'll keep my eyes open when I'm working on other CARs related to saving and/or property editing for problematic code snippets.

I've never heard of this bug. I could not replicate it in 8.2 or 8.6. Is there something special about the particular class that you are updating?

I've never heard of this bug. I could not replicate it in 8.2 or 8.6. Is there something special about the particular class that you are updating?

QUOTE (Aristos Queue @ Jan 7 2009, 05:03 PM)

This bug has been confirmed in LV 8.6. It has been filed as CAR 139602.

This bug will be fixed in the upcoming bug-fix release of LabVIEW.

QUOTE (Aristos Queue @ Jan 7 2009, 05:03 PM)

This bug has been confirmed in LV 8.6. It has been filed as CAR 139602.

This bug will be fixed in the upcoming bug-fix release of LabVIEW.

This bug has been confirmed in LV 8.6. It has been filed as CAR 139602.

How do you resolve the conflics if you cannot turn off the autopopulating folder when resolving conflicts? Not only every referenced VI has two versions but also every referring VI has two versions.

Have any of you filed a bug report? If not, please do so with VIs/lvproj files attached that reproduce the bug.

A logical impasse exists between two highly praised LV features: the autopopulating folders in the project and the cross-link detection/resolution tools. Both of these came into existence in LV8.5.

(Author's Note: I should mention that both of these features are highly praised by people who only use VIs, not by people who use both VIs and libraries, but we're working on that...)

Situation:

Alpha.vi and Beta.vi both call Gamma.vi as a subVI. Alpha wants to load c:\Gamma.vi and Beta.vi wants to load d:\Gamma.vi. The conflict is between two VIs of exactly the same name but at different paths being listed as part of the project. The user needs to either pick which Gamma.vi to use in the project OR remove all references to all but one version of Gamma.vi, making that one the only version of Gamma.vi listed in the project.

The trouble arises when the user tries to pick which Gamma.vi to use. Suppose that the project has an autopopulating folder for c:\, but the user says "Use d:\Gamma.vi for this project." (This reportedly happens somewhat commonly.) The project cannot get rid of c:\Gamma.vi because the file is in the autopopulating folder and the project has been told to keep everything in that folder up-to-date.

And so, with this in mind... please answer the questions.

QUOTE (Jim Kring @ Jan 3 2009, 02:19 PM)

> suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards

Only if one used improper settings that allowed the .svn folder contents to be included -- the .svn folder contents should be exclude-able in the build spec scheme.

The general pain that I'm describing is caused by the fact that you can only "build" things (exe, zip, installer) from sources that exist in your project. Building a software product typically involves several cascaded build steps (in most situations this is an EXE, followed by an Installer, followed by a ZIP file). The project environment bonks when it can't find project items. And inputs to a build step generally don't exist until a prior build step completes -- this is why, IMO, it doesn't make much sense to require that items exist in the project in order to build them (since the auto-populating folder scheme is so "dumb" in how it auto-populates). Plus, projects (and auto-updating folders) don't update/refresh between build steps. Maybe you could use multiple projects, but this is also a bit of a kludge and means that you can't build in a single step -- it also means that you can't open a downstream project until an upstream project is built. Bottom line: using the project environment to build any non-trivial software product is a painful endeavor -- you should http://thinkinging.com/2008/05/27/a-dogfooding-challenge-to-ni-use-your-application-builder/' rel='nofollow' target="_blank">try it sometime

Ah -- chained building is an entirely different beast. Chained building is a feature I'd support. But the base source files for any link in the chain should all be in the project or another project pointed at by this one. That way every link in the chain is managed by a project file that is very explicit about which source files should be pulled into the build.

I only used the 8.x builder once, but I've also felt the need at least to be able to browse to select files to be added to the build. For instance, why would I want to have the icon for my application in the project? I'm only interested in it when I go to build the app. I understand the logic behind this (it's part of the project, it allows to show missing items, etc.), but in this example it simply disrupts the workflow (I go to build the app. Oh, I need an icon. So, a minute later I created one and now I need to add it. Now, where's the browse button?). It might be easier if we had a browse button in the relevant sections of the builder which would automatically add the selected files to the project.

QUOTE (Jim Kring @ Jan 2 2009, 06:34 PM)

Yes.

Why? Wouldn't that make the situation described here worse? You would conceivably have a project that works perfectly well in development, then you build an EXE and suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards. What can you pick up in a build spec that you cannot pick up in the project itself?

QUOTE (Daklu @ Jan 2 2009, 07:55 PM)

Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh:

QUOTE

It's not the compiler. If we pull those out, we can get rid of the "DoNothing.lvclass" entirely. And the loop wouldn't wake up to try to do the "Enqueue Element" just because you typed in new numbers.

QUOTE (Michael_Aivaliotis @ Jan 2 2009, 05:00 PM)

I have a project file that always shows an asterisk (like there are unsaved changes) every single time I open it. If I save it, then do a diff on the project file it doesn't show any changes.

Seriously though: The only bug like this that I've heard of for projects involves autopopulating folders. X.lvlib owns A.vi. A.vi is saved in a directory which is autopopulated in your project, but the library is not saved in that directory -- it's just a part of the project. So the project loads up, loads the library, then it starts populating the tree, and it includes the VI, and the library says, "Hey! That's mine, you can't have it!" and it tries to go with the VI, but the autopopulating folder says, "You can't come in here! You're not in my directory, Mr. Library!" They have a war which someone eventually wins but in the meantime the poor project gets hit with a docmod.

Autopopulating folders: The only way to win is not to use them.

Of course, this may not be applicable to your problem, Michael. It's the only case I can offer today, though.