Jim Kring

QUOTE (Aristos Queue @ Mar 26 2009, 07:21 AM)

Jim: In situations where there are several valid choices in behavior, why not make sure that whatever you ship allows all possible behaviors and then improve access in the future if some of the hard-to-reach behaviors turn out to be in high demand? With LabVIEW's current behavior, if you want to rename all the VIs, you can, and if you want to rename only one, you can. All behaviors accounted for. If LabVIEW renamed everything when you renamed one, you wouldn't be able to rename just a subset. Functionality loss. Why didn't we just add both mechanisms initially? Consider the issues this feature raises:

1. Adding the rename all would be additional code to implement the feature plus new menu items which I am guessing there would be severe pressure against since it would push up the already mind boggling complexity of the Save As options dialog (you'd now have two different kinds of SaveAs:Rename, which is, currently, the one easily comprehendable option in Save As).
   
2. Suppose you chose SaveAs:Rename:RenameAll on a child implementation VI. Do we then rename the child and descendants or do we go rename the ancestor as well? Or do we make more options in the Save As dialog so you have three options for Rename instead of two?
   
3. What if some portion of the inheritance tree was currently reserved or locked because it was read-only on disk... does the entire Rename operation fail or do we rename those that can be renamed?
   

Very quickly this turns into a significant feature requiring a significant slice of developer and tech writer time. Most editor improvements do. The path of least code provides all the functionality albeit without the pleasant UI experience. We go with that unless there is a compelling usability reason to strive for the better UI -- which generally means either we predict the feature will be unusable without the improved UI or after release we get customer requests for a particular improvement.

I have a list of something close to 100 purely editor UI improvements that we could make specific to LabVOOP (LabVIEW itself has thousands upon thousands). I have around 20 major functionality improvments requested. In general, my team has time to implement between 3 and 5 per release as the rest of the time is generally given to 1 or 2 functionality improvements (functionality improvements are generally much harder than editor improvements because you have to implement the functionality and then you still have all the UI problems that editor improvements have). When you make requests, please phrase the priority of those requests accordingly. It helps us decide what to work on next.

I'm sorry if my post made it sound like I was complaining. I was simply making a feature suggestion.

Regarding priority: if it was really important, I would have been much more emphatic (or possibly written a tool to do it myself) -- you know how passionate I get when I'm really excited or pissed about something

Now, if you'd like to show me your list of 100 editor UI improvements, I would be happy to review and prioritize them

Thanks for all your hard work -- it seems like we've all been asked to do more with less, lately.

AQ: In situations where there are several valid choices in behavior, why not prompt the user to choose (and maybe give them an option to not ask again and use their current choice in the future, if that's appropriate)?

Mike: It sounds like you've been spoiled by great programs like TortoiseSVN that, when you rename a file (like changing a prefix), will find other files next to it with similar names (that you are likely to want to rename) and ask you if you want to apply the same renaming operation to them, too. Maybe one day LabVIEW will have a great feature like this, too

QUOTE (okeen @ Mar 24 2009, 03:46 PM)

Hi, I am fairly new to labview and I am trying to open an XML file and have it load into a cluster. I have attached my vi and the xml file that I am trying to open. If you guys could lead me in the right direction that would be great. Thank you

Here's an example of how to use EasyXML to do this:

Download File:post-17-1237937606.vi

PS -- come on Omar, why not post an example

QUOTE (xuniL @ Mar 22 2009, 08:23 PM)

I'm part of a small and growing LabVIEW-based consulting company that has outgrown its peer-to peer network and looking for the best file server solution. I'm hoping to learn from somebody else's experience and maybe even get a little debate going.

We are currently using Tortoise SVN for version control on a portable USB drive and want to move it to a dedicated file server. And while we're at it, let's throw in web access so we can commit and update files from off-site. So, we're looking at anything from:

a. Buying a new full-blown server running Microsoft Windows Small Business Server 2008

b. Dusting off an old PC and installing Ubuntu

Any suggestions?

Whenever possible, use a hosted solution from a company you trust. As PJM said, stick to LabVIEW and leave the IT headaches for the pros (masochists).

Here are several companies that offer subversion hosting (note: I'm not recommending any of them). You can find others by googling "subversion hosting".

http://cvsdude.com/

http://wush.net/

http://svnrepository.com/

http://www.codespaces.com/

Good luck,

-Jim

QUOTE (gmart @ Mar 18 2009, 06:20 PM)

In general, no. I was trying to cover my bases since it's possible that a library owns a class and such. In that case, loading a library would load VIs but only due to a class being a member of the library.

Thanks for the clarification.

QUOTE (gmart @ Mar 18 2009, 03:13 PM)

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

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)

I thought I would poke this thread and see if we can get it started again...

In the past six years doing TDD I've only actually unit tested a handful of private class methods, I would say less than four. I subscribe to what I feel is the overall tone of this thread, we shouldn't be testing private methods for all of the reasons given above.

However, that said, I agree with Jim, if I know what I am getting into there should be a method to unit test private methods.

In VS2008 you can do it, however they really make you really work for it, there is a whole dance you need to go through with reflection to load the assembly and to unit test it. It is a pain, but it can be done.

I think as VI Tester goes forward it would be nice to have the option, but an option that has a cost to the developer. Inflicting this cost would make a developer think twice about wanting to actually do the unit testing this way, and may in turn cause them to refactor their code to a cleaner implementation if at all possible.

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)

Is this an edit time or run time bug?

Ton

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)

As a workaround to that, rename the class file, load the typedef, edit it, then rename the class back to its original name and open it. This shouldn't be necessary, but since you're working around the other bug, this workaround becomes useful.

An easier solution would be to

1. open and edit the typedef,
   
2. don't save any other changes,
   
3. close all VIs,
   
4. reopen the project, and then
   
5. save all changes.
   

QUOTE (ned @ Feb 23 2009, 07:25 AM)

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 frames
  • Note 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 frames
  • Note 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)

Thank you very much for the heads up Jim! :thumbup:

I wonder if that is realated to ?CAR# 117209 ? where edits of a type def cluster could show an analogous effects. The suggested work-around was to edit the type def with the callers closed and only open them after the change. I worked up a duplicate of your code in LV 8.5 and duplicated the bug you demoed.

I converted it over to a type def version and achieved a similar effect by deleting an element from the type def hit apply changes, then did an un-do in the typed def and hit apply changes again.

I then backed-up and tried the edit of the typed def with the caller closed and it did not mix up the events.

So editing type def with callers closed may help you work-around/avoid this issue. Yes I am assuming you are using type defs in your real code.

Just trying to help,

Ben

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 frames
  • Note 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 frames
  • Note 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.

If I add an automated backup feature of the deleted/removed method then it would be quite safe.

We're just about to release a new version and I'll see if I can squeeze this function in.

You can clone a method (from the base class), to one or all siblings, see image below:

I haven't added the function of sending a method to several other classes but it's a small task to do that.

I can create a beta version for you during the weekend if you are interested?

> 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)

I have a solution which is to use the GOOP Development Suite for your native class. Sorry about the plug...

There is a feature called "Clone VI" which allows you to clone a VI a and select a new class (and VI name). The new VI will be properly linked to data types of the new class. The icon will also be fixed of course.

Right click on the VI and select: GOOP->Clone VI...

Try it:

http://www.endevo.se/index.php/en/Products_Info/Trial.html

Community Edition is free.

QUOTE (MikaelH @ Feb 19 2009, 05:02 AM)

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)

Confirmed (v8.6).

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)

Actually he is an XBoxer- call of Duty type. I asked him to think about writting something up after he started to rattle off a buch of stuff but stopped and said, It's really complicated!". He did say he would try to put something together.

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)

I can't give you an exhaustive list but here are some notes (well at least one worth reading)

1) Property nodes executed prior to the web-srever being fully up do not always work. We were setting the string for a ring control too early and they would not show up. Doing so after the server was running no issues.

2) Whenever possible, find a young co-worker to develop the app. It saved me a lot of headaches.

3) A sign on the side of the equipment cabinet reading something to the effect "Warning! Parking this cabinet over a high pressure steam vent is a very bad idea."

Well at the least the first one was worth sharing.

Ben

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)

For those of you interested, I posted this question on the NI Forums and got some good responses. Here is the link:

http://forums.ni.com/ni/board/message?boar...hread.id=349998

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,