Yair

QUOTE (shoneill @ Mar 20 2009, 12:59 AM) It's called a http://en.wikipedia.org/wiki/Virtual_table' rel='nofollow' target="_blank">vtable and if memory serves Stephen did refer to LabVIEW using this method, although a quick search didn't reveal anything.

You're right, I was a bit too explicit. I guess I was overcompensating. The basic point I wanted to make was that almost all the problems inherent to globals (memory allocations and mainly race conditions) are not solved if you use simple get/set FGVs and are sometimes made worse. Some people are probably not aware enough of this distinction because all they keep hearing is "globals are EVIL!!!! :!: " and "you need to use FGVs instead".

QUOTE (crossrulz @ Mar 19 2009, 03:56 PM) They are better to use, but only if they are functional. If they just have read/write options (or get/set or whatever) for a single value, then they're no better than globals and in many ways they're worse. The power of functional globals comes when you place actual code inside them. If you're not doing that (and even if you are), you might wish to consider other alternatives like GOOP or LVOOP (probably using single element queues to transport the object if you want to have globally available data).

QUOTE (ASTDan @ Mar 18 2009, 11:32 PM) I'm surprised no one really said this explicitly (although Ben has alluded to it), but the project does NOT have to mirror the disk layout, and there are some advantages to it not doing so. Specifically, You can place only the stuff you want to access frequently in the virtual folders and thus ignore all the boring subVIs. Also, you can have links to documents, etc.

As Paul Mark said, using something like a queued state machine, but since you don't have that, I think you chose the correct solution based on your description. I'm one of those who feel that a global with a single writer is often perfectly legitimate. One point, though, is to consider whether you want a global. Currently, you have a single writer. In the future, you may have more (e.g. maybe you have an E-stop button). One simple way of working around this is creating a simple functional global with two inputs - Stop and Reset (both default to F) and one output (Stop?). When stop is T, you raise the stop flag. On first call or if Reset is T, you reset the stop flag. You can then stop the code from several locations. Edit - I started posting before seeing the other replies.

QUOTE (Aristos Queue @ Mar 17 2009, 09:38 PM) Jeffrey said he didn't get the out of memory error when using the unflatten primitive. Assuming he tried it on the same file (did you, Jeffrey?) shouldn't the binary file primitives do the same?

QUOTE (neBulus @ Mar 17 2009, 08:31 PM) Go one version back - http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=352101' target="_blank">This was reported on Aug 28, CARed on Sep 2 and fixed on Sep 19. That's 22 days.

QUOTE (Mark Yedinak @ Mar 17 2009, 09:04 PM) 8.5 and 8.5.1 were binary-compatible. This meant that you didn't have to recompile your VIs when upgrading (e.g. to mass-compile vi.lib), but it also meant that if you have code which has an 8.5 bug which was fixed in 8.5.1, you would have to recompile the VI explicitly for the correct machine code to be generated.

I assume that if you try it by using the method NI shows in its examples (using the datalog functions) it will work, but it might not. Personally, I flatten to a string and then save that string. You can try doing the same and seeing if the unflatten node throws the out of memory error. In general, though, I would agree that this is probably a bug and that LV should recognize you simply did not point it at a class file.

QUOTE (Neville D @ Mar 16 2009, 08:12 PM) That's what NI has sales people for, although admittedly there would be a need to understand the implications of the environment and of choosing the equipment you choose. Luckily, I don't have to do that, as we have other people who do understand electronics and who can sort these things out with NI or the other hardware vendors. In my specific case, the skills required to do my job well are the ability to understand a variety of systems, the ability to understand the client's needs and offer an appropriate (or better, preferably) solution and the ability to implement the solution. The projects we do are often very different from each other, but LabVIEW's ease of use and various modules allow us to implement solutions we wouldn't dream of doing otherwise (e.g. image analysis, parallel execution systems). I think that this shows the difference, although I probably am the minority, as John suspects. While the stuff we do is not "pure" software in the sense that we almost always have some hardware interaction, we don't usually have to really deal with the electronics ourselves.

I believe the block diagram property is set up so that you can't use from outside the current instance, which is why you're getting the access denied error. You can check this by opening the context help window and hovering over the property. This means that you CAN'T do what you want. Instead, you may need to do what Ton suggested, which is to open a reference to a VI which will run in LabVIEW and that VI will be the one which runs the scripting code.

QUOTE (Norm Kirchner @ Mar 16 2009, 12:09 AM) Great, now Stephen will probably spend the entire day writing these instead of doing work which would actually benefit LabVIEW users.

Your example has no code and the border wraps each node individually. What I'm essentially getting at is this - Either the code you're scoping has internal dataflow dependencies and then it can have an external dataflow connection easily added, even today (e.g. by using the OpenG tick count wrapper), or it doesn't have internal dataflow, in which case you would need to force it or wrap all the code in a single structure to make it clearer that you're profiling all of it together. I simply fail to see the big advantage in having a "special" wire and I do see potential for problems. P.S. I'm not even sure that making sequences smaller is even a good idea. Narrow borders are great, but we need to be able to easily tell the different structures apart. I think we would have to see an example of a thinner sequence to know whether it's worth it or not.

QUOTE (crelf @ Mar 15 2009, 03:56 AM) Not exactly, since people seem to want to avoid "artificial" data flow and you would usually want to scope a block of code. Here's a challenge - create a sample graphic which has several nodes and shows how this is easier and more readble. QUOTE Yuk! That'd be unintuative Probably. I didn't say it was a good solution.

QUOTE (RAJKU @ Mar 15 2009, 08:02 AM) No idea. I only used them once or twice and that was a while ago, but I would guess they either specifically include parts of the LabVIEW compiler needed to do this or that they call into the IDE using VI server as suggested by jgcode or using another trick. To do this, you need to specify that VI server allows external connections on a specific port (preferably not the default 3363, as that might conflict with your EXE) and then open a reference using "localhost" as the machine name and the selected port. I have no idea if this will work, but it probably will.

Additionally, this won't work even if you use a VI which does have a block diagram, as the run-time engine doesn't support most (if not all) of the scripting properties and methods at all.

You can also combine the FG and references method to have more readable and safer code by doing something like this. You can update the controls using the Value property. Alternatively, if you're using 8.6, you can try using tags to mark the "owner" and "position" of each boolean and iterate over their references. There should be tagging VIs in vi.lib somewhere (I think in the Utility folder), although you probably want to check that they work fast enough and that they work in an EXE as you would expect before using them extensively.

QUOTE (jzoller @ Mar 13 2009, 11:18 PM) Did you know that you can drag controls into a reference (control ref, queue ref, notifier ref, etc.) to make a reference of the control's type?

QUOTE (crelf @ Mar 12 2009, 10:48 PM) I think this is a terrible idea and would create a huge potential for wiring bugs for people who won't notice the border or know what it is. I'm guessing that you just want the users of the NI forums to have more threads they'll need to respond to. Additionally, I fail to see how this scopes the tested code. You would essentially have to wire to every data flow "start" and "end" points within the tested piece of code. It seems to me that scoping using a sequence or an an explicit error wire coming out of the timer is much clearer. Hmm, maybe this would work if you could expand that border around more than one node? I wonder, what does that sound like? If you guys don't like the sequence structure because of its size, all you need to do is use the diagram disable structure which has a much thinner border and which I believe can have a single frame.

I don't know if this would work, but you could try NI's online evaluation. It requires installing some ActiveX component, but I don't think it needs a separate EXE. I never used it myself, but here are some potential problems - would you be able to get the files onto it? Would it allow you to run it multiple times? Is it a recent version? Will it be fast enough? P.S. It's nice to hear that LAVA is on the list of approved government sites. :laugh: P.P.S Thumb drives can be a huge security risk.

Michael probably used LV 7.x. Others have some methods for this. Look through the threads.

Scripting has been put behind the license engine in 8.x and NI does not sell licenses. The floated threads in this forum probably refer to this.

You should send this to NI's product suggest center if you want them to see this. I know that they are aware that people don't like that dialog box, but I have no idea if they're doing anything about it.

QUOTE (neBulus @ Mar 5 2009, 07:29 PM) Which kind of swearing is this? :!: The answer to both your questions is no. If you used a Yud it would "Yefferson" and the double F is simply replaced with a Pe. The J is accomplished by having a Gimel with an apostrophe. It looks like this (hopefully this is Unicode): ג'פרסון P.S. The use of J as a replacement for Yud is only from Hebrew to the languages using the Latin letters, never the other way around. Interestingly, some languages pronounce J differently (e.g. Juan in Spanish, and I believe the Dutch also do this sometimes), so people might have three or four different ways of pronouncing the same word (e.g the name Xavier is also sometimes written as Javier and I wouldn't be surprised if some people pronounce it with a J).

I'm not sure if you can have VIs in inherited classes which have the same name and are not override VIs. Try reading this. That said, I'm far from an expert on LVOOP. This smells like a bug from your description.