Yair

QUOTE (Justin Goeres @ Jul 12 2008, 01:13 AM) Does "uh-oh" cover it or should we also make a really worried face? By the way, am I the only one who finds bread with chocolate chips to be a weird concept? Isn't that what you have cakes for?

Watch out everyone! Here comes the 1K hit wonder!

Kelly, relying on control labels is something I generally find potentially dangerous. A more robust method would be using the control references directly. You can see a quick example here (in 7.1, if memory serves). In actual code, I would probably separate the action from the group input, but it shows the concept well enough.

The VI Kelly posted works with control labels. Personally, I find that a potential for bugs and prefer the method Norman used. You can find a quick example here showing how you can move this to a subVI and use different groups and other options.

Crosspost. It is generally polite to link to the other thread when cross posting.

Given scripting access, this should actually not be so hard. Wires have a Joints[] property, which is an array of the points where a wire starts\ends\bends\splits on the diagram. Using that, you can sum the length of each wire in pixels (which you can then translate into KM). You might need some tricky logic to handle all the splits, but it should be doable. Then you need to recursively traverse all diagrams and subVIs. <vi.lib>\Utility\traverseref.llb has a VI which will traverse the diagram and get all references of wires, but it doesn't exist in 7.x.

When you reply, the system quotes by default. When you post two successive posts in a given timeframe, it concatenates them into a single post. Result - I quote myself within my own post. I'll edit it so that it doesn't confuse others.

Maybe it's because I don't file or track CARs (other than an occasional thread), but I don't really get what's so creative about that. Is there something I'm missing?

QUOTE (Aristos Queue @ Jul 10 2008, 10:01 PM) OK, so now I gotta ask, did you place the array outside the loop on purpose? The only difference I can see between the two methods is that the array is folded before the loop, but since the entire loop is folded, I assume that means that the array inside the loop is folded as well and therefore having the array outside the loop should not have any advantage.

QUOTE (Ton @ Jul 10 2008, 08:26 AM) No, but they reinforce each other. QUOTE (Aristos Queue @ Jul 10 2008, 08:07 AM) Unfortunately, my really cool idea for using a stack of semi-transparent VIs won't work... I can't make the panel color itself transparent If you don't mind a Windows only solution, I have an option. If you use the VI I posted here and set the background color to pure white, the background will disappear when you run the VI. You can even set the slide to 255, which means no transparency and it will still work - anything which is pure white is made completely transparent. You can get the window name using the FP Window.Title property. The catch is that I don't know if this is intentional behavior or not. It might be a bug. QUOTE (Yair @ Jul 10 2008, 09:47 PM) The catch is that I don't know if this is intentional behavior or not. It might be a bug. OK, looks like it's not a bug. According to the http://msdn.microsoft.com/en-us/library/ms633540.aspx' rel='nofollow' target="_blank">documentation, the second parameter sets a color which will be completely transparent.

That sounds like an interesting idea, although it does have certain dangers. Here are some thoughts: I assume you're only refering to strings, so an XControl might be better, because it can have properties and its code is encapsulated. I would advise against the use of a brat VI here, because it might be difficult to debug. Instead, you can use some sort of action engine which will accept control references and masks. If you do want the brat VI, using tags might be more robust than the tip strip. They're currently private, but I wouldn't be shocked if they were released at some point. The code itself should be relatively simple, but you should be aware that users might paste into the control, so you will need a way to handle that. Filtering Ctrl+V (and Insert) and disabling right clicking should help, at least on Windows. In any case, you should monitor both Key Down? and Key Repeat? and be sure to handle ASCII 9 (backspace) and the Delete key. Also, be sure to handle the left and right keys. P.S. Isn't LabVIEW 7.0 great? No crashing, no waiting. So much fun.

QUOTE (Michael_Aivaliotis @ Jul 10 2008, 04:40 AM) Well, of course not. Don't be ridiculous! It's the AAAAAAAnti-Wikipedia. P.S. Bonus points for those who recognize the quote above without searching.

Welcome to LAVA. Here are some tutorials which might help you. As for the Excel issue, you can use the Write to Spreadsheet File VI, which allows you to generate a CSV file, which can be opened by Excel. You can make a 2D array from two 1D arrays by using the Build Array primitive.

AAAA AAA AAAAAAA AA AAAAAA AAAAA AAAA.

AAAAAAA.

I was thinking of adding that I'm actually a bit surprised and that I would actually expect it to behave the same way on both platforms (either to optimize or to perform the code literally), but I decided against it, since I figured that Bob probably had a reason to say that it worked fine. I guess I should have tested it myself.

Congratulations on the new blog. I assume that this happens because RT doesn't do some optimizations which LabVIEW on Windows does in order to keep the RT run-time smaller and lighter.

QUOTE (neB @ Jul 7 2008, 04:03 PM) If I understand the concept correctly, LabVIEW only has one meta class - LabVIEW object. All other classes are instances of that class (and I'm not even sure if that's correct, since they could also just be described as child classes). The rectangle is simply a child class of shape (or whatever the hierarchy is in this case) - when you drop one, you are creating an object, not a class.

I didn't really look at all the details, but it looks very nice. One important UI tip from my own experience - when you drop an object, make sure the cursor is at its center, not its top-left corner. Additionally, you might wish to have an outline or a ghost image of the object when you move it. You can see both if you look at how you drop things in LV itself.

Let us know what you end up doing (sample code helps :thumbup: ). I'm sure we could learn from the experience.

Again, I'm sort of writing as I'm thinking, and I'm not exactly an LVOOP user myself, but here goes: QUOTE (neB @ Jul 3 2008, 05:16 PM) The property is indeed an element in the class cluster, and the overriding does play into it - if memory serves, you can have an override and then use the call parent implementation node (or whatever it's called) to perform the code of the parent class as well as that of the child class. This should allow you to move the code which is common to all classes into the higher classes and thus not have to reimplement with every class you create. Since I saw it, I assume there's an example showing this, but I may have seen it elsewhere. QUOTE I think I have to add two children to Boolean, Control and Indicator .... All objects that are of class Indicator or children of such will have their "Control?" property set true and vise versa for Indicator. So the class implies the value of that property so what good does it do me? Not trying to fight over this Q just trying to learn which hammer (Class vs property) to use when designing an app. :thumbup: As you said, the class implies the property in this case, so you shouldn't use the class. Since the only difference between controls and indicators is whether they can be clicked or not, the only thing you have to do for indicators is not register for the mouse down event. That's really easy and doesn't require a whole class, just a property. As I mentioned, the property and the registering code should be in the high level classes (plug-ins or dynamic), so that they are shared by all inheriting classes. Since the value of the property is constant for each class, you can just set it in code when creating the object of that class. I think that to do that you need to call the parent version of the init VI, which will eventually accept that constant. If that parent is removed by several layers, this may be an issue. QUOTE So does implementing the idea of control/indicator get applied at the top of the architecture like it does in LV or is this an application requirement that dicates it should be handled at a lower level? Again, I would say that the object oriented paradigm says that you should implement functionality shared by all sibling classes in the parent class as much as possible, but I'm not really an OOP programmer. QUOTE Your term "init method" got me thinking since I'm initializing my objects in two different ways. That term is not exactly technical. I suppose this should be refered to as a constructor VI, but LVOOP doesn't really have constructors. In any case, the bottom line is the same - objects should only be created by using those VIs, and the VIs should make sure that the objects are created with valid values. QUOTE I think a light buld just went on. My first dozen reads of your response had me thinking that registering was just a synonym for "invoke mtehod". Then when trying to dismiss the possibility you were talking about registering an event it hit me that when I create the object, I could have it spawn off a background process that registers events for the picture control used to house the objects on the GUI. This one word alone may help me get rid of the one AE I am using to direct mouse clicks to the correct objects. So rather than filter the event and invoke a method from the GUI, I could let each background process filter if the event (Mouse Down, Mouse Move, Mouse Leave, ...) applies to itself. I WILL be giving this much more thought. I was actually refering to registering for mouse down events, and I'm not sure, but I think having a single point for registering those events (as I believe you've posted recently) is actually better. The registering will tell the AE (or whatever) the position, shape (possibly a hierarchy of classes as well) and Z-order of the object and the process will be responsible for finding the object which was clicked on (since it has the info of all objects) and sending the click to the object if it is valid. Of course, maybe the other method is better, but I don't like the idea of multiple event structures when one should be enough.

Welcome to LAVA. This might help you.

Duplicate.

Off the top of my head: Add a style property (control\indicator, enabled\disabled, etc.) to the dynamic class (or even the plug-ins class, if you want to have the option for the future). Then, in the init method for that class, do the registering based on the style. Since your styles are currently constant, you can set the property in the init VI for each class and then call the parent implementation to do the registering. You can also add VIs for changing that property which will also register\unregister the event. In general, for something like this, you might wish to look at how its implemented in LabVIEW itself, because presumably NI put some thought into it.

I'm not a big fan of this idea, because it causes annoying changes in the UI. Instead, what you might want to do is use some other way to make the current tab stand out. You can do this by enabling multiple colors on the tab control and then using the Pages[] property to color all other pages in another color. Another option is to create your own tab selector. This takes more work and is a bit annoying when modifying the tab, but it gives you more power and looks better. See a simple example attached (saved in 8.0).