Jim Kring

QUOTE (gmart @ Mar 18 2009, 03:13 PM) Hi George, I apologize, in advance, for not reading this whole thread (or testing to answer my own question, below). I just have a quick question: Are lvlib members really also loaded into memory when the project is loaded? I thought that only class members were loaded into memory when the project was loaded. Thanks, -Jim

QUOTE (benjaminhysell @ Feb 24 2009, 08:58 AM) We've given a little thought about how we might be able to unit test private methods, but none of them are easy, to say the least. This will probably be a very low priority, in the near term.

Has anyone encountered this? I have a customer who complains about the following: When I start LabVIEW 8.6 with my network connection active, it takes a long time. But, with the network disabled/unplugged, it starts up very quickly. It's worth noting that this doesn't happen in 8.2 Any LabVIEW.ini keys or other settings that might help?

Since (I think) nobody has mentioned it, yet, Agilent VEE has a feature like this and I never really understood or liked it.

Hi Tomi, Congratulations on this big step. I have no doubt Agile4 will be a success -Jim

QUOTE (Ton @ Feb 25 2009, 10:19 AM) It is an edit time bug in LabVIEW that creates a run time bug in your application.

Update: CAR 148149 assigned by NI.

QUOTE (Aristos Queue @ Feb 23 2009, 01:48 AM) An easier solution would be to open and edit the typedef, don't save any other changes, close all VIs, reopen the project, and then save all changes. QUOTE (ned @ Feb 23 2009, 07:25 AM) Aahh, the frustration. I never knew that Register for Events accepts a cluster of user event references (and I haven't seen it documented anywhere). Do I take advantage of this trick to clean up my code, or stay away from it to avoid this bug? Unfortunately, avoiding clusters won't help you avoid this bug. Below, is another example using scalars and multiple event terminals on the Register for Events node Short Video Demonstration of the Bug (using scalars instead of clusters) And, here's an example VI that you can use to test it for yourself: Download File:post-17-1235412403.vi Steps to Reproduce Open "Dynamic Events Bug (scalars).vi" Cycle through the Event Structure framesNote the contents of the frames for Event A, Event C, and Event D. Note the cluster constant with user event reference constants for Event A, Event B, Event C, and Event D [*]Delete the Event B user event constant. [*]Right-click on the second User Event terminal on the Register for Events node and choose Remove Element. Observed Results Cycle through the Event Structure framesNote that contents of the Event Structure frames for Event C and Event D got swapped: the contents for Event C are now associated with Event D. Expected Results The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)

QUOTE (neBulus @ Feb 22 2009, 07:17 AM) Hi Ben, Thanks for the information. This is very helpful. The only problem that I see with the work-around you mentioned (editing type def with callers closed) is that I use classes a lot. And, having any member of a class (e.g., a type definition that is a member of a class) will cause all class members to be loaded into memory (e.g., VIs with Event Structures whose dynamic events use the type definitions). Thanks, -Jim

[CAR 148149] Background There is a bug in the Event Structure where code in frames of an Event Structure can get re-associated with a different/wrong Dynamic Event when the input event reference data of a Register For Events node changes. Short Video Demonstration of the Bug And, here's an example VI that you can use to test it for yourself: Download File:post-17-1235239395.vi Steps to Reproduce Open "Dynamic Events Bug.vi" Cycle through the Event Structure framesNote the contents of the frames for Event A, Event C, and Event D. Note the cluster constant with user event reference constants for Event A, Event B, Event C, and Event D [*]Delete the Event B user event constant from the cluster constant. Observed Results Cycle through the Event Structure framesNote that contents of the Event Structure frames for Event C and Event D got swapped: the contents for Event C are now associated with Event D. Expected Results The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)

QUOTE (MikaelH @ Feb 19 2009, 03:49 PM) > I can of cause add a checkbox that allows the tool to delete any existing method before, but that's a bit scary. How about adding an OK/Cancel confirmation dialog letting the user know that pressing OK will overwrite existing files (if that's the case). That wouldn't scare me at all. Plus, I use Subversion and commit my code very frequently > You can clone a method (from the base class), to one or all siblings, see image below: How about adding another option for New VI Owner called "<Clone VI to Selected Sibling Classes>" that populates the bottom list with a list of all the sibling classes? > I can create a beta version for you during the weekend if you are interested? Of course I am Thank you very much, -Jim

QUOTE (Jan Klasson @ Feb 19 2009, 01:41 AM) QUOTE (MikaelH @ Feb 19 2009, 05:02 AM) GOOD NEWS this feature works on normal LVClasses made without the GDS tool. (Of cause I can't understand how you can work with classes without this tool ;-) The function also supports cloning one base class method to several child classes at once. So install the GDS tool, and just right click on the VI, and select GOOP->Clone VI... Hi Jan and Mikael, Thanks for the tip. I actually did already look in the GDS tool (which I have installed and use, regularly) and was not sure what "Clone VI" did. I tried it, but it doesn't work for me. Here are the problems: 1) My sibling class already has an instance of the method that I'm trying to clone. The GDS "Clone VI" dialog will not permit me to make a clone that overwrites/replaces an existing method. 2) The GDS "Clone VI" dialog only permits sending the new clone to a single class. I want to send it to about 30 sibling classes. Ideally, I don't want to have to do a "Clone VI" operation 30 times. Thanks, -Jim

Thanks for your responses. Here's some more background: Each sibling class has some data that needs to be obtained as a flattened string in little-endian byte order. How can I put this code snippet in only one VI without the use of variants?

[cross-posted to ni.com] I have a situation where I need to duplicate some code in sibling methods. Ideally, I would put this code inside the parent class, but for performance reasons (I don't want to use variants) and a limitation in LabVIEW's edit-time type adaption/propagation, the code must in the child class. This means that every time I want to change the implementation of my code, I have to duplicate the code in the sibling methods. What I'm looking for is an easy way to copy a method into a sibling. Now, I can sort of do this with a "Save a Copy As" operation, but then I have to manually relink the copy to the sibling classes data types (such as the object/class-private-data, etc.). Has anyone solved this problem? I'm tempted to try to automate this using either scripting or by modifying the linker info on disk, as described below: Copy "ClassA.lvclass:Method.vi" (<MyProject>/ClassA/Method.vi) to "ClassB.lvclass:Method.vi" (<MyProject>/ClassB/Method.vi) on disk. Modify the linker info of "ClassB.lvclass:Method.vi" (<MyProject>/ClassB/Method.vi) on disk, such that every instance of "ClassA.lvclass" in the linker info is replaced by "ClassB.lvclass". I've got to do this periodically for about 30 sibling classes, so it's starting to make sense to automate this task.

Hi John, Thanks for posting this. This is very cool in several different dimensions! :thumbup: -Jim

QUOTE (crelf @ Feb 14 2009, 09:35 AM) I've reported it in the LabVIEW 2009 Platform beta, too, so maybe that will expedite a fix.

In the Project Explorer hiding both the "Standard" and "Project" toolbars hides all toolbars the next time project is opened. Steps to reproduce: 1) open a new project 2) hide the "Standard" and "Project" toolbars, by right-clicking on the toolbar and unchecking them 3) show at least one other toolbar (such as "Build" or "Source Control") 4) close the project 5) open new project ==> note that all toolbars are hidden -- THIS IS A BUG 6) right-click on the toolbar and show the "Standard" or "Project" toolbar. ==> note that several previously hidden toolbars are now visible

QUOTE (neBulus @ Feb 12 2009, 01:07 PM) Hi Ben, Thanks for asking him. > "It's really complicated!" All the more reason for us to be sharing our info Thanks, -Jim

QUOTE (neBulus @ Feb 12 2009, 11:40 AM) Hey Ben, Thanks for the info. Would any of your "young co-workers" have any info they'd like to share, too? Or, are they too busy Twittering and Facebooking with thier IM buddies? :laugh: -Jim

QUOTE (jlokanis @ Aug 19 2008, 10:15 PM) John, Thanks for stirring up that conversation. It was very enlightening. I'm curious: have you (or anyone else here at LAVA) had success in deploying web services in LabVIEW? The process seems very non-trivial and I'm wondering if those who have tried it have any advice, best practices, or list of gotchas that they could share. Thanks,

QUOTE (Val Brown @ Feb 4 2009, 12:41 PM) Don't forget that text-based languages are inherently open, in the sense that you can use any editor to read and modify the sources.

QUOTE (Jim Kring @ Feb 14 2007, 05:39 PM) To close the loop, on this thread... JKI has just released VI Tester, a software (unit) testing framework for LabVIEW. See here for details: http://blog.jkisoft.com/news/jki-announces...se-in-jki-labs/ Thanks, -Jim

You might have seen the announcement, already, but JKI has just released VI Tester, a software (unit) testing framework for LabVIEW. See here for details: http://blog.jkisoft.com/news/jki-announces...se-in-jki-labs/ Thanks, -Jim

QUOTE (Herbert @ Feb 2 2009, 10:10 PM) Hi Herbert, That's basically how I feel, too. It's nice to hear you say it (...even if I'm wrong, in theory) Cheers, -Jim

QUOTE (Omar Mussa @ Feb 2 2009, 06:33 PM) Well, writing tests that call private methods means that your tests are broken. Sure, you could make the methods under test public before running the tests via reflection (so that the tests aren't broken when the tests are run), but who wants to do development on VIs that are normally broken?