jgcode

I revisited this post as someone PM'd me for code. When I looked at the code the UI structure I posted is actually a Cluster of Clusters (not an Array of Clusters as I thought when I just posted a screenshot). So what I wrote was wrong regarding Arrays, apologies - it looks like you cannot have different Ring Strings[] in an Array. The Channels did not need to be dynamic so this was fine as a workaround for this use case. Here is how I updated the ring (there was only one ring, so searching by ClassName was fine in this case, but you could do it another way) in each Cluster to display different Strings[]. Cheers! -JG

Whist this is a great idea in practice, I don't see it working as explained. As ShaunR pointed out, every developer's workflow is different - and what code/tools they prefer/require will vary. Additionally having a large monolithic installation (one single package) does compromise the advantages of modular releases (see elsewhere for discussion) I do however, believe that packages (and the both the LVTN and VIPN) solve the proposed task due to their flexibility Of course, it becomes an issue when code is not released as a package (for whatever reasons). This is something I have been trying to work on with the Team LAVA initiative. Firstly, only packages are used as the deliverable. Now instead of focusing on select packages (as proposed, although it makes sense that popular LAVA packages definitely get published), it focuses on quality (and hopefully quantity in the future), which is accomplished through the LAVA-CR and the Compatible with LabVIEW (CwLV) process. All the while it promotes the LAVA community.The more packages the better. Once the code is available on the LVTN (or VIPN in OpenG's case) you can download it and manage it - easily from any PC (with internet connection and VIPM installed) without the need to search the forums etc. Just search VIPM. Now, if someone wanted to post their recommended community code/tools, it would be as easy as uploading e.g. a .VIPC file (VIPC's are potentially under review to make them better for this task - see here) which references the LVTN/VIPN packages (or could even include other packages). A user code simply download the VIPC file and patch their LabVIEW installation - IMHO this accomplishes the proposed task. Over time, a user could easily upgrade a package due to the modular installation (something that would be more complex to maintain if it was all just a single release). A few packages have already gone through this process for Team LAVA and I actively encourage any community members who are interested to participate in releasing their code through LAVA onto the LVTN - or if they have any ideas to make this process better - please post!

The wiki has been mentioned however LAVA has a new Knowledge Base that I am currently reviewing for suitability also.

This situation has been noted previously (re: hacking) and the OpenG team is discussing alternatives including moving to LAVA. It would require a lot of effort to move all content. Any volunteers?

Just to clarify -are you saying that they own everything you do at work or in your personal time as well?

This is an annoying error I have encountered too, first reported here: http://forums.jki.net/topic/1616-strange-error/page__fromsearch__1 Not sure if it's isolated to LabVIEW as I initially thought. Have no idea tho

Nice! Another issue I can see with this is that you don't have a visual indication that the string has focus e.g. no | in the control. Also you can still tab in this example and get the black rectangle of course, this could be easily fixed by skipping this control during tabbing.

You'll have either have to use a system control or vote here and patiently wait

I think it's the workaround: Its a reference to a LabVIEW Data Object Which is updated during runtime

This may be of interest? https://decibel.ni.com/content/docs/DOC-12668

If your instruments differ in configuration settings, but behave similarly (?) then the following may help: You could use a case structure, but if I do this with LVOOP, I usually think I am doing something wrong or I could do it better. Load the configuration information from disk, internal to a class. Have a method that e.g. accepts a path which loads config info and updates that instance's data. The file structure can be different for each Model. Have a configuration object as a data member of the Scope class. Create accessors for the configuration object. This config object would have children for Model 1 and 2 that would contain the correct data for that Model (and the base config class could contain shared settings). You would need to upcast to the correct configuration class when you use it inside each Model but that shouldn't be a big deal. This will separate your config stuff from your how your instrument actually works which can be handy. I am sure there are other ways to implement this too.

It may also be handy to state why you are trying to accomplish the above (use case), as someone maybe able to offer an alternative solution to your problem.

I just meant by my comments that the OpenG Builder (OGB) may have changed (been worked on by JKI) quite a bit (or not much at all). As I remember there was mention that OGB was no longer an external dependency of VIPM - around VIPM 3.0/2010 if I am correct - and it was now included. ...So if you were to go digging and change something, it would be best to look in the right place Anyways I did some digging just then as I was interested and this is what I found: OGB is licensed under LGPL so it cannot be in the exe as I mentioned above. I found the external library for OGB for VIPM here: The build version is: Comparing this to the latest OGB on the VI package network, it is newer: Although the actual package versioning is different to the build version VI?: (So it might not be correct? I don't know the answer to that at the moment). Might not help much, but I answered my questions

Good job on solving your issues. Here is a KB on custom error files that may provide more info for others (that includes links to other resources at bottom).

Hi Steen Congrats on the code release I PM'd you offline about this question. Regards -JG

Yes, I see that. It's just if I was needing assistance with VIPM I would (and do) head over there. This is actually an interesting question as I would have thought that (nowdays) VIPM would install it's own version of OpenG Builder (possibly stored in the exe) and that it would have been worked on by JKI. I am just guessing tho?

Hi Osvaldo As it is specific to VIPM it would probably be best retrying at the JKI forums rather than here to get a response.

This toolkit is really cool - thanks for releasing it to the public!

Congrats to François Normandin as UI Tools is now Compatible with LabVIEW! ... View the full article

I have added a new version to the LAVA-CR - v1.1.0.51 adds a Element Wrapper Retooler feature.

A while back AQ issued a request to finish some code located in <resource>\Framework\Providers\LVClassLibrary\NewAccessors The with great power come great responsibility line always stuck in my head and it was on my to-do list however, it took me a while to look at it (plus my scripting skills have improved slightly since then ). Basically the code operates on a Class which has other Classes as Data Members (composition) and allows the end user to create an API that wraps the required Data Member methods (delegation): I have now finished off the existing code and bolted on a UI and included it with LVOOP Assistant. I made this a separate thread for a few reasons (not discussed here). Feedback on this feature would be really appreciated. I thought I'd put it out for testing and to get feedback. The aim of this tool is to speed up development. This wasn't my first choice in how to design the GUI etc... integrating it into the current LVOOP GUI's that ship with LabVIEW would be grand, but these are locked. So this way was by far the easiest for me. My next mission is to see if I can get this natively included with LabVIEW Instructions: Class A contains other Classes as Data Members Nesting of Data Members (stored in clusters) is also supported Public methods are may be selected In this case Class B is Friends with A - which means A can have B's community-scoped on their block diagram Private and Protected scoped methods are not supported as Private would break Protected is not logical as LabVIEW does not allow a Child as a Data Member of a Parent The script is accessed through the Project Provider by right-clicking on a Class (that contains data members) and selecting LVOOP Assistant >> Create Element Wrappers The GUI will appear and allow the end user to select the Data Member that will be worked on as well the methods that will be wrapped Public methods and green, Community methods are blue Click a method to check/uncheck it, or use the buttons to batch check/uncheck etc... In the example Data Member 2 is chosen - which is an instance of Class B, which has the following methods Clicking OK creates the following methods for Class A What is happening from a scripting perspective is that Class B's method is copied Converted to a Class A method Class A's BD is cleared, then the method is delegated to Class B. Here is a demonstration (no sound) <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="957" height="652" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/d749a41d-0411-46de-a9ac-2df37c6dc6f9/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/d749a41d-0411-46de-a9ac-2df37c6dc6f9/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/d749a41d-0411-46de-a9ac-2df37c6dc6f9/FirstFrame.jpg&containerwidth=957&containerheight=652&content=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/d749a41d-0411-46de-a9ac-2df37c6dc6f9/LVOOP%20Assistant%20-%20CEW.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/d749a41d-0411-46de-a9ac-2df37c6dc6f9/" /> Unable to display content. Adobe Flash is required.</object> Enjoy! -JG Example Code in LabVIEW 2011 cew example_LV2011.zip

There is an interesting new post on the LabVIEW Tools Network Developer Center Blog that talks about a facet of deprecating code - How to Change Connector Panes in New Versions of an API. I added a comment based on my experiences about deprecation in general, with examples from OpenG. Please check out the blog post and add your comments on this interesting topic! I would am very interested to hear what over developers do, as well as see examples including libraries and classes etc... Regards -JG

This thread should be pinned. Hilarious!

These controls need a defer update method of their own IMHO. I think there is a LVIE idea for this.

It may not be the 'best' but 'a' way is to use Network Streams: http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/networkstreams/ http://zone.ni.com/reference/en-XX/help/371361H-01/lvcomm/ns_networkstreamspalette/ ShaunR also has a library in the LAVA-CR that would be worth checking out - but I'll let him comment wrt your question. Cheers