klessm1

I think that maybe a tool to analyze dependency links would be helpful.  Not just for this type of issue either.  In a couple of our projects I end up saying "why is that class being pulled in"?  Many times you end up with a "uses a" relationship with another class (static vi reference, passing a class into another class's method).  If you could visually and programatically inspect your class relationship it would be great. I am wondering what Symbio tools would do with the weird setup I had going (we don't use them).  A tool like that would be pretty nice for code reviews.  Just a simple representation of classes, lvlibs, and xcontrols in your project and some red flags for circular references.

If I had some spare time...

Slight restructure worked. I had some weird linkage because of some static vi references. Database class was clean.

So my main GUI class is passed to all main screen guis as data from screens is sometimes shared (they are plugin screens for a sub panel). I could of done it diff but that is what I ended up with. Anyway, the GUI screen vis were part of the main GUI class because they use the main GUI class. For each screen I have another class containing the control refs for that GUI. In the init function for the screen class I had a static ref for that screens gui (which was part of the main GUI class). Throw in the fact that the screen guis have the xcontrol on them and the screen classes have the ref, properties,and methods you end up with a bad situation. Like a two day crash fest.

So I removed the guis from the main class (don't know if it was required..), and got rid of the static refs from the screen init methods (this was probably the root cause). So now that the main and screen classes don't call each other everything seems to be OK. I left the refs as the xcontrol type (not containing data type) and I don't think I'll change it back as everything is working.

Thanks for the inputs. Def will remember the delete ref trick.

Posting here because NI forums is down...plus I found this thread which may have something to do with my problem.

So what if there is a class that both the XControl calls and the Main class calls?

For example, my Xcontrol calls a database class (which calls .net ADO), but that class is also in the dependencies of my main GUI class (which the XControl is also dependency of).

I've been dealing with crashes, bad property and method nodes for the last two days am pretty much at that point where I start posting on forums.

So my GUI class is in charge of getting data from and updating the display (which includes the XControls).  I have the references for the controls I need to control in the class data (which sometimes causes problems when updating the X Control).  Most of the time I just get a bad method or property node and can re-select and save.  I also have a control (not type def) of the reference that I update with the latest reference of the XControl then I apply it to the class data.  Having it as a type def causes way too many problems.

I have also tried replacing the XControl strict reference with a regular control and used the "to more specific class", but that didn't work.  The references were still called by the GUI class.

What I am thinking of doing is removing my main GUI panels from my GUI class (floating VIs), and create a messaging system to another stand alone VI that would contain all the methods and properties I need to access for the X controls (which defeats the purpose of having these nice methods and properties).  It is probably going to hurt a little (timewise), so I am looking for some wise guidance.

Info: Using 2012 SP1f2 32bit on Win7, Most vi's have separate compiled cache set.  Clearing cache before loading (usually have to load XControls first then main gui class).  

I have stopped using this tool because the latest version of tortoiseHG will now go through all the files first and then give a list of conflicts.  It also allows you to select local or theirs and can use a merge tool of your choice on individual files (in the case of VI's just use lvmerge directly).

Since the XControl is only being used in my application and in one spot I was able to fudge a little and use the following code. Note the plus 10 which I think is due to splitters or panes not being at origin. I think NI also has a similar issue with their tip strips that has been documented. If you hover over control that is in a paned window that is in a subpanel you will see it. The location of the tip strip can vary and to get it in the correct place you have to scroll the pane. Maybe this is fixed in 2012, but haven't switched from 2011SP1 yet so I'm unsure. Anyway here is the code that seemed to work good enough for me to get by.

I am writing an X control that launches a popup that I want to place in reference to a control that is part of the XControl. It worked ok when the X Control was in a normal VI (even with multiple panes), but when that vi is in subpanel it always shows up in the same location. It gets the same "panel coordinates" everytime regardless of where the top level vi is placed, but changes when the subpanel is moved on the front panel of the main vi. It seems like I need to go one more level up, but so far have been unable to find a way to do that. It is almost like instead of "owning vi" I need the reference of the subpanels owning vi.

Here is the vi I am using. The vi with the magnifying glass recursively searches for controls within controls (e.g. clusters, tabs). Basically it finds the pane the control belongs to then finds the panel coordinates and then the screen coordinates.

Does anyone have a trick to make this work for subpanels?

Much Thanks!

I did a quick search of the website but I didn’t see something like this posted so I’d thought I’d post it. It’s probably been done before but I found that it pretty helpful in my current project.

I usually use DVRs whenever I want to use the aggregation pattern (zero or more relationship). Many times though I want to sort or return an object from the array based on an attribute in the object (like name). Since I am using a DVR I found I can quickly make a hash table using variant attributes. I just use the “Name” or other unique value and make the DVR the value. I can then lookup a DVR by name through the variant. It stays really fast because the DVR is just a reference to the data and I am not looping through DVR references and comparing the name or unique value to the value in the object.

Example use:

I can lookup these commands by name or opcode using the variant hash table.

I create the lookup based on name.

I also create the lookup based on opcode

I can then lookup the object very quickly based on name or opcode.

Question posted on NI's site. Thought I would list it here in case you don't check NI's forums and you have an answer for my question!

http://forums.ni.com/t5/LabVIEW/Setting-quot-Scale-Objects-While-Resizing-quot-programmatically/td-p/1970005

I am thinking of sharing this API after I get this figured out because it makes collapsing / expanding panes a breeze. Is there is a different \ easier way to accomplish this?

I have attached what I have so far in an example vi.

MessingAroundWithSplitters.zip

I mis-wired the unbundle, but that occurs after VData to Cluster function.

I ran into an interesting issue with the Array of VData to VCluster when using XControl references as part of the VData. It looks like it puts it together correctly into a cluster, but when trying to type back to the XControl reference type it throws an error. You can convert it back to a normal control type, but when doing generic sets on controls in a cluster that method doesn't work very well. LV2011, Latest verison of the library.

Screen shots here and code attached. I actually tried it with a couple different XControls and it didn't work.

I wouldn't think that this behaviour is normal, but maybe there are some known restrictions when using XControl references? The references themselves seem a little weird because I did a source build on the project and it changed the type of controls in the "new" cluster constant when LabVIEW compiled it. They were just normal control references made from scratch in the source code and then in the build it changed them. They still said "Control" but when you clicked on them to view the ActiveX class they had Control and MRUFilePath selected. Weird.

Anyway, I can probably manually cast these values, but the whole reason behind my method was I just had to add the control ref to a cluster in a class and input the refereces as a variant array and It would load them...no custom loading of the clusters.

XControlRef.zip

Great API.

Couple comments and suggestions.

I was using a couple of panes in my application and so the locations got a little messed up. I modified it so it could register pane mouse down events instead of vi mouse down and it works pretty good.

Although I don't have a current need I noticed that you can't register multiple controls on the same window or in two windows that are up at the same time.

Finally it seems to take a little bit of time to load because it is using vi server. I am using it on some popup windows and when I switch between step interfaces quickly it is a bit noticable (not really bad, but should be almost instant). I tracked it down to the init call where it launches the vi dynamically. Possible update could be to run as a daemon?? It could solve the time to load and the multi-control / window open at the same time.

I was going to post on the NI site, but they have one huge LabVIEW forum so I though it might get lost. Was not aware that every post was read there. Thanks for the information and for entering the CAR.

I am flattening an array of classes and loading into an MSSQL database in an XML column. When the XML is returned it is formatted to take up less space. Which means a line of "<Cluster></Cluster>" becomes "<Cluster/>". When returned in this manner I get an error:

1403

LabVIEW: Attempted to read flattened data of a LabVIEW class. The data is corrupt. LabVIEW could not interpret the data as any valid flattened LabVIEW class.

Lines that have <Val/> and <Name/> work ok. It is only the custer tag that has the issue. I have attached two xml files...one with <Cluster/> (doesn't work) and the other with <Cluster></Cluster> (works) for reference.

I am hoping someone at NI will take a look at this and enter a CAR if necessary because it just seems to be an overlooked item that doesn't happen much. This seems only possible with classes when a child class is empty. I don't think an empty cluster outside a class is possible.

The work around is to perform a search and replace of <Cluster/> with <Cluster></Cluster>. Easy, but shouldn't be necessary.

Using LabVIEW 2011.

BeforeReplace.xml

ClusterReplace.xml

Cool, yep, its meant to do that.

Cool, I will try to fire up 2011 later on and check too.

OK... so at the end of all this... is the behavior now what everyone would call "correct"?

If yes, does it match the documentation?

If no, what still needs tweaking?

Finally got around to checking it without recompile and it works as expected for me. Private function has an X and the public functions do not.

I did not try that yet.

I did however realize that the red X on the property node vi was because I had made it a private function. I will try it without compiling, but will probably do it tonight.

Recompiling in 2011 worked. The only vi with a Red X now is the property node which is a broken vi because I don't have the class going into it(setup for place vi contents).

Thanks for the information guys. I guess I should have searched Red crosses and not Red X. It was late, sorry.

I will try it in 2011. Maybe resave all of the menu files when I do incase they fixed it in the way they are saving the menu files themselves. I'll let you know if resaving works.

Thanks again.

Has anyone see this and know why it occurs?

Using LV2010.

Tried the menu's in the lvlib and the lvclass.

The examples show up ok (assuming because they are outside the library).

Default palette set for the lvclass to dir.mnu.

The vi's drop out of the palette ok...they just have the X on them.

I am using the lvlib because I am giving the option to build a packed library. It is really slow and hogs a bunch of memory in the development environment though when I am working with it so I just went to a source distribution. Might try 2011 to see if they optomized it.

Thanks

You are correct as it is not really "code" it is an application. The code will not work unless it is compiled into an EXE (mercurial cannot call a vi directly). It cannot be run as source nor is it useful to call it as source from another application (not an API). Thought I would make it easy on users by not requiring them to download and compile the tool in order to use it. I for one dislike downloading free applications from the web that do not have a compiled application packaged in an install.For those looking to make updates to the source code and performing their own builds, they can contact me via PM and I can send them a link to a public mercurial repository that they can pull down.

I will put a warning in the description.

Got the go ahead from my employer to post LVMergeHG. It is now posted in the code repository on lava http://lavag.org/files/file/164-lvmergehg/.

Let me know what you think.

Name: LVMergeHG

Submitter: klessm1

Submitted: 02 Feb 2011

File Updated: 03 Feb 2011

Category: *Uncertified*

LabVIEW Version: 2010

License Type: BSD (Most common)

Copyright © 2011, G System Solutions LLC

All rights reserved

Author:

Michael Klessens

Contact Information:

PM on LAVA

Issue Reporting or Feature Requests:

http://gsystemsolutions.fogbugz.com

Report under LVMergeHG project

Note:

Due to the nature of this package it does not contain source code (it will not run as source code). For those interested in obtaining the source code for their own builds please contact me via PM and I will point you to the location of a public mercurial repository.

Description:

LVMergeHG will enable users to perform multiple file merges with Mercurial either directly or through a client like TortoiseHG.

It is configured as an external merge program for LabVIEW files that can be merged with LabVIEW's built in merge tool (LVMerge).

Features:

1. Mercurial waits for an external merge program to exit before it will continue to the next merge item. LVMerge exits and launches a separate merge utility before a merge is completed. LVMergeHG acts as a buffer between Mercurial and LVMerge and waits until the LabVIEW merge is complete before it closes.

2. Mercurial downloads merge files in directories other then the target directory. LVMergeHG moves the temporary files into the target directory and removes them when finished. Note: This feature may not be needed if separating compiled code from source in LabVIEW.

3. LVMerge does not handle a two way merge automatically. LVMergeHG asks the user to pick which version (mine or theirs) to use as a base version and uses the selected items when calling LVMerge.

4. LVMerge does not auto select the version of LabVIEW to use for merging the vi's selected. LVMergeHG tells LVMerge which version to use based on the version used to last save the vi.

If the exact version is not found LVMergeHG will find the next highest version of LabVIEW to use. ***See caveat 4 below.

Requirements:

1. LVMergeHG uses LVMerge so a LabVIEW license that supports LVMerge is required (LabVIEW Professional Development System and above).

Recommendations:

1. Install Mercurial first. LVMerge installation will try to configure LVMergeHG's settings on installation, but it can be reconfigured at any time using ConfigureLVMergeHG.

2. Set VI settings to remove compiled code from source. LabVIEW won't require sub vi's to be present at the time of merging when this is set (no search windows).

Caveats:

1. LVMergeHG does not override some of Mercurial's automatic merge decisions.

For example:

You have a vi in one branch that hasn't changed since the base and you deleted it in another branch.

You merge the two branches and Mercurial will assume you want to delete the file without asking because that is the only change.

LVMergeHG sets the premerge configuration to false, although this doesn't seem to effect this merge decision.

Solution is still in development.

2. LVMergeHG is only supported on Windows Operating systems (XP, VISTA, Windows7).

3. LVMergeHG has only been tested with LV2010 although it will most likely work in other versions.

4. LVMergeHG tries to set the version of LabVIEW that LVMerge will use based on the version read from the vi.

However if two versions of LabVIEW are open LVMerge doesn't seem to load the compare in the correct version.

It is safest to only have the version of LabVIEW open that you want to use or not have any version of LabVIEW open.

Click here to download this file

I've read up a little bit on the GPLv2 and it's not that hard of a license, and if you create an executable (thus stripping the icon of the VI) you should be able to use a more general license.

The nice thing of the GPLv2 is that it's in the spirit of OpenSource software, it enforces the next-generation of your source-code to be open source as well.

Ton

Thanks for the info on GPLv2. I went and read up on it as well. I am checking with legal as I created some of this tool while at my full time job. Need to find out about copyrights and if they will even allow me to post it. I'm pretty sure they will (they are not in the software business and this tool will not help their competitors). In the meantime I am going to test it with a couple versions of LabVIEW to make sure it is compatible. I've only been testing it with 2010. I've tested it on an XP Pro OS and a 64 bit VISTA (yeah!!! ). I don't have LabVIEW loaded on my Win7 machine but I am pretty sure it will install and work on Win7 if it worked on my VISTA box. I think it is ready for distribution, I just have to get the go ahead.

Thanks for your patience.

One thing to remember is that Mercurial itself is licensed as GPLv2+, this license includes the Mercurial logo. If you are just calling the Mercurial command line interface you don't need to use the GPLv2+ license.

Ton

It would make sense to use their logo as part of mine for the application, but didn't want to open that can of worms...

I am actually not even interfacing with Mercurial, only with LVMerge.exe and the Mercurial.ini file.

So would the BSD apply to an exe distribution? It is not really meant to run as source code, but as an interface application between TortoiseHG and LVMerge.

I am thinking GPLv2 might be the correct way to go anyway???

Depending on how useful and how many features I can put in it I may want to charge for a full-featured version.

Also to be able to put it on the VI Package Network do I need to use VIPM to package it? I was going to just zip up an an install for it so it can auto configure the mercurial ini file to point to the program.

Let me know what you guys think. Thanks.

Working on the installer and icons now...

Sorry I got sidetracked with a "real" project. I think I am about ready to submit the merge tool, but I need some input on the best way to package / license it. I am thinking about just releasing it as an executable and possibly providing access to the source in a public kiln site. So would an EXE fall under BSD or GNU?

So I guess my questions are:

EXE? Installer?

What kind of license for an EXE?

Would a mecurial repository of a source distribution be ok for those that want to check out the code?

I also made a public fogbugz project for LVMergeHG so users can submit issues.

I hope to have a alpha version ready by the end of today and posted. For right now I am just trying to get something that I can use to merge 10 files from two heads so I can get going on a project (also a good test case for this tool)...may not be the final implementation but maybe others may be interested in helping out.

It is not a very large project so I don't know if I want to post it in the public domain of my Kiln site or not...

I'll let you know.