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

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 A handy side effect of this is that you can acquire images using IMAQ with a 3rd party CameraLink board without any license (since camera link uses plain IMAQ, rather than IMAQdx), but if you use a GigE camera then you need IMAQdx and therefore you need a license. Something to think about if you are building a vision system and have a choice of hardware interfaces! 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.

The Vision Common Resources install is FREE and allows you to use the IMAQ image control in your application. You don't get any image processing but it is fine for loading images and displaying them with all the ROI tools. I believe the only bit you need a license for is IMAQdx...

You forgot "Inability to use in arrays"

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. 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: Poll the mouse button (e.g. user32:GetAsyncKeyState) to know when drag has ended Manually move the floating panel into position (I use user32:SetWindowPos) When mouse button is released then reset timeout back to -1