Yair

I wasn't illustrating an issue with graphical programming. I was illustrating deadlock, which can be found anywhere in life (the plumber won't come to fix the leak until the builder comes to tear the wall down, and the builder won't come until the plumber comes and turns off the water. Deadlock). I wanted a simple example which involved a function call and I wanted to clearly show the lock-unlock part AND I didn't have LV open. All those combined led to that.

I believe the main issue AQ was considering was that a reference always points to a shared resource. Question - When you have a shared resource (e.g. a clerk at the post office), what do you get when you have multiple users who want that resource? Answer - A line. Suppose you just want to buy three stamps, but the person at the top of the line is sending Christmas presents to his 47 cousins. What happens? You have to wait 40 minutes. The same thing would happen in your program - the more bottlenecks you have, the more likely you are to have places in your code which are waiting on other places. In the specific case of references to controls I believe you can incur three additional penalties - If you're writing the value to the control from multiple places you most likely have race conditions. I'm pretty sure that every interaction (at least a write one) with a control's property forces that control to be drawn on-screen, unless the defer updates property is set to T. If you're reading the control's value, you have a memory allocation for the wire, which takes time. DVRs were specifically designed to also not have this problem. All that said, it doesn't mean your architecture is invalid. Passing references to controls to subVIs in order to control or query the UI is certainly valid and would not necessarily slow your program to a halt. If you're trying to do these calls a million times a second while measuring a 5 MHz signal, then you'll probably have some issues, but if you're only accessing them a few times a second, you'll usually be fine. Remember that the comment was "you can kill", not "you will kill".

As I said, I think that the features themselves are great (gotta love Ctrl+R) and I fully understand the logic of placing them in QD. I also agree that it's better to ship a crooked feature than not ship it at all and that no one has to actually use the feature if they don't want to. That said, I still feel that it "just doesn't fit" into QD. It's just a nagging feeling of "WTF?!", even though it works very well and I will probably use it. If QD was changed so that Ctrl+Space opens up a "shortcut dialog" which would list these shortcuts (from which another Ctrl+Space would open QD), it would make some sense, but as it is, it doesn't. If the RCF had keyboard shortcuts you could assign to the plugins once you click the hot-key, that would be cool and would definitely help. P.S. And no, I don't think that the fact that's a plugin framework would help the feeling of wrongness. It's great it can be extended, but it still feels like it belongs elsewhere.

It doesn't allow for classic race conditions (two places changing the same piece of data) because you HAVE to lock the data every time you want to access it (even if it's just for reading). What it does allow are deadlocks, which is what AQ was refering to. If you want a simple example, think of this psuedocode: A{ Lock (Data) B() Unlock (Data)}B{ Lock (Data) ... Unlock (Data)} A and B operate on the same data, so they each begin by requesting a lock. When you call A it request a lock, gets the lock and calls B. B then requests a lock, but doesn't get it because A already locked the data. Now B has to wait until A releases the lock and A has to wait until B finishes execution. That's deadlock. You know for sure you're going to run into this problem if you have a reference crossing the boundary of an IPE structure where it's been used. If you're using a reference in a structure, DON'T let that reference cross the boundary of the structure. Presumably the issue Jim ran into is more complicated, but the concept is basically the same - when you have a lock, you can lock yourself out in any number of ways.

Had I been in Austin I certainly would have. Had I noticed it in the beta I would have said something then. I don't have a problem with the feature existing. I just feel its placement in QD is "stupid". If you'd be kind enough to draw the esteemed Mr. Nattinger's attention to this thread, I'd be happy to take it up with him mano a mano.

Am I the only one who thinks this is really stupid? Not because of the shortcuts themselves. They're useful. The problem is with placing them in QD. W. T. F. !. This is the kind of thing that would be ideal in something like the right-click framework - select something, operate on it. Why is it in QD? Obviously the answer is simple - someone wanted it and didn't have anywhere else to put it which would make it easily accessible, but I find this to be totally unrelated to the QD functionality and very undiscoverable.

No matter how good you are at ASCII art, I bet you can't do that in visual studio.

Seems to happen everywhere (at least every forum I tried).

I feel that a better solution for this is the one shown in Darren's nugget here, because it doesn't require you to do anything beforehand and allows "fixing the mistake". One of the posts there also has a link to a 7.0 equivalent, for those who don't have 8.x. I certainly don't feel that the project is for file organization (aside from the files tab, which can help with that), but I can't say I understand your exact request. Why not post an idea to the idea exchange yourself? Those who agree can support it there.

I don't have any real answer for you, but if you add a wait of a couple of seconds between opening the FP and running the VI the error doesn't occur. If you debug the actual error, you can see it's an error 97 in the first property node, which is a null refnum. I'm guessing that you're correct and that there's a race condition somewhere. Basically, I guess the ActiveX object needs enough time to be initialized after being "dropped" before you try to access it. You might be able to add the wait to the XControl's Init command to encapsulate it.

When I try to report a post to a moderator I get a page with the following error: This seems to happen with every post. Admin edit: this post was reported successfully by Gary Rubin with the following text: "testing..."

The files you download ARE the VIP files. Some browsers recognize them (correctly) as ZIP files and saves them using that extension.

Or are you? Great, starting with -6000 points is all I need. To be honest, I have to admit I don't notice the LAVA voting buttons. Unlike the NI ones, they're not "in your face" and so I don't use them. Even if I would, I'm the type to only vote on posts which are either out of the ordinary, show real commitment or have real value for me personally.

Well, I was thinking of a "Create value change events for these controls", with some nice touches, but I ran into not having any of the event stuff exposed as soon as I started writing some experimental code.

You can't. The LabVIEW compiler generates executable machine code from the diagram. The LabVIEW run-time engine (which is what runs the code in the EXE) does not support any of the properties or methods related to the diagram or the compiling process and can only run the machine code in the VIs. Each property and method has a table in the help file which says if it's supported in the RTE. If you want to generate and edit VIs dynamically in an executable you will have to open a VI server to LabVIEW and ask it to do all the operations.

That wouldn't help you because the reference you get is for a diagram, which wouldn't have the specific info you need from the event structure. It looks like nothing at all about the event structure is exposed in the scripting API - there's no way to get the event structure data, there's no method for registering events, etc. Even the Register for Events doesn't appear in the New VI Object list. I'm assuming that means NI will need to do some work to expose it.

I mentioned several potential improvements, so it's hard to say which one you're refering to, but here it is: Caption.Align.Left Label.Visible. Label.Change to easy to read font. Again, part of the issue is that with a parser, once you wrote the "change to easy to read font" VI, you can call it on any piece of text. The framework will need to be responsible for getting to the text part of the object. Why? If you know it's a parameter, just pass it as one into the align VI, which will attempt to cast it into one of its allowed parameters. For example: The first part is correct, although in this specific case, label is of the Text class which does inherit from GObject. You're definitely correct that finding the right type might be tricky. As I said, it won't necessarily be simple, but I think it's required in order to make it really useful (as opposed to the very useful it is now).

I was thinking "it's good you finished the long post before the next version of LV came out". That said, the theoretical improvement LV may or may not get would not be as all purpose as Inkscape or GIMP.

Funny. I could have sworn I said "search".

I have to say that I like the idea ever since I first saw Norm's demo of it last year, but I haven't used it all due to not wanting to install the speech recog utility or speaking all the time in the office. Another thing which I think is a major hinderance is the list of options. I think that what QE needs to really take off is a smart parser. This is certainly a tricky bit, but also important, due to the following improvements it could allow: Writing less code for the framework. To demonstrate this, think of the command "Label visible". Today, it has its own specific VI. In the ideal version, the parser would recognize the structure, use the word "label" to get a reference to the label of the object you selected and then pass that reference into the "visible" VI (which was only implemented once, for the GObject class). That would mean that you only have to write the code for each action once. Now that you've written it, "visible" would work all objects, their labels, their captions, etc. The parser could allow parameters. For example, "caption align left" would obtain the reference to the caption, then call the "align" action and pass "left" as a parameter. Immediately you have only one action instead of several. Synonyms - imagine if you could say "label visible" or "visible label" or "show label" or "label show", etc. That would make it a lot more "natural", although I admit it's a secondary objective. As I said, writing such a parser would be tricky. It's possible that maybe an initial version could use some explicit vocal separators to break the different parts of the text.

Or to customize a color box to look like a LED. You should be able to find an example if you search the NI forums for "color LED".

Non-premium members can only edit their posts for a limited amount of time.

You might find the NI legal team hunting you down if you do that. You should add virtual folders to the class to organize it. Also, you can drag the top level VI to be the first one. You're right.

There's a VI here for rotating a picture, but I don't know how good the text will look if you don't render it directly. You might wish to use a bold font.

How about something like this? Too much noise?