gb119

QUOTE(Jeff Plotzke @ Jun 5 2007, 07:56 PM) There is a sort of a way to do it, but only in the development environment and it's a bit of a hack. What you do is have a sub-vi that has a tab control with a single tab and a copy of the cluster 'element'. In your main vi, you have a sub-panel control into which you insert the sub-vi with the tab control. but before you do so, you use vi-scripting to add extra tabs to the tabbed control and then fill the newly created clusters with the data from the array. Example (LV 8.2.1) atttached. http://forums.lavag.org/index.php?act=attach&type=post&id=6038''>http://forums.lavag.org/index.php?act=attach&type=post&id=6038'>http://forums.lavag.org/index.php?act=attach&type=post&id=6038 Almost certainly not worth the effort though

QUOTE(Aristos Queue @ Jun 4 2007, 11:46 PM) Does the while loop actually do the allocation on every iteration ? - I thought I'd read somewhere that it allocates in chunks of increasing size and then deallocates anything left over when the loop finishes. Did I totally dream that ? Is the compiler intelligent enough when looking at a loop to work out if the iterator terminal is unwired to not bother generating code to produce the iterator output, or would that explain why the array operation is faster ? On the original topic, what would be very handy would be if index array and friends took in a cluster of n-numerics to index a n-dimension array. Particularly handy for working with 2D arrays of images if one could wire in 'points' and 'bounds' type clusters to pull out points and subsets. Hmm, maybe my next XNode project

QUOTE(Eugen Graf @ May 30 2007, 09:38 PM) [...] QUOTE(Eugen Graf @ May 30 2007, 09:38 PM) Thank for your answer. I don't really know if I can use here Variant.llb. And I have LV 8.0. Eugen So it looks like your data originates from outside LabVIEW - in which case I'm afraid there is no easy way - you need to convert your data to an array of unsigned ints (looks like your protocol aligns on 2 byte boundaries, so U16 will work) and with the individual elements. You can quite easily do U16->array booleans->cast to your type def. Here's an example of a U8 cast to an 8 element cluster of booleans. http://forums.lavag.org/index.php?act=attach&type=post&id=5973

QUOTE(Eugen Graf @ May 30 2007, 07:35 PM) Flatten to string essentially gives you a straight memory dump of the data with (for versions < 8.0 by default and optionally for >=8.0) a separate ouptut that can describe the structure of the data. Sometime around LabVIEW 4.x/5.x the in-memory storage of a boolean was changed from one bit to one byte, so when you flatten a cluster of 8 booleans you do indeed get 8 bytes back. I'd hazard a guess that the change was done because RAM wasn't quite so critical and memory alignment issues were more so, so it made sense to reserve a whole byte even though only the lsb is used. I'm not entirely sure I understand what you are trying to do, but if you have 8.2.x or perhaps 8.x, then in the Utility folder of your vi.lib there will be a VariantDataType.llb which has subvis for interpreting variant data-types without getting your hands dirty looking at the flattened data.

QUOTE(Darren @ May 23 2007, 08:00 PM) The feature that I have already implemented as an XNode returns takes an n-dimension array and a scalar x and returns the (x+1)'th dimension of the array or -1 if x<0 or x>n-1. Fairly elementary stuff, but I got tired of wiring array-dimension and then index array together. It hadn't occurred to me to make it growable - but then so far I've kept my XNodes nice and simple and just made non-resizable ones :-).

As others have said there may be easier ways to do this, but to answer the original question... Flat sequences are a bit weird in the LV class heirarchy - you'd expect them to be Generic->GObject->Node->Structure->FlatSequence, but no the whole flat sequence structure is a direct descendent of GObject. That has a Frames property which gives references to a set of FlatSequenceFrame objects which is not even a GObject (!). That has a Diagram property which you can then use for the New VI object primitive for placing the tick count (ms) node. Not having tried to do this myself, I'd be interested how you are moving the body of the code into the middle frame of the sequence whilst leaving the terminal nodes outside and then rewiring it all up again.

QUOTE(AdamRofer @ Mar 29 2007, 09:49 PM) Yup, it looks like it really truly is just a Node. I can't get a Text.Size to Text? to work either. On the other hand this whole typecasting of refnums so that property nodes don't notice you accessing non-exposed properties seems so completely and utterly hackery that I'm not sure whether to laugh or cry. I wonder if the NI employees enjoy watching us bang our heads against walls trying to do things that we're really really not supposed to do with LV :headbang:

QUOTE(yen @ Mar 29 2007, 07:54 PM) The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created. As far as I can see, there must be a property or method to specify the expression that the expression node uses, hence one would expect the expression node to be some class different from e.g. the increment function. If one wires an class that is incompatible with the object that New VI Object tries to create then you get a type cast error (e.g. try specifying a terminal class constant while creating an add function). Compatible in this case means that the class you specify is either the same as the actual class of the object, or a superclass. The reason that wiring the generic class works, is that generic is a superclass of lots of things, but it does mean that you can't do very much with the object you've created without casting it to a more specific class first, for which you need the correct class constant... By replacing the generic control with more specific class types in turn, iterating over the class heirarchy and spotting which generate errors and which don't one can map out the specific heirarchy of the object that one is creating. Thus, I've got as far as 'Node' but no further. Actually, thinking about it, if I create an expression node on a block diagram, I wonder if I can interrogate that from another vi to determine the class type of all the nodes on the block diagram. Will go and try this...

I'm playing around with scripting and trying to create an expression node (as in the in-wire formula nodes). I'm getting stuck as to what type of class to wire into the New VI Object primitive. I can tell that it must be some sort of Node class because if I use a Node class constant I don't get a type casting error from the New VI Object primitive. On the other hand it must be a sub-class of this because there needs to be some way to set the expression to be used. However none of the subclasses that the DataAct Class browser (great tool by the way for us trying to script in 8.20) knows about. Trying to create property nodes with class names set to likely looking strings isn't giving any joy yet either. Has anybody created an expression node through scripting, and if so, how do you set the expression ?

QUOTE(dannyt @ Feb 13 2007, 11:30 AM) Many years ago (well about 6) I wrote a vi that interfaced to the Perl Compatible Regular Expressions library for LabVIEW 5.1. It's downloadable from: http://www.crojack.org/labview/pcre-2.08-lv.zip If you're running Windows then there is a precompiled binary, otherwise it's a question of compiling the CIN and linking to a version of libpcre. Basicallly my routine does the same as the one now builtin in LV 8.0+ - except that I did it first and mine isn't a nice extending node but can handle variable numbers of sub-patterns at run time. It's a long time since I used that version (I rolled the CIN code into a custom dll full of other useful code functions, and the PCRE version is positively prehistoric in internet terms !) so I can't promise that it all still works....

Google is your friend... http://www.sullutions.com/LabVIEW/Info-LabVIEW.html confirms that info-labview is currently down, although the machine itself seems to be up. I guess we're waiting for Scott Hannahs to perform the correct magic.

Thanks - that was pretty much what I was I had figured out. Perhaps this could be added to the sticky post at the top of the forum ?

I'm sure this must be a FAQ, but if is then I've failed to find where it is answered: How does one reveal the scripting methods and properties in LabVIEW 8.20 ? The ini key setting that works in LabVIEW 7.1 (SuperPrivateScriptingFeatureVisible=True) doesn't seem to have any effect for me and doesn't appear in the LabVIEW executable file. SuperSecretPrivateSpecialStuff=True does work (and is in the executable). This is for Windows FDS if that is relevant. Gavin