gb119

QUOTE(tcplomp @ Nov 12 2007, 04:36 PM) Of course, or just a versioning file system so I didn't need to remember to do a commit after every save... oh for the days of VAXen and VMS Semi-seriously, has anyone else had problems with generating corrupt xml files when LV tries to handle non-unique filenames in multiple directories (like dir.mnu for example) - quite often I seem to get an XML file that has multiple entries for dir.mnu that originally pointed to different directories, but at some stage get set to all point at the same file. LabVIEW then decides my library/class is corrrupt and won't load it. A quick go with {CVS|SVN} Diff and a merge editor (I like WinMerge myself) sorts out the mess, but I wish I could work out what triggers this and how to stop it.

Ok, I've discovered a new way to shoot myself in the foot while programming in LabVIEW. Here's how you do it: 1) Create yourself a LabVIEW class 2) Create yourself an XControl to display your new class doing some nifty processing to prettyify your class's private data 2b) Note that you can't add your XControl to your class, so use some public methods to extract the private data 3) Decide you want a probe for your class, so create it and figure "why not just use my nice shiny XControl in my probe ?" 4) Add your probe to your class so that you can assign it in the class properties. Don't forget to save your class as soon as you have added the probe ! 5) Notice that your class is now locked. Enjoy that sinking feeling as you realise this means you can't remove the probe and undo whatever damage it is that you have just done. Find a nice text editor and get hacking on the XML file that defines the class. :headbang: I think the problem is that when a VI containing an XControl is added to a project, the XControl is loaded. creating a new application instance, which contains an instance of your class. Your class is now loaded in two application instances and is therefore locked.

QUOTE(Tomi Maila @ Nov 5 2007, 02:37 PM) I don't have 8.5 to play with (NI doesn't appear to have shipped the update DVDs to academic site licensees in the UK yet), but at least on 8.2 the Variant Type vi's will help here. Specifically, the Variant Type.lvlib:Get Refnum Info includes an output that will contain the type of the queue element when fed the refnum type of the queue. So, I think you it all before generating code. In Adapt to Inputs ability check first that the queue input is a queue refnum, then get the queue element type using Get Refnum Info, and put the element type into the XNode state. Then in Get Terms3, read the state to get the Queue type and set the element output terminal accordingly. Finally generate the code...

QUOTE(Justin Goeres @ Oct 31 2007, 09:54 PM) Perhaps simpler code challenges for when we get asked 'homework' type questions: * The worst LabVIEW style solution - who can come up with the solution that whilst actually doing the correct thing without bugs like race conditions is executed in the worst possible style - I'm thinking multiple nested sequences and loops with sub-vis and wires that sit on top of each, wires that run right to left, daft connector pane patterns, the full works. * The most obfuscated solution - again, a solution that actually works and is bug free, this time written in technically good stlye, but with hardest to follow and least obvious algorithm. I'm thinking about solutions that will score a nice big zero mark but do actually work. Or am I just too evil

QUOTE(mballa @ Oct 19 2007, 06:15 AM) Already there - http://forums.lavag.org/downloads-file87.html (the cleanup all wires was a bit of example code, but I think it you search on LAVA you'll find other people's versions as well)

I wrote my own development environment toolbar for my own use - it didn't have plugins or any fancy key bindings, but I did include things like the XNode manager and some of my various scripting hacks like a "clean-up all wires" tool, a "wire up all possible tunnels" tool, a "re-link all badly linked subvis" tool, a "show node terminal locations and order" tool, and a "find tunnelling error wire and rewire to case selector" tool (my favourite for making my sub-vis more LAVA code repository friendly....) Unfortunately other priorities (undergraduates mainly) have gotten in the way of my LabVIEW coding recently ! QUOTE(JDave @ Oct 18 2007, 10:37 PM)

QUOTE(Jim Kring @ Aug 29 2007, 07:43 PM) I have to say that this whole thread just makes my head hurt ! The swap Values primitive reminds me of the fun I had when I wrote my own CIN to manipulate the string handles in a string array - all of a sudden I noticed backwards propagation of data ! Now I just need the new LV 8.5 DVDs to make their way from the darker recesses of my university to me...

QUOTE(MartinD @ Aug 6 2007, 05:30 PM) There is a provision in the GPL to not include things that are normally part of the operating system. In the context of LabVIEW it would have to be taken that the "operating system" included everything that was installed as part of the LabVIEW runtime engine - if the person who wrote the GPL'd LabVIEW code hasn't or can't make this implicit extension to the OS exception then it is unclear whether you can redistribute their GPL code at all. You can distribute code under the GPL with the diagrams stripped or protected, but you'd have to include someway of acessing the source code - i.e. the vi's with the diagrams unprotected and editable. In which case, why bother protecting it ? There's no way round that - it's just how the GPL works.

QUOTE(tcplomp @ Jul 20 2007, 08:44 AM) Firstly, I'd support having a recommended standard location -but then I'm one of the guilty parties who is submitting code that relies on other code repository code. I'd rather hope that code repository wasn't just a place for snippets but there is clearly some overlap with OpenG when we start having significant packages of code in the code repository. In terms of layout - why not use the heirarchy that already exists in the code repository catagories ? Hence, user.lib\_LAVACR\Rusty nails\XNodes\... etc I had a feeling that the LabVIEW linker works with relative paths ? If so, that would mean that the code repository "root directory" could be moved around would it not ?

QUOTE(Paul_at_Lowell @ Jul 19 2007, 06:17 PM) Uhhh, doesn't the application instance id always end up being set to the FF FF FF FF special value in your version ? Commenting code is a good thing, I probably should do more of it...

QUOTE(Paul_at_Lowell @ Jul 19 2007, 05:01 PM) Yes, you can have a Labview Object control, the reason I used a variant was to do with how the coercion works and the need to get a application instance ID. The application instance ID is only in the type descriptor array not in the flattened string data. Now, if you make that input a LabVIEW Object control, then when you wire up your class control it will be cast to a LabVIEW Object first. Then you flatten that to a string, and recover the 'real' class name from the flattened string, but the type descriptor array refers to the wire type which is a LabVIEW Object and not a wire of your specific class. The problem is that the application instance (which is derived from the type descriptor array) for a LabVIEW Object is always FF FF. Therefore, although you get the correct class name you don't get the correct application instance id. With the variant input, your 'real' class type is wrapped up in the variant, so when you flatten that to a string with a type descriptor array (using the flatten variant function) you get the type descriptor of your 'real' class with the real application instance id. The flip side is that you need to check that you are really looking at a Class and not at anything else which is why I have that little bit of error checking code first. The best solution would be to wrap the class name finder up in an XNode which could do the check to make sure it was being fed a class at edit time, but I thought that was probably complicating matters a bit too much for a quick and dirty hacked solution. If I get keen I'll write the XNode and release it via the code repository (if nobody else does it first). Oh and the random LabVIEW Object constant on my block diagram was a left over from a previous iteration of the code

QUOTE(tcplomp @ Jul 19 2007, 11:49 AM) I'm guessing this might be my XNodes then. There are problems if the linkages for all the ability vi's aren't quite right. Try to mass compile the folder with the .xnodes and their ability vi's in and see if that claims to be missing any vis.

QUOTE(Neville D @ Jul 18 2007, 08:33 PM) I'm pretty sure that you can't use property nodes (or attribute nodes as they were called in LabVIEW 5) because I seem to recall that the Value property came with property nodes in LV6... Unless I'm missing something, the question is actually how to set the value of the 4 ring controls in the sub-vi based on the first 4 selected values of the list control in the parent. The way to do this is to have a hidden array control of integers (I think you can hide controls in LV5 by right clicking on them in the block diagram) that is connected to the connector pane of the MultiPlot sub-vi. Have the ring control in LiveDAS wired to this array input on Multiplot, then in Multiplot before you start doing anything else index elements 0-3 of the hidden array and feed those numbers into local vairable nodes (structures palette) for the 4 ring controls. Local variable nodes let you read/write to control or indicators irrespective of whether they are controls or indicators. They're very useful for exactly this sort of problem of sorting out initial values in a user interface, but are also very easy to abuse. Be very very careful when writing to a local variable and reading back from the control that you make sure that order of the write and read is deterinistic - i.e. controlled by data flow, otherwise you get all sorts of horrible race conditions. These typically come and bite you when you change something in the code or hardware that marginally changes the execution timings.

QUOTE(Paul_at_Lowell @ Jul 18 2007, 05:19 PM) Ahhh, I'm reinventing the wheel.... actually that thread provides a lot of useful information. I've edited my original post with a new version of my class namer tool that extracts more information from the class reference and (I think) now includes enough to properly test the class identity. Although I coded from the information in the thread, it's actually very similar to the OpenG Object template version except mine handles the special case of the base class which the OpenG oibject template don't have to worry about. I'd now revise my wish list for the possibility to access the class heirarchy in the runtime so we could do whatever testing of class hiearchy that we wanted to. (Actually I notice that you can wire a LabVIEW class to a property node - it would be very cool if we could expose the class hiearchy through the property nodes - it would be even cooler if we could write custom properties like in XControls - it would be a nice way of creating pseudo public/protected data instead of get/set methods.)

QUOTE(MikaelH @ Jul 18 2007, 05:15 AM) Ok, here's a vi that does just that and extracts the name of the class (apart from a slight wrinkle with the location of the name string in the base LabVIEW Object class). No guarantees that this will work in anything other LV 8.2.1 and for the classes I've tested it on since I don't understand how a class is stored in flattened data. Unfortunately you can't feed a class wire into flatten to XML which would be a much nicer way of extracting the actual data type from the wire. http://forums.lavag.org/index.php?act=attach&type=post&id=6395''>http://forums.lavag.org/index.php?act=attach&type=post&id=6395'>http://forums.lavag.org/index.php?act=attach&type=post&id=6395

Dunno if it's too late now, but here's a couple of XControls I've been playing around with. http://forums.lavag.org/index.php?act=attach&type=post&id=6393 One is a signal generator XControl that produces a waveform output, second is a simple toolbar XControl that will return a cluster with the index of the button last pressed and whether it was a transitory click or a latch/unlatch type event. © University of Leeds 2007, released under the BSD License I'm considering submitting the toolbar to the CR unless someone puts a better implementation there first

QUOTE(Paul_at_Lowell @ Jul 17 2007, 05:54 PM) If I understand correctly you are trying to search for objects by class rather than by value ? You have an array of class A and are looking for which elements of that array are in fact class B objects where class B is one of a number of child classes of A ? You can use the "to a more specific class" node to test whether an object can be cast to a specific child class. You'd need to write your own set of search sub-vis though. (edit - oh the joys of fast answers - I see Omar Mussa beat me to it !) Another approach you could follow would be to have a dynamic method called e.g. Class_Name that returns a string containing the name of the class. You then override this in every child class, loop through your array of parameters calling Class_Name, do a regular search on the resultant array of strings and then index the array of objects to retrieve the specific class. One of my wishlist items would be a function in LV that returns the class name (or even better a reference) to the actual "on-the-wire" class.

QUOTE(Aristos Queue @ Jul 10 2007, 08:12 PM) Ahhh, so it wasn't just me then. Actually it hadn't been a big enough problem for me to spend the time trying to work out why one of my classes always crashed when probed - I'd sort of assumed it was something to do with the class data structure, but I hadn't got as faw as working out some test cases. Good to know it'll be fixed...

QUOTE(ntward @ Jul 7 2007, 10:17 AM) You probably want to look at property nodes for this - they're a way of programmatically changing the appearance of a control. Right click (or platform specific equivalent) on the cotrol (I'm assuming you're using a boolean here !) and select Create->Property Node and pick the property of the control you want to change. I'd suggest you look at colors (to change the colouring of the control) and probably disabled (to stop the user from trying to change the control if there is a malfunction). Other (more complicated) solutions would involve having a transparent control overlaying an indicator - the user operates the transparent control and you report report what is happening with the indicator - e.g. make the indicator a color box and use different colours to report valve open/closed/stuck open/stuck closed.

QUOTE(LV Punk @ Jul 6 2007, 08:18 PM) Just a suggestion, but if the aim is to generate images of all possible block diagram objects, why not use vi scripting to generate each possible object one by one, then use the bounds property of the GObject class and the Block Diagram image method of the vi-class to get a flattened pixmap of the created BD object ? (A word of warning, I tried to do this quickly but keep crashing LabVIEW - I suspect it doesn't particularly like me trying to create and delete one of every possible object on the same BD in one run...) Edit: Ok - I've generated png for all the LV objects that I can do without LV crashing on me - here they are if someone wants to sort them into catagories (perhaps that can be done using the pallete menu api to work out which images belong where...)http://forums.lavag.org/index.php?act=attach&type=post&id=6325

QUOTE(Guillaume Lessard @ Jul 5 2007, 11:45 PM) Assuming you don't care too much how verbose your TCP transmissions are, why not use the (un)flatten to/from XML functions ? They (obviously) don't use a type descriptor array and with the string data being human readable it might be easier to debug if the conversion failed...

QUOTE(mdd100ai @ Jul 4 2007, 10:30 AM) If you are using LabVIEW 8.2 then my http://forums.lavag.org/downloads-file87.html' target="_blank">Scripting Tools toolkit has a polymorphic vi that returns a class constant of every possible type. This doesn't actually help you that much because in LV 8.x the properties and methods for scripting are hidden and can't be revelaed with any fancy ini file key. The Scripting Tools toolkit will create some nodes for you, but not a formula node (yet), but if you look at the Create Expression Node, you'll see that that is actually creating a formula node (and a mathscript node is a subclass of a formula). Alternatively, I'd reccomend the DataAct Class browser for those wanting to mess with LabVIEW scripting - I think it supports LV 7.x and upwards. It does cost $ if you want the version that can create property and method nodes. In terms of using a scripted vi in a project - firstly you need to be aware that it will only work in the development environment (scripting is really only for NI for writing development tools...). If that is not a problem, then what you will want to do is have a vi that creates and scripts a new vi that has the formula node, and then executes the new vi using the vi-server methods, before closing all the references to the new vi, hence removing it from memory.

QUOTE(orko @ Jun 26 2007, 11:19 PM) Ah, yes. I had a slight failure to engage brain when I wrote my version. It'll be fixed in the next release of the Scripting Tools (a Wire is a GObject, but isn't returned by the All Objects[] method of the Diagram class...). Using the Traverse for References is neater in many ways I suspect, but why not ask Traverse for References just to return Wire class references, rather than GObjects and then filtering as at present ?

QUOTE(zoogies @ Jun 25 2007, 07:11 PM) <plug mode="own code"> The http://forums.lavag.org/downloads-file87.html' target="_blank">Scripting Tools toolkit in the code repository has, as an example, a little program that can be put into your project folder that will find all wire references and run the clean-up wire method on them. The toolkit is LV 8.2, so if you're using 8.0 then it's not much use to you. </plug>

QUOTE(Doon @ Jun 5 2007, 10:47 PM) Not wanting to be picky, but how do you adjust the number of tabs at runtime if the array size isn't 8 elements long ? That's the tricky bit. Perhaps one could make an array of booleans with a custom graphic on the button to make it look like a selected/deselected tab with transparent array housing with some logic to ensure only one element is true at any one time to simulate the tab strip and then usse the index of the true element to index into the array and use a single cluster control as in the above example. If platform independence can be sacrificed and the target is Win32 then I think the ActiveX tab control can have new tabs added at runtime - if so, that could provide the tabs part of the UI with a single cluster control displating the current index.