gb119

Why not use a semaphore that each subvi tries to acquire before inserting itself and releases after it unembeds? This seems to involve minimal changes to the existing structure...

I want to believe your statement about using XNodes.  Partly for this function, and partly for the OpenG Array tools.  What I'd really like to do is package up these tools into our internal reuse library.  But that is just something I cannot do until NI endorses using these techniques.  Maybe I could make a XNode package and not include it in our base reuse and just have it be experimental.

I'd be a little surprised if the performance with the OpenG Array XNodes where very different from the original OpenG versions - the XNode code is just being generated from a template that is nealry identical to the original OpenG version (or at least if the OpenG versions had the optimal settings applied to them in terms of debugging and inlining etc.)

I've sometimes wondered if one could persuade an XNode to replace itself with a normal sub-vi version of the generated code. Perhaps a right click option on the XNode that took the generated code and saved it next to the parent vi with a unique name and then did the replacement. That would let one develop testing code with XNodes and then 'freeze' them to normal vis for release so that production code wasn't using unsupported features. Of course, code that eplaces itself might equally be a quick way to crash the IDE

Thanks for the lecture When I've figured out how to clone myself I'll send another isntance of myself to attend some CompSci letctures and learn these things systematically ! I can see one immediate enhancement to the new NI GDS toolkit - make accessor vi's non DD by default and require the use to explicitly set them to be DD....

Ok, now I'm a little confused...

What you should do is add two protected scope VIs to the parent class to do Read and Write of the value -- those two VIs should NOT be dynamic dispatch.

I generally do make my property accessor's dynamic dispatch in case in a child class I want to do some extra validation or data munging before I read or write the data for that child instance. Since I'm generally not organised enough to know when I design the parent class what I'm going to put in the child class, I've tended to stick to dynamic dispatch on a precautionary principle. Am I committing some utterly heinous OOP crime in ignorance ?

For similar reasons, I try to avoid using bundle/unbundle nodes for any element of the parent's data that I think I might end up wanting to hook extra validation or munging in a child class, even when I'm in a parent method.

A semi-concrete example of where I use this: I have a parent class that has a wavefcorm as part of it's private data. At various points in the child classes I want to check for and store in the child data specific waveform attributes, or to ensure that those attributes are eadded to the waveform. In these cases I overload the waveform accessor methods to handle the waveform attributes and add them to the child class's private data.

Of course in most cases the accessor vis don't end up being overloaded and I guess I pay a small overhead in the fact that I'm calling into a subvi rather than bundling/unbundling directly and possibly in the uncessary dynamic dispatch (although I though I understood that DD was not an expensive process when the method vi is not overloaded). Finally, I tend to make my accessors into property vis just because they take up less real-estate when I'm accessing a bunch of private data at a time.

I can see one other potential problem that might happen with the bundle but not the property node version: you've unbundled a reference and called a property node with that reference. Now, if for some reason that property node hits an error then the reference out from the property node might be set to Not a Refnum and the error cluster will contain the error information. If you use the bundle node then you bundle the Not a Refnum back into the class data without any checking at all - probably generating downwire bugs. With the property node accessor vi, the presence of the error in the error cluster will stop the Not a Refnum from getting put back into the class and chances are that other things will continue to work ok.

Of course this would mean that the caller of this routine wasn't checking the error out cluster, or possibly that the accessor proptery node vi was discarding an error - which would otherwise have picked up the problem.

When one uploads a file to the Code Repository there is a handy dropdown box to indicate the LabVIEW version that the code is written in. Currently it goes up to LabVIEW 2011 - it probably needs 2012 added !

http://forums.ni.com/t5/LabVIEW/How-do-I-control-the-location-of-palette-files/td-p/929187]According to Darren[/url] it's InternalPaletteEdit=True.  However I would back up your menus directory first in case you want to revert.

I have this memory that there was some way (like an ini key) to get the palette editor to save editted palettes 'in place' in the main installation directory and not into the user's LabVIEW Data folder.

Does anyone know how to do that...?

New 1.0.1 version released that removes the errant XNode call + fixes a number of bugs in particular in the configuration dialog window + cleanup several other parts of the code to be a little less crazy and a little more like sane LabVIEW style (plenty more still to be done through) + add some more toolbar button themes.

Hi,You have a call to a missing xnode: "Minimum Array Size.xnode" in your “Toolbar.xctl:Set Toolbar Images.vi"

I've packaged up a partially cleaned up version of the code as a VIPM and stuck it on the Code Repository in Uncertified. (here). I think I've found and zapped the XNode instances (unfortunately, they don't show up in the normal dependency places) and some of the vi's now have descriptions. I've also added a tip strip capability to the toolbar which has been on my todo list for about a year !

Name: Toolbar XControl

Submitter: gb119

Submitted: 13 Feb 2013

Category: *Uncertified*

LabVIEW Version: 2011

License Type: BSD (Most common)

lavag_lib_User_Interface_XControls_Toolbar XControl v1.0.0.3 by University of Leeds

Author: Gavin Burnell

Copyright: Copyright © 2013, University of Leeds

License: BSD

Compatible LabVIEW Versions: >= 2012.

Compatible OS Versions: ALL.

Description:

This is a native toolbar for LabVIEW implemented as an XControl. It supports a single row of square buttons which maybe latching (sticky) or transitory (command) style buttons drawn in one of 4 different styles (system, square, flat or rounded). The toolbar will report button clicks via a value change event, but allows the possibility for further integration into other messaging systems.

The buttons are represented as instances of a button base class that provides methods for drawing the button, updating tooltip text or responding to clicks. Overriding these methods in subclasses allows a greate flexibility of response. Included in the package is a 'vi-button' class that stores a vi reference with each button and executes it when clicked.

This Package depends on these other packages:

oglib_string >= 4.1.0.12

Click here to download this file

I guess what one could (in theory and I might think about trying at some stage) do is to have an XNode that responds to a right click menu option by replacing itself with a static subvi that includes the same code - thus one could have the benefits of XNode type adaptation during development but with the ability to convert to static vis when preparing a production version of code.

I would add "in-house code which the developer is in full control of" to the class "private experiments" but otherwise not disagree with Rolf. That said, they work for me and I trust my $200k cryostat to them, but you wouldn't find me trusting a heart monitor to them !It appears NI would like to have a mechanism to let users write generic, type adapting code, but they have stated here that XNodes will not be the solution.

This is not a feature request by any means, but if you are thinking about making the tool look more native I would suggest having vertical separators  and a function that allows for resizing the window, which would collapse buttons into a single button when they all can't fit in the display.  See the image of Foxit Reader which collapses the buttons to a >> button which don't fit.

Amazing, the community again thanks you for your contribution.  The case as you put it is quite undocumented, and needs work, but the concept is there and it works just well.  Also it should be noted to get this to work you need to install the Array XNode library, which also requires the lava_lib_labview_api_scripting_tools package as well.

These are pretty much the reasons I've never released the code 'officially'. Actually the XNode dependency and hence the Scripting tools dependency is pretty easy to strip out and replace with 'static' code. I've sort of intended to do so for ages but somehow other things keep getting in the way. Also, I've a very long term, slow burning, project to replace the whole toolbar with something a bit more flexible that could include other types of control, not just a push button.

Here's a toolbar XControl that I developed for one of my applications. It's not really intended for public consumption, so it's almost entirely undocumented and may not all work as exepected or indeed as I intended :-), but there is a minimalist example included in the project.

Essentially the toolbar is an array of picture controls and the core of the underlying state is an array of button class instances. The button class provides methods to draw itself and also to take an action when clicked. I've included a sub class of Buttons that stores a vi-reference in the button, uses the vi icon to genrate the button and executes the vi when clicked. Obviously one could sub-class the button class to do other things like pass messages via one of the many message/actor type frameworks.

The XControl itself returns a cluster giving information about which button was clicked.

(LabVIEW 2012)

Toolbar.zip

This does not extend to all reference types. It only applies to the parent reference being a VI. In your example, closing a panel reference will not invalidate references obtained from the panel reference.

Yeah, I realized after the event that I'd messed up my quick test code and was being misled as to why my references were invalidated.

because refs to actual controls can never actually be closed?

Um, well the refs in the Controls[] property of a panel reference presumably can and should be closed. The refs obtained via control reference nodes obviously not.

"You can close child object references when you no longer need them, but closing the parent VI reference automatically closes child object references of that VI. However, if you close the parent VI reference before LabVIEW calls a child object reference, the child object reference may become invalid. Make sure to wire block diagram objects so each function executes in the order you want."

It wasn't immediately obvious to me that this applies to all parent references, not just to the (fairly obvious) case that the parent is a VI. To extend the example given, if you open a vi reference, get a reference to the panel, get a reference to the controls, close the panel reference, but leave the vi reference open, then the control references are invalidated. Now I'm wondering why I haven't fallen into that before....

It was the lack of error dialog that was weird. I understand why the cast did not work.

Still, it is a bummer that I cannot extract a parent object from the child object without creating a parent object to feed into the to more generic node.

It may not be such a killer. The child objects have to have the parent (and grandparent) in memory anyway, so the penalty is the memory allocation of the default data for the parent's private data. I'd imagine that large data storage in a class would be in an array or other dynamically growable object (like a waveform or variant). So long as you don't set the default value of tge class private data to contain lots of data, the actualy overhead of storing e.g. empty arrays is not so large.

ok, so this is weird. If you take the grandparent wire with the parent object riding on it and cast that to the parent type, you can use the parent accessors to get at the data in the parent object.

But, if you take the grandparent wire with the parent object riding on it and you cast it to the child, then try to use the parent accessors available to the child class (I made them protected), you don't get the data. It comes back empty. Turns out, this is because the cast fails. But this was not obvious to me at first because I did not get an error message, even though I have automatic error handling turned on.

It's not very weird. You just cast a parent object to a child. You can't do that - it's a parent object and not a child object and casting it to a child doesn't change that fact.

Remember, casting is just about changing the wire type - you're not actually casting the data that is travelling on the wire. If you want to do the latter, then the preserve run time class node is your friend - but you'd better be sure that the data your messing with is really the right type (i.e. you still can't make a parent into a child). I guess the lack of error reproting is down to the casting class being a primitve rather than a subvi. (herein casting==to more specific class/to more generic class)

Life was so much simpler before inheritance came along :-) !

So I have created those accessors in the parent, but the wire type coming into the child is of type grandparent. So, I don't have access to the parent methods without casting it to the parent's type. I was hoping there was a way to do this using the child class wire. But I cannot sort out how to do this.

Ok, but you can cast the grandparent wire to parent wire using a "to more specific class" node and then call the accessors. You probably want to check the error code from the to more specific class node just in case you accidentally get something which can be treated as a parent class (note that the to more specific/generic class conversion odes are operating on the wire type not the actual data type).

I think, however, that there may be some refactoring you could do with the design - normally when one is facing a series of uphill battles like this it's better to find a way that is downhill :-) !

What I need to do is cast the grandparent wire to the type of parent so I can access the parent's data. I could use the child to do this but how do I extract the parent class type from the child and use it to cast the grandparent to type parent? I need to do this statically as design time, not at runtime.

Umm, since class data is always private, you're not going to be able to do this directly in the child class (you could, in principle, cast a grandparent to parent within the parent class method and then access the class data but it would be prone to failures ince you'd have no way of guaranteeing the cast would succeed). The best you can do is created protected class data accessors in the parent class and use them in the child class to get at the class data.

Here's a template that doesn't use the IPES, so should work in 8.6. It should be almost as efficient.

OpenG Remove Duplicates from 1 D Array Template.vi

Many thanks ! This template is used in the new 1.3.1 version.

I've noticed one further buglette in the XNode - if you don't connect up wires to all of the inputs and outputs then it doesn't work (even if the outputs aren't then used for anything). I suspect this is the templating code failing to wire a tagged tunnel to a non-existent terminal but haven't had a chance to investigate it properly.