fabric

I've enjoyed this hack for many years, but noticed it is not working in LV2023Q1. 

See here for problem description: https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-05-10-2010/m-p/4360614/highlight/true#M1280554

FWIW, here is an idea I recently posted that addresses one of the major sources of unnecessary bends...

To be clear I don't think the toolkit is free (someone correct me if I'm wrong).  What is free is the deployment of a EXE that uses a subset of the Vision toolkit components.  So you pay for the Vision Toolkit, develop code in it, then build an EXE.  If the toolkit VIs you used, included image processing functions, then you must pay for a run-time license on each machine that runs that EXE.  If you only use the other functions of the toolkit then you can get away with making an EXE and not need to pay per seat by using what was linked to.

Actually it is a little better than you think...

If you install the Vision Acquisition Software (i.e. the dev toolkit) then you don't need a license at all provided you UNCHECK the IMAQdx component... Magic!

Of course, this will limit you to basic Image Management functions, but if that's all you need then you you don't need to pay half a year's salary for a full Vision license 

I don't know what the overhead of the picture control is? It seems to work well but like i mentioned I am not doing any heavy processing

I tested this a little while back. Let's say you have a 1024x1024 RGB image:

• The IMAQ control uses 4MB to display the image, as expected since the underlying data type is u32 (4 bytes per pixel). Pretty efficent.
  
• The picture control uses 7MB which includes 4MB to display the image plus an additional 3MB for the input data. Why 3MB for the data? Well, the picture data is smart enough to know that an RGB image only has three bytes per pixel that are worth encoding. 
  

Note that the IMAQ control doesn't have the overhead for the input data since IMAQ images are by-ref.

A few inconveniences that come to mind:

 

...

You forgot "Inability to use in arrays" 

... but I have a vague recollection that this had to do with compiled code separation

Yes - my compiled code is separated...

By the way, my current workaround for this is the old "pre-save, change, check, re-save" routine.

• Pre-saving the project before making any changes is starting to become second nature before editing any enum typedefs.
  
• Checking is a pain if you're paranoid, but usually I can tell if morphing has occurred by looking at any one instance. There seems to be an all-or-nothing pattern here...
  
• If there is suspicion, then I have found that saving the enum and then reverting the entire project usually does the trick, i.e. the morphing seems to be an edit-time effect and generally does not occur if the project is re-opened with a modified enum. (At least, this is what I have seen when adding values or deleting unused values...)
  

Yeah. I guess empathy was what I was shooting for. 

 I think almost all of the time I am adding new values to the end, not updating, or removing them, maybe this is safer since the constants already in my application aren't having their values changed.

There might very well be something in this. Today I added a value in the middle and I think I often do that when the morphing occurs.

Grrr... It's happening more often now.  I'm sure I've read about it here before but maybe it's time to table the issue again:

• I'm working on a large project, and I'm running LV2012 32 and 64 bit on Windows.
• I have an typedef enum inside a class. The enum happens to be the sole member of the class private data.
• The enum is public and is used here and there all over my application
• I decide to add another value to the enum and ... BAM! ... All instances throughout my project are reset to the first value of the enum.
  

Kind of defeats the purpose of the enum, don't you think?!

What do other people do? Define all enums fully during the design phase and never change them again? Label each instance of the enum with the desired value to provide some insurance against morphing? Don't use typedefs and update them all manually?

A simple solution is to put a collection of buttons in a cluster and set to arrange horizontally. Then you can show/hide buttons according to context using property nodes. Just use an event handler to detect clicks. How much easier can it be??

<blockquote class='ipsBlockquote'data-author="Mike Le" data-cid="101054" data-time="1359502271"><p>

This makes sense, but does that mean EVERY time the UI queries a setting, it has to go through the Controller to query the Hardware Actor?

</p></blockquote>

The preferred way to think about your actors is that they post information, rather than requesting it. That turns your issue around slightly:<br />

- The hardware actor stores it's own settings. If they change then it notifies someone who cares... probably the controller, which in turn notifies the UI.<br />

- The UI then does what it wants with the information.

Does the sequence need to change dynamically? If not, then a chain of sub VIs is hard to beat :-)

Could this syntax be adapted to specify certain class data as protected or community scope? That would probably be of more interest to me...

I have done something similar using win API calls:

• Use event structure (with timeout = -1) to detect the original click on the thing you want to drag
• When a Mouse down is detected then store the starting position and toggle the event timeout to ~10ms
• In the Timeout case of the event structure, do two things:
  

1. Poll the mouse button (e.g. user32:GetAsyncKeyState) to know when drag has ended
2. Manually move the floating panel into position (I use user32:SetWindowPos)
   

• When mouse button is released then reset timeout back to -1
  

... we are years away from even thinking about UI gestures for this. Keyboards may be obsolete by the time it is done. Years. No, I'm not joking, exaggerating, making stuff up or trying to set false expectations.

Just years? Excellent!! I was thinking it would be somewhere between decades and never...

The feature to have LV able to zoom its diagrams/panels/etc is one that we are indeed working on...

Really?! Then can I put on a request for "CTRL +" and "CTRL -"? It works amazingly on adobe apps, and after a few hours of icon editing I'm always disappointed to come back to LV and find that my muscle memory has disappointed me.

Reminds me of all those touchscreen projects... After a few hours of testing I've been caught out tapping the "normal" monitor back at my desk...

I'd say the single best thing you can do to fix all (yes, all!) the issues you mentioned is to restructure your code with the intent of simplifying the dependency tree and reducing cross linking.

If many of your libraries are statically dependent on other libraries then you can quickly end up with a very complex dependency tree. This is compounded when using classes since loading any class member causes the entire class to load, as well as any owning libraries. (Sticking a bunch of classes in a .lvlib can cause major IDE slowdowns...)

Many of us have seen great benefit in using interfaces to abstract the low-level layers from the application layers. This is a big plus for multi-developer environments and for improving load time and IDE performance. You might want to read up on the Dependency Inversion Principle.

A few lava links:

• http://lavag.org/top...d-vi-templates/
  
• http://lavag.org/top...existing-class/
  

And you might want to vote for this idea over on the blue side - you could be vote #100!

• http://forums.ni.com...s/idi-p/2150332
  

Cross-posted to the blue side: http://forums.ni.com/t5/LabVIEW/VI-object-cache-shared-between-32-and-64-bit/td-p/2230316

I think this is probably due to the fact that 64 bit is a different platform. This means you open the VI and the compiled code is for the wrong platform which forces a recompile. Even with a seperate object cache I think that because the compiled part of the VI file is for another platform it has to start again

(null)

Right.... but if there was a separate VI obj cache for each platform, then most VIs would NOT need to be recompiled when switching versions.

At least that's how I think it should be!

My current project contains around 5000 VIs, so the unwanted recompile is a bit of an inconvenience...

Does it help if you use seperate LabVIEW data folders?

Ton

Maybe... How do I do that??

(I'm running LV 2012, by the way)

Ok... here's my test:

1. Open LV32
   
2. Make a new VI, save it
   
3. Close LV32
   
4. Check timestamp of "objFileDB.vidb" file.
   
5. Open LV64
   
6. Open previous VI and run it (but don't save it)
   
7. Close LV64
   
8. Check timestamp again and notice that it has changed.
   

If I open my VI in a different version of LV but don't run it, then the timestamp of my obj cache file doesn't change.

Conclusive? Maybe not... but interesting!

I am currently working on a large project that needs to be deployed in both 32-bit and 64-bit flavours. This means I need to periodically switch between installed LV versions to build.

It *seems* that if I have been working in 32-bit LV, and then I close everything and reopen my project in 64-bit LV, that everything needs to recompile... even if I had only changed a few items since I last worked in 64-bit.

It appears that while LV does keep a separate VI Object Cache for each LV version, that it does NOT keep a separate cache for 32- and 64- bit versions. Is this really the case?

There's an ongoing "Idea Exchange" thread floating around on Lava users typically use to promote their ideas. Nothing wrong with putting it here, but it might get more visibility there.

Ahh... thanks for the heads up :-)

... In theory I suppose it would be possible to postpone loading the entire class until the class ctl editor is opened, but there may be other reasons why that is unfeasible.

I think this would be a great leap forward. A large number of class edits do *not* affect private data. It would be great if these edits could be made quickly and easily without necessarily loading a bunch of member VIs and dependencies.

FYI: I've just posted on the Idea Exchange about improving IDE performance when working with classes. Would be nice to get some more visibility on these issues!

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-IDE-performance-when-working-with-lots-of-classes/idi-p/2150332