Omar Mussa

Is it possible to launch multiple instances of an EXE built by LabVIEW App Builder?

QUOTE (Nighthunter @ Jul 15 2008, 01:31 PM)

Is there anny way to save those annotations?

Annotations are just a property of the graph (an array of clusters). You can save them but you have to write the code to do it yourself (there is no NI built in way to save/recall annotations).

I was looking for some good style resources for presenting at NI Week and I found this awesome presentation.

QUOTE (JiMM @ Jul 12 2008, 08:29 AM)

Why would delivering an exe or password protecting the BD not accomplish this need?

1) Delivering an exe is not always possible (you could be delivering an instrument driver for example).

2) Password protection works as long as you trust that nobody has hacked the LabVIEW password protection scheme. Jim Kring wrote an excellent article http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' rel='nofollow' target="_blank">here.

QUOTE (Val Brown @ Jul 11 2008, 06:24 PM)

But don't forget, there can be situations in which BAD code (re: style) is actually GOOD.

I don't think code obfuscation is the same as 'BAD' code and is not what the article or my post were trying to talk about. The code I'm talking about is the code that anyone who is a professional LabVIEW developer has seen about N times and that many non-professional LabVIEW developers end up encountering too, which is code that is poorly written and poorly documented and on top of that does not follow the LabVIEW style guides in any way so you end up spending time trying to figure out what the developer is trying to do.

Personally, I am not sure I am in your camp on this one. I'd rather inherit code that I can understand quickly and easily that doesn't quite work right, then code that works well that I can't comprehend. Maybe its because I assume that I have the technical abilities to sort out the issues of code that is well written but not functional. I find that code that is not well written tends to become un-maintainable really quickly, and IMO un-maintainable code is basically dead code that will end up getting re-written in the long run or just dropped altogether because nobody can figure out how to use it. I've had countless projects where I've been forced to 'figure out' the intent of the original developer that used bad style and then refactor the code into a maintainable form. I don't know that I've ever had a project that followed all of the coding style guidelines that I had to get 'working'. In my reality, there are few times when you find really clean code that isn't also really well designed code.

I would like to quote Jim Kring on this:

QUOTE

Your code looks great, but less of it would look even better

Also, many of the style guides -- good documentation, etc. are essentially there for (at least) two reasons: 1) to make it easy for others to understand your code 2) to force you into a workflow that compels you to write higher quality code.

I think one of the key issues that is implied here is that style and architecture are somehow seperable. I don't find that this is the case very often. I think that if you are going to follow best practices and have good style, etc. you will generally be compelled to choose an architecture that is scalable and maintainable and write better code as a result.

QUOTE (Ton @ Jul 8 2008, 09:34 PM)

I think this will get you an error, because the FP is not open.

I think you're right Ton! I should've done a test first.

QUOTE (Antoine @ Jul 8 2008, 10:59 PM)

If you're trying to use the call chain to get the reference to the current VI, you should use the VI Server Reference - 'ThisVI' constant from the Application Control Palette. It will work with re-entrant VI s to get the reference of the current instance (I use this a lot).

QUOTE (Aristos Queue @ Jul 8 2008, 07:48 PM)

Does anyone know of an easy way to say, "Hey, dumb clone, open your FP in the same place as your original"?

Just set the VI.FrontPanel.Position property prior to invoking FrontPanel.Open method within the VI. I think that if you don't do this, you'll always get the staggered behavior.

QUOTE (JFM @ Jul 8 2008, 01:41 AM)

Using conditional terminal;

Length of the indexing input is not necessary equal to the Length of the indexing output, unless all iterations are completed.

This is actually a really useful feature of enabling the conditional terminal in certain cases (for example, autoindexing an array of strings UNTIL an empty string is found, etc).

Is there a way to tell if a VI is executing? I know that I can get the Execution.State property to tell if the VI is 'reserved' for execution (state=running), but is there any way to tell if a VI is actually executing?

A strange thing happened to me yesterday. I worked in LabVIEW for an entire day without it crashing :thumbup:

The only problem was that this was because I was working in LabVIEW 7.1. I realized that I've become so used to LabVIEW 8.x crashing, hanging or otherwise requiring me to kill the tasks that I'd forgotten that once upon a time LabVIEW had a stable development environment.

I hope that these experiences can be found in future versions of LabVIEW (8.6?) but for now I have a feeling that I'll continue to need to keep the following command line text handy:

taskkill /f /im labview.exe

(Kills all LabVIEW Windows tasks immediately)

QUOTE (Justin Goeres @ Jun 23 2008, 01:24 PM)

I'm pleased, therefore, to announce the arrival of my shiny new 17" MacBook Pro. The plan going forward is to do my development under Windows via VMWare Fusion, but to have the door open for forays into the Mac world as opportunities present themselves. I'm also a natural-born Mac user from way back and I've missed my old Power Mac G4 ever since it bit the dust a couple years ago, so it's good to be Back Home.

:thumbup:

Is there a reason you chose VMWare Fusion over Parallels?

QUOTE (Daklu @ Jun 20 2008, 10:37 PM)

Labview doesn't directly support virtual (must inherit) vis so I was wondering if there is an "official NI recommended" way of accomplishing this?

One way I saw at an NIWeek presentation that I liked and copied is to make all the 'virtual' methods raise an error if they are called directly. I can't remember who the presenter was (it was probably 2 years ago) -- the presentation was about processing manure I think -- would like to give credit for the idea.

QUOTE (Daklu @ Jun 20 2008, 10:37 PM)

Check out Tomi's article on LVOOP Plugin architectures -- it shows how to inspect the class for its runtime type.

QUOTE (Daklu @ Jun 20 2008, 10:37 PM)

You could also have a dynamic dispatch VI (a method called 'Battery.ConfigurationDialog' perhaps) that is designed to open its front panel when called and you could basically setup each panel based on the class. Make sure the code to open the front panel is inside the child class implementation and not part of the parent class.

QUOTE (Tom Bress @ Jun 18 2008, 07:42 AM)

If I make a branch and open a project in the branch it looks like the sub-vis are all still linked to the trunk.

Did you do a 'Switch' to the branch? Unless you switch to the branch, you are still working in the trunk.

Typically, the SVN hierarchy looks like this:

trunk\project\...

tags\tag_x\project

branches\branch_x\project

TortoiseSVN will keep your repository pointing to wherever you did a checkout from unless you do a 'Switch' command (it is available from the TortoiseSVN right click menu in Explorer).

QUOTE (neB @ Jun 11 2008, 07:04 AM)

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

I assume that by Action Engine you mean you're using a functional global inside your LVOOP object. What it sounds like you are doing is trying to create a By Reference framework. Search for LVOOP and By Reference or ByRef. There's been a lot of discussion on LAVA related to this topic.

The short answer, creating ByRef objects using LVOOP (ByVal) objects is not defeating the purpose of LVOOP. There is even a shipping example that shows how to do it (ReferenceObject.lvproj).

QUOTE (neB @ Jun 9 2008, 12:56 PM)

PS: please excuse my dumb questions on LVOOP. I have been reading and I'm trying but OO is still a forign language. Learning the machine instruction set of a KL-10 seems easy to getting this old hardware guys head around the terminology.

There are some good links to documentation on the LVOOP wiki here:

http://wiki.lavag.org/LVOOP

QUOTE (neB @ Jun 9 2008, 12:32 PM)

Whenever I set any of the VI within that class scope to "private" the class breaks (they all dynamic).

Haven't looked at your code but FYI private VIs cannot use Dynamic Dispatch. I think that is your problem. This is a desired/expected behavior. You wouldn't expect private VIs to allow ancestors to override them.

QUOTE (crelf @ Jun 4 2008, 03:43 PM)

I still get emails for Basics I and II courses...

Aww come on, don't you want a refresher course

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

Your article does not specify what LabVIEW version can create these corruptions. There were two corruptions known in LV8.2, both of which were fixed in 8.2.1. There was one corruption associated with 8.5 that was fixed in 8.5.1. I do not have any open bug reports of any corruptions since then.

I don't think it matters 'how' classes or projects get corrupted. I was trying to mostly point out that there are aspects of classes (and projects) that if corrupted are irrecoverable. A VI can similarly get corrupted (call it the neutrino effect) but it happens (though luckily very occaisionally for VIs). The point is, unless you are using an SCC system while you're making changes to code (especially code that is binary in nature) then you are risking losing your work and not having an efficient way to recover.

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

I've been using 8.5 (I have not been able to switch to 8.5.1 yet) and I've seen the issue related to the corrupt class that I documented in my article appear -- now, you get a dialog that tries to help you recover by asking if you want to 'Add the missing file to the class' but I've seen this operation crash LabVIEW (and I have not reported it -- sorry about that -- I think it mostly is due to my not wanting to try to figure out exactly what the problem is so that I can report it correctly -- am sure I am not alone in this). I will go back to the article and edit some of the version specific info though.

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

I think that what made me realize I needed to finish the article was the fact that the poster was losing productivity due to a corrupt project -- which could have been equally prevented using SCC.

I would contend that it is possible (even probable) that there are still bugs that can corrupt LV Classes in LV 8.5.1 that have either 1) not been reported or 2) not been discovered that will still warrant using an SCC system to prevent loss of productivity. So I think the premise of the article still stands -- use SCC so that you can have less fear of corrupted files.

QUOTE (bpreis @ May 16 2008, 11:47 AM)

The Additional Installers list is built from files found in C:\Program Files\National Instruments\Shared\MDF\Manifests. The xml files there represent the additional installers and their dependencies.

The fact that your Additional Installers page is missing some installers, like the LabVIEW 8.5 RTE, would suggest that the files representing those installers are not present. But since you found those installers in the ProductCache folder, I'd expect there to be a file in the \Manifest folder as well.

I recommend going to Add\Remove Programs> National Instruments Software, then select all and press Repair.

-Bob

I've seen the Additional Installers checkboxes get corrupted to the point where I had to uninstall all of my NI software and reinstall it to get it fixed. That sucks. So now I try to create a virtual build machine whenever I need to create an installer with additional installers included. The 'Additional Installers' feature would work much better if you could force it to point to a specific NI Installer file -- otherwise you can get stuck with it asking for 'Device Drivers May 2006' and you are pretty much SOL if you don't have that exact version (you can't just point it to May 2007, etc.

QUOTE (gmart @ May 16 2008, 09:35 AM)

There is no mention of using the built in LabVIEW SCC integration. Do you use it? If not, why?

Good point, I haven't tried using built in SCC integration for a while. The main reason I stopped was that I have different SCC repositories/servers for different projects and in the past LabVIEW SCC could not handle that. I haven't looked into it for a while but just from quickly looking at the LabVIEW 8.5 SCC options it doesn't look like that has been addressed.

I'm currently using TortoiseSVN from Windows Explorer for all of my SCC operations.

I just posted an article: Fighting Corruption: Using Source Code Control Systems (SCC) with LabVIEW Class Files to ExpressionFlow.com.

The article highlights ways that LabVIEW class and project data can be corrupted and some SCC practices that can help you to recover from them.

QUOTE (Tomi Maila @ Apr 24 2007, 10:15 AM)

Nice

Tomi

I finally got around to doing this so I thought I'd post the http://expressionflow.com/2008/05/16/fighting-corruption-using-source-code-control-systems-scc-with-labview-class-files/' target="_blank">article link here for reference.

QUOTE (Val Brown @ May 14 2008, 02:29 PM)

Thanks for the reply. I can't say precisely in what way they're getting corrupted. All I know is that I go to open the project (either double-clicking on its icon or starting up LV and then using File/Open...) and I get back the message that the project file is corrupted. Yes, I'm aware that they are XML and I can certainly open them even in regular Notepad but I didn't want to do any particular editing as I wasn't at all clear what to change. I'll give a try to removing the items in memory section.

No, I'm not using LV Classes.

I'm sure that it is too late for your current problem but you inspired me to finish writing this http://expressionflow.com/2008/05/16/fighting-corruption-using-source-code-control-systems-scc-with-labview-class-files/' target="_blank">article! You may want to read it even if you're not using LV Classes.

QUOTE (Aristos Queue @ May 2 2008, 01:33 PM)

How would that fix the problem? We're not talking about saving or not saving. We're talking about whether LV should *ask* you to save before the item leaves memory. This is a question of calculating whether the class will be leaving or not. For running VIs, we can calculate which ones will be leaving memory. For a class, we cannot make that calculation until after the VIs are halted *and* already removed from memory. So those VIs have to have already asked about their unsaved changes before we even know if the class will be going or staying.

I was not reading it too carefully I guess. For the record, I've seen strange instances where LabVIEW does not 'save' my VIs even after I hit 'save all' or 'save this class' and I'm in too much of a hurry to figure out if this is the same case at the moment.