gb119

Can you negate (at least partially) this con by having the event creation happen when the read-only property vi is run. With a simple flag in the XControl state could you then check whether to generate events and destroy it in the UnInit ability ? I guess there's still be the problem of the user getting the event property, using it once and then ignoring all suvsequent events - in which case you might want a method to inform the XControl that this was the case and replace a simple flag with a reference counting mechanism to keep track of the event being used in multiple places. In general I like option A better because the XControl defines what the user event data type is - just seems a little bit more robust to my mind.

Pretty sure it can't be done - a local variable has to sit on the block diagram of the vi which owns the control. I'm not sure exactly which block diagram an XNode scripts its contents onto, but I'l fairly sure it isn't the parent diagram of the XNode itself. That is of course the main advantage of property nodes over local variables - it allows sub-vis to manipulate the controls of the caller (which of course is a disaster unless you're doing UI stuff....)

Ok, further checking, you actually have to break the new icon editor to make it not open in the other application instance (I think I was getting confused with using custom editors in LV 8.6....) 1) Start LV 2009 2) Open <labview>\resource\plugins\lv_icons.vi 3) Make some trivial change that breaks the vi (e.g. create a broken wire segment) 4) Attempt to edit an icon

Yes, I've done that. Attempting to edit the icon of the new LV2009 icon editor will open the 'traditional' editor. I would imagine that any action that breaks the new icon editor or stops LabVIEW from launching will have this effect.

There are known problems with multiple non-vi/ctl files with the same name in LabVIEW libraries and classes that can result in unexpected cross-linkages between lvlibs or worse, corrupt files. See this thread on NI's forums for details. Essentially it appears that the loader uses the standard LabVIEW linker rules about how to find a file when loading the members of a library. Whilst this is perfectly sensible for LabVIEW VIs, custom controls etc which should have a unique name, it is less than helpful when the library files contain other types of file that may legitimately have the same name - such as dir.mnu files. This isn't a problem in project files as in that case the members aren't all loaded into memory when the project is. The solution is to move the dir.mnu files out of the lvlibs, or to rename/recreate them with unique names. Your current solution will go very badly wrong if you ever have multiple dir.mnu files in the same lvlib !

The really frustrating one I've encountered is when a class object has gotten saved with a child class instance as the default data. Sure the class icon on the block diagram shows up with a black border - but is it a black border because the class is the correct type but with non-default data, or is it black bordered because it's got a child class on it ? And other than opening each vi which uses a class and looking at its front panel to check for black borders, how the **** am I supposed to find which vi is keeping my child class in memory ? The real problem with this comes when the vi holding the child class in memory is a mehtod vi of the parent class and the child class itslef is broken. That makes the parent class broken and every single child class of that parent is thus broken as well.... you can't simply unload the really broken child class because you can't easily track its dependency, fixing the breakage might not be easy if this is a child class that is under development...

Your class hierarchy looks basically the same as the one I'm using. Attached is my LVOOP'd driver for a Keithley 24xx Source Meter (which is a bread and butter instrument for us for any sort of electrical transport characterisation). I won't pretend that it's particularly well implemented, it was pretty much the first thing I wrote in LVOOP but it is now the basis of all the instrument communication I do. The base class provides essentially a wrapper for VISA along with some SCPI handling code and provision for realtime monitoring of what is being sent to the instrument. The source-meter intermediate class is rather tightly coupled to Keithley type instruments, but since that's what we mainly use... The actual Keithley 24xx class includes some pretty ropey code in places, but generally works as expected. Anyway, "share and enjoy" Keithley 24xx-LVOOP Driver.zip [edit: 8.6.1]

I've certainly wanted to attempt runtime resizing and rearranging of my frontpanel (for an XControl where the user can resize the facade and so I want to be able to rearrange the control elements as required). I had a brief look into how Tcl/Tk packing layout engines worked, but it looked quite complex so I stopped

Ok, your immediate problem (aside from the missing sub-vi) is that you are generating some outputs in the case structure inside the while loop, but only when that case is true. When the case is false the two wires coming out of the case structure don't connect to anything inside the false case. You can see that this is the problem because the 'tunnel' where the wire goes through the case structure boundary is white not solid colour. However, I suspect that you have a larger lofic problem in your code as the bit where you are trying to save the log file to disc will only execute when the whole measurement loop is finished and then will only write the very last measurement to disc. Your probably want to move the code that builds the table and and also save the file into the inside of the case structure in the while loop.

That's a shame. From a quick trawl through the LabVIEW folder it doens't look like the probe window is implemented in G which would have given some chance of replacing it with customised code. My particular irritation (aside from the lack of option to change the default float/non-float) is that having floated the window, closing it re-embeds the probe rather than having it remove the probe like it used to. I was looking for something like a toggle on the context menu on the probe watch window to re-embed the probe window which seemed like the more obvious place to go...

It's going to be almost impossible to help you unless you give more details of the hardware that you are working with - how do your sensors connect to your computer ? What so of signal do they return ? People on LAVAG are generally helpful, but are much more likely to help those that try to do something for themselves first, so I suggest you post what code you've managed to write already, even though it doesn't work. Or you might find that asking your teacher or instructor is a more profitable route to getting solutions to your assignments.

This really wants to be an option doesn't it ? I wonder if there is a magic ini file string that turns this behaviour on or off ?

Yup, that's why I thought I'd ask if anyone wither had already done it or knew of a smarter way to do it....

This is thinking about right click framework plugins for inserting code into a wire - but if the wire is branched you need to know which bit of the branch you are trying to break into - i.e. inserting before a branch point or after a branch point makes a difference to the code.

Hmmm, that all helps, but it looks like a routine that then traverses the wire to work out which terminal(s) are down-wire of a selected segment is still needed. I'll add it to my l"interesting things to look at when I have time" list...

On a related topic, does anyone have a good algorithm for working out (given a set of co-ordinates) on which segment of a wire a mouse click has been made and therefore which drain terminal that segment is connected to ? This is kind of important if one wants to insert a node into a wire between the source and only one specific drain terminal.

View File Waveform XControl Copyright © 2008, University of Leeds, UK All rights reserved. Author: Gavin Burnell --see readme file for contact information Description: This XControl provides a function generator wrapped up in an XControl that outputs an analogue waveform data type. Supports sine, square, ramp, saw tooth, parabolic, cubic, quartic and arbitrary functions with adjustable amplitudes, offsets, and number of periods with no further coding. User interface provides a graph that updates in response to user changes to the controls. XControl will adjust layout as it is resized, and provides properties to set the visibility of the axes scales, y=0 marker and a current index position marker. Submitter gb119 Submitted 07/04/2009 Category X-Controls LabVIEW Version 2018 License Type BSD (Most common)

I've just uploaded a new version - 0.20.1 which has several new features, including a vi that can create structures by enclosing objects that already exist on the block diagram - just like the regular draw structure around things does. There;s also a couple of vi's that do things that aren't exposed by scripting - like turning on the "use default if not wired flag" on tunnels and triggering type propagation. I've stuck these together to create a new example too - a pugin for the JKISoft RCF framework that will wrap everything in a case structure, wire up the error wires and then set the output tunnels to use default value if not wired (so the resulting VI does actually compile).

Name: Generate Palettes Submitter: gb119 Submitted: 21 Jul 2009 File Updated: 15 Oct 2009 Category: LabVIEW IDE Version: 1.0.04 LabVIEW Version: 8.6 License Type: BSD (Most common) Generate Palettes-1.0.0.04.zip ~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright © 2007-2009, University of Leeds, UK All rights reserved. Author: Gavin Burnell G.Burnell@leeds.ac.uk Distribution: This code was downloaded from the LAVA Code Repository: http://lavag.org/index.php?app=downloads Description: This is a utility for automatically creating palette menu files from a library or LabVIEW class. LabVIEW offers the option of including palette files in .lvlib or .lvclass files and for setting one of these palettes to be the default palette file when the user right-clicks by a member vi or class wire. This is very useful, but the LabVIEW project manager has some flaws when it comes to having multiple palette files with the same name in a project that can easily result in a corrupt xml file. This utility gets around this problem by creating uniquely named palette files that reflect the project structure of the class or library. In the case of class files, if the class is a child class the utility will attempt to lcoate a palette file for the parent class. This makes it easier to have all parent methods readily to hand when right clicking on a class wire. Couple with the option to work out the complete class parentage and create all necessary palettes it is quite easy to setup a chain of palettes through a long descendent list of classes. Todo: I've got various ideas to implement in future versions: 1) Look for gone away or moved items in the palette files and attempt to relocate them. 2) See if I can access Endevo Goop Developer class properties to use different icons for public/private/protected class folders. 3) LabVIEW project file support (should be quite easy to find all class, library files within a project) Dependancies: OpenG File Tools Support: If you have any problems with this code or want to suggest features: <LAVAG forum here> h Change Log: 1.0.04 Fixed silly bug where default palette was set after the library was saved. Sorted out relative paths somemore. 1.0.03 Added code to set default palette file (thanks to Ton Plomp !) and move refresh palettes to only run once. 1.0.02 Added some more documentation to the sub-vis. 1.0.01 Original release License: Copyright © 2007-2009, University of Leeds All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the University of Leeds nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Click here to download this file

Ooh, what have I started here !? So basically it's a way of forcing the base method to be invoked even if the immediate parent classes have over-ridden it.I guess this becomes a way of achieving partial inheritance - given my original inheritance tree, a class D can fall back to some methods from class C in the normal way, but if there are some cases where class D wants to make sure class A's method is run, then it implements the methof itself and uses a helper class B which uses this trick to call class A method directly on the class D instances. Of course it would probably have been easier just to reimplement the original behaviour in class D - except that this way the A class private data in the instance of class D can be used directly and the programmer of class D doesn't need to know the details of the class A implementation to access it. On the third hand, it makes my head hurt

No, that bit's ok - class B isn't an array of GMO's - it has private data that is an array of GMO's. Aristo Queue demonstrated this sort of an idea in the Map LVOOP example that will be buried somewhere in hte LAVA 1.0 content. The problem, I realised as I walked hom through the rain tonight is that (apart from living in a wet climate !) I was being terminally confused over what methods would execute when the call parent node ran - even if it had worked on the basis of the dynamic despatch class inputs rather than the owning VI's class, it wouldn't have done the correct thing for me. Also consider what would have happened if I really did have an instance of class A going into it - what method would have run ? That's not saying that the original question was stupid - it's not obvious how call parent method node determines what the parent is, and it would probably be a good idea if the compiler required the dynamic despatch marker in the class wire to enusre people like me don't write crazy code.

Ok, just so that you get some idea of how the thought processes of your users go.... My program is measuring a widget as a function of temperature, magnetic field, voltage applied to device etc. All of these measurements essentially follow a pattern of construct a list of temperature or whatever, iterate through them one by one, measure widget, save data repeat until done. So I write a base class (A.lvclass) that knows about constructing a list of values, initialising somehing, iterating to the next value, working out when all the measurements are done and a whole bund of other things. I then implement each type of measurement (magnetic field, temperature, applied voltage whatever) as a subclass of A - these are classes C,D,E etc. All is fine in the world and my students give me data. Then my students come and say "ok, this is fine, but I want to measure over both field and temperature". So I think, I could just expand my program to work with 2 instances of class A separately, but somebody is bound to ask to iterate over 3 parameters, so instead the cunning way to do this to make a new descendent class of A (B.lvclass) that takes an array of child classes of A and for each method simply calls the corresponding method for each element in my array of class A. Since dynamic despatch works, I'll call the correct method for whatever class is actually stored in my array. So I'm doing the second version of your list of operations below. Now I get lazy - I'm essentially writing the same block diagram for each and every method class B - viz, get array of class A, index through it, calling methods, stuffing the elements of the array of class A back into the array and thence back into class B's private data. So being lazy I wonder if I can just keep doing Save As for each method having used the call parent method node so that it automatically picks the correct method. Then I realise that I'm not a 100% sure what call parent node does in this circumstance. Yes - basically I was just being lazy ! Still, at least I've learnt something interesting even if it does mean I have to go back through my class replacing all of the call parent nodes with the correct specific method. Although your comments about reentrancy do remind me I ought to put a test to make sure than I'm never actually have an element of class B or a descendent of it in my array of class A.

I thought I understood how dynamic despatch worked and calling parent methods within a dynamic dispatch worked, but now I'm having second thoughts ... Suppose I have a class hierarchy like this: A.lvclass |----B.lvclass |---C.lvclass |--D.lvclass |--E.lvclass Now B.lvclass has private data that is of type A.lvclass. And all classes have a dynamic-despatch method M Now in a particular wire of B.lvclass, the private data contains an instance of D.lvclass B.lvclass:M invokes Call Parent Method on it's private data (which is an instance of D, but with control type A). What version of M is run ? Is it A.lvclass:M since that is parent method of B.lclass:M (which is what I would expect), or is it C.lvclass:M which is the parent method D.lvclass:M ie. does Call by Parent Method work out which class to execute by looking at the type on wire on its dynamic despatch terminals or by looking at the class of the calling vi ?