MikaelH

I have always wondered about this behavior, but just accepted it. If you do this by the invoke nodes VI:Save.Instrument and select “Save a Copy=True” the master VI don’t get changed. Nice thing is that the new cloned VI gets disconnected from the class. So it will not modify your class automatically, instead you have to add it as a second step where ever you want it.

You're using the right property node! Try taking the working graph in your Toy Example, and copy the graph and replace it with the one in your main application. //Mikael

Hi I got the same bug in one of mine VIs. See VI Property: Allow debugging, My VI don't work if I turn off the debug option Check for data coercion dots in your sub VI, and typecast them manually, that might do the trick. //Mikael

QUOTE(crelf @ Sep 12 2007, 07:58 AM) Yes your absolutely right there !! Finally the spring is here, we had 28°C a couple of weeks ago, and the week after we experienced -2 and snow. (It might be because we went 5 hours South-West from Sydney up to the snowy mountains)

QUOTE(Harish @ Sep 5 2007, 09:55 PM) Here's an undocumented GOOP class I've used in the past (just upgraded it to 821-lvoop style, and haven't tested it). You need the _goop3.llb in your addons-folder. (you can get it through the GDS tool). Download File:post-941-1189566714.zip Cheers, Mikael

Welcome Colleague I guess you won't see me at the office that much since I took Chris Relfs position at NVSI in Sydney. But I still work for Endevo in the evenings, nights and weekends Cheers, Mikael

Thanks, //Mikael

I have an old VI I haven't touched for ages, but suddenly it gave me wrong result. Try the attached VI, and run it and look at the PictureOut indicator. Now change the VI property: Allow debugging to OFF, and run it again. The PictureOut's result changes. Have I done something wrong?!? You have to excuse me for the nasty code behind this VI, it's an old one. Download File:post-941-1189392546.vi The behavior is the same in 8.2.1 Cheers, Mikael

Funny you should mention this, because I was just thinking of creating an application like that, and then do the "tray icon" part as a .net Class library. You can then create the "Icon tray" object set its properties/icons and then when a user interacts with the system tray icon the .net part fires call backs to LabVIEW. I've done a similar project before and the callback works great. If I have time to finish the code I'll post it here. //Mikael

The front panel grid works fine but I would like to see the Microsofts Visual Studio approach some day. It shows you help lines when you reached edges of other objects like this picture. http://forums.lavag.org/index.php?act=attach&type=post&id=6808 --Mikael--

But if you place the List Box Value event after the Numeric Value event it should probably work?!?! I guess it's depending on the speed of your computer if it has time to do the event numeric change before the list box value change. I put a small timeout in the example and got the "wrong" behaviour, and then I just rearranged the events and it worked again. Cheers, Mikael

This is a known problem in LabVIEW 82(1). I've had to live with it until NOW when 8.5 is out. You can ignore the rename problem unless you try to load these VIs/Controls dynamically. But you have to build it in debug mode. What happens in the process is that some VIs have been saved without block diagram, and then a VI needs to be renamed, that works fine, but now a VI that already was saved without block diagram has to be recompiled, and it can't handle that. There are still issues with one of my large projects that I have had these problems in, even for LabVIEW 8.5 but it works better. If you still like to use 821, build it with debug-flag on, and then manually remove the block diagram of all class VIs and VIs inside the exe-file. You can extract the llb from the exe file by removing the header in the exe-file until you get to the word "RSRC", this is where the llb starts. Extract it, remove the block diagrams and then put it back in the exe file. -Mikael

QUOTE(Aristos Queue @ Aug 23 2007, 11:38 PM) The default values is visualized like this: MyAttribut:int=23 MyObject:BaseClass=LeafClass But the UML modeller don't look at the default values right now. When it comes to the default values for a referenced based class, these default values should be wired up in the Create/Constuct-method. You could still add the equal sign in your design when generating code, but when you do a reverse engineering those will be overwritten. -Mikael

QUOTE(Aristos Queue @ Aug 23 2007, 01:56 PM) That's a tricky one, I guess it has to do something with garbage collection. Here is how it looks if you analyse it with a LabVIEW based UML Modeller ;-) http://forums.lavag.org/index.php?act=attach&type=post&id=6725 BTW, how do you set the default data to a leaf Node in the Map class attribute named Root which is a Map Node Object? Cheers, Mikael

QUOTE(Jim Kring @ Aug 23 2007, 08:19 AM) What I thought was that the new 8.5 VI "Get LV Class Default Value.vi" is just the 2 VIs you mentioned wired together. I use it like that in 821, but haven't tried it in an executable. BTW I like the new "Get LV Class Path.vi" found in 8.5 in the same folder :thumbup: //Mikael

You have to start by creating the child object (analyzeSpec), but you can then of cause use it as it was a normal listSpec object, but now you have the option to use the childs methods as well. To be able to convert it from a base to a child in runtime is not allowed, maybe it will be some day. See Wish List , Post 8- //Mikael

QUOTE(orko @ Aug 23 2007, 07:19 AM) I guess you're using 82(1) But it's better than my 8.5 version, because now the project tree list won't scroll when you get to thew edge with your dragged item. It worked perfectly in 821, anybody else got this problem? But maybe you sould upgrade to 85, since you can connect a folder to a physical disk-folder so it auto updates all it content. My top 8 list of new features in LabVIEW 8.5 <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">When double clicking on a SubVI on the block diagram that is a dynamic dispatch VI, you can select which implementation VI to open. <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Auto-populating folders (and that it doesn't add hidden folders like .svn) <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">To see the path of the VI in the project tree. <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Possibility to set scoop on item in project tree by right clicking on the item. <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">And of cause recursion!!! <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Conditional stop terminal in for loops <LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Finding callers on SubVI by right click on item in project tree. Mass compile project by right clicking on the Project node in the project tree. //Mikael

The cell is blocked for user input, so it won't update. But you can get it to work by changing the Mouse Up event to "Mouse Down?", and set the "Discard?" option to true or false depending on your application. But to be sure that your Cell update is executed before the "User input block", you should update the cell in the "Mouse Down?" event case. //Mikael

Colleagues of mine have had just the problem; the Java Application was controlling a telecom base station. The solution was to send XML-typed data through TCP/IP. //Mikael

If you try running it from another application instance, it will be even more "locked". Especially if you open en reference to a class from several Application instances, it gets locked. I have had lots of problems with this for the Project Tree Addon tool (GOOP Development Suite) I'm working on, since that code is running in a "NI.LV.MxLvProvider" application instance. Also you can get LabVIEW to crash when messing with too many open application instances ;-) //Mikael

QUOTE(Aristos Queue @ Aug 19 2007, 04:17 PM) But of cause you shouldn't use Equal, when comparing floating point numbers. Use something like this instead: http://forums.lavag.org/index.php?act=attach&type=post&id=6696''>http://forums.lavag.org/index.php?act=attach&type=post&id=6696'>http://forums.lavag.org/index.php?act=attach&type=post&id=6696 //Mikael

QUOTE(Jim Kring @ Aug 21 2007, 11:23 AM) I've just tried it in 8.5 and it doesn't work their either. I guess you can't set it on a running VI //Mikael

QUOTE(Ale914 @ Aug 21 2007, 06:13 AM) Since the main goal for extreme programming is to reduce the cost of change, I find that a proper OO-analysis and OO-design solves that problem. I've been using GOOP with inheritance since 2001 and I always start with a UML class diagram to visualize my needed classes and their dependencies to make sure changes are easy to add later on. Below is a class diagram describing parts on my current project. http://forums.lavag.org/index.php?act=attach&type=post&id=6692 //Mikael

I'm, guessing you have to place the check in the timeout case, and poll the window bounds. VI:Frontpanel.WinBounds If you want to know as soon as the mouse is clicked on the title bar, you have to use the InputDevices.llb\ Mouse VIs. These will get you the current mouse postion and button states and then compare them to you VI window positon. //Mikael

Your right, I'm always thinking in reference based objects In java it look like like: SubClass MyClonedObject= (SubClass ) super.clone(); Also I prefer protected attributes, when will that be available ;-) http://forums.lavag.org/index.php?act=attach&type=post&id=6666 //Mikael