Mellberg

Thanks Ton, looks like what I was looking for!

Hello! Is there any possibility to get the size of an array from a reference to the array? Since the data type within the array is unknown, I can't convert it to the actual data type and then use the built in 'array size'. Thanks in advance! //Lars Mellberg

Well, I think you should consider skipping the coloring and then also writing the data_1..data_2 as 'Child Text'. Also, skipping writing the Child Tag will give the item the tag of 'Left Cell String' - not sure if that will speed things up, but perhaps... Modifying your example, making it give the same result, except the coloring, the run-time went from ~30 sec to ~1 sec on my machine, using LV8.2.1. Hope it could be of some use... :-) //Mellberg

Hi, Using 'Defer Panel Updates' to speed-up the updating of the front panel is sometimes very handy, and when developing GUIs I use it alot. Recently I saw a very strange behavior, using a chart, which we confirmed to be related to the above mentioned VI-property. Try out the example below and try switching the 'Defer Panel Updates'-switch a couple of times and you'll be seeing strange graphical issues in that chart! Download File:post-1154-1191475617.vi This bug was found using LV8.2.1, but NI told me it also existed in LV8.5. //Mellberg

QUOTE(orko @ Jul 2 2007, 04:28 PM) No, it didn't :thumbdown: Thanks anyway!! //mellberg

QUOTE(orko @ Jun 29 2007, 11:13 PM) Ok, I understand! Thank you! //Mellberg

QUOTE(orko @ Jun 28 2007, 06:06 PM) Well, correct me if I'm wrong, but I do have to update the left case-structure too to be compliant with LV8.x, don't I? I guess that I in that case need to have NI's bless to be able to reach and be able to use that reference-constant you're mentioning - the SuperPrivateScriptingFeatureVisible=TRUE & SuperSecretPrivateSpecialStuff=TRUE won't help...? //Mellberg

Hello! I've just written a little test-VI to check if another VI has any structures in its BD that has the Auto Grow turned on, and I do check this by the property node called 'Auto size'. After testing the code for several hours I've come to the conclusion that this property node isn't trustful to use at all. The documentation of it isn't much to have, so the problem could be my lack of knowledge of this function... The problem is that if I manually check a VI which have got 2 structures in its BD and find that none of the structures has the Autogrow turned on, I can still, somehow, get a result from my test-VI that the actual VI do have one or more structures with Auto grow on. But not always. The thing is that this little test-VI is part of a feature-rich development tool I've written, and when running this test-VI inside the development tool it seems to ALWAYS give me a false result. But when I run the test-VI more or less standalone it never gives me an false answer, AFAIK, until i startup my development tool and run the same test in parallell. In my development tool I do NOT mess with the Auto size property... Obviously it is hard for you to understand what I'm doing inside my development tool, and if that could interfer with the Auto size property, but instead of focusing on that I would like to ask: Had anyone else experienced a similar problem where you find that any of the hidden BD property node features tend to be untrustful? I'm attaching my little test-VI if anyone would like to check or comment... The code was made with LV7.1, and then converted to LV8.2. Thanks! //Mellberg

QUOTE(Mellberg @ Apr 2 2007, 02:59 PM) According to NI here in Sweden, this bug is solved in LV8.5. //mellberg

NI's 'BugID': 48188CE8

I discovered a bug yesterday. I hope it hasn't been reported before - I did a search here on LAVA, but couldn't find any similar... I'm not sure if it's only related to LV8, but my guess is that it also affects all other versions where it is possible to recall the VI's path via the VI Property node. If you have one Main.vi which is located in C:\temp\ and one SubVI.vi which is located in C:\temp\SubVI\, where the SubVI.vi is used inside the Main.vi, both pathes of these two VIs will tell the truth - the pathes will be as mentioned here. However, if you now change the name of the folder 'SubVI', located in C:\temp\ to instead be 'subvi', and check the pathes with VI property node, the pathes has not changed. So what is the problem? On a Windows system the pathes are case insensitive, but if your using ClearCase of may be running Mac OS X or UNIX, pathes are case sensitive, AFAIK. If you would like to test this yourself, you have to always open the Main.vi - NOT the SubVI.vi, because if you open the SubVI.vi before the Main.vi the 'bug' doesn't exist. You should also close LabVIEW inbetween the initial verification and the second test. This has been reported to NI.

NI's 'BugID': 44J9B2E8

Ni's 'BugID': 4580H8E8

Hi! This 'bug' is reported to NI. If you create a new VI, go into the default LV icon editor and copy the icon, the copy in the clipboard will NOT be the same as the icon you've copied. This can easily be verified by creating a another new VI, edit the icon and paste the icon you have in the clipboard. If you now toggle between undo and paste, you'll see that some colors are different. This bug exists from LV7.0 to 8.2. Maybe not a big thing, but if you're, like me, indexing all VI/CTL icons in mem to find all defaults icons, your need to have this in mind. //Mellberg

Hi Folks, Just want to report two LV-bugs I found. The bugs are reported to NI. First, if a combo box is set to 'allow undefined strings', you can't write 'ABBA' if 'abba' already exists among the 'strings []', i.e. a pull down-menu item. Second, if a combo box string-item (one of the pull down-menu items) contains a string that is 276 chars or more in length, this can either cause LV to pop up a 'crash' dialog or crash hard without any dialog. These two bugs exists from, at least 7.0 to 8.2, as far as I know. //Mellberg