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) 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) 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) 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 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 you're right Ton! I should've done a test first. QUOTE (Antoine @ Jul 8 2008, 10:59 PM) I'm not sure this can help but I think that sometimes the "call chain" primitive gives you what you would expect from "current VI path" primitive. I think I saw that in LV 6 or 7 with vit. 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) 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) 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) :thumbup: Is there a reason you chose VMWare Fusion over Parallels?

QUOTE (Daklu @ Jun 20 2008, 10:37 PM) 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) How do I find the class the object is instantiated from at runtime so I can convert the variant into the right data type? 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) I'm also puzzling over how to present the data and options that are specific to each battery to the user. Sub panels? 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) 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) 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) 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) 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) Aww come on, don't you want a refresher course

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM) 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) Please edit your article to specify which versions of LabVIEW are capable of creating these corruptions so that future readers don't continue to wonder if these are issues. It's irresponsible, in my opinion, to post an article such as this one without providing the version information. This article will still be available for reading -- and thus indexed by search engines -- years from now. Without a version number, this article becomes a source of FUD. 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) Your article opens with "a recent post on LAVA made me realize that this may still be useful." I'd just like to point out that the recent post on LAVA that you cited explicitly mentions that, no, he is not using LV Classes. If you know of any way by which the project and or class files can become corrupted that is not addressed by LV8.5.1, please report them ASAP so they can be fixed. 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) 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) 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) 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) 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) 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.