Yair

Keep the scope of the problem small enough to allow someone to work on it "during lunch"

I worked on this last challenge over a long period of time, with each session being anywhere between a few minutes to around an hour and I had a lot of periods when I couldn't get around to it. As a result, remembering everything I wanted to do wasn't always particularly easy.

A smaller scope, like not building an application to demo the API, would have made it easier (although less interesting).

I also like the idea about seeing how small you can make a certain bit of code.

They only cost 380,000 each!

That's in Yens - I can help you with that if you want. :2cents: :2cents: :2cents: :2cents: :2cents: :2cents: :2cents: :2cents:

4) Push yourself "in public" and be prepared to be corrected.

5) Make a list of the technically top five LV posters and read everything they ever wrote.

So, let's combine 4 and 5 and see what comes out. Ben, which five would you recommend?

And another one for Python fans:

This isn't an argument.

Yes, it is.

No, it isn't, it's just contradiction.

No, it isn't.

Yes, it is.

Congratulation, Zen (hey, nice name ) and thank you to the committee. I rather enjoyed that one.

A note to the committee, though. LAVA currently has over 5000 members listed. Even if we decide that over 90% of those members are inactive, I'm sure there are ways to get more than 26 people to vote (with several being the committee members and the submitters). I'm sure that some of this is because people did not have an LV version which was up to date enough, but I have a feeling that this is more because the challenge and the voting process were not published enough\appropriately.

A couple of suggestions for potential changes - decide on a maximum version (or backsave code if possible), allow people to vote even without seeing all the submissions (?) and PM all the members of LAVA once to let them know of the challenge and of the voting.

There are several Modbus drivers for LV on the internet, including on NI's site. You can try searching their forums for it.

If you have an OPC server, you can connect to it from LV using Datasocket.

Really? I can't create, edit and save an external VI from a process in an exe?

There are various kinds of options which are not supported in the RTE (methods and properties have a table in their help page which also says whether they're available in the RTE). At the very least, the RTE can not recompile a VI and can not call the Save Instrument method. Supporting those would make the RTE bigger and would make LV "less necessary". Since there is no need for them in the RTE, it probably can't access all the diagram properties, etc., but I didn't check that.

One option which would have been cool if the RTE could save VIs is using VI tags to save the configuration data (you can basically save a series of named variants inside a VI by using the tag methods. See Dataact's site for an example). Unfortunately, that can not be done in the RTE.

Sarah Mclachlan... :thumbup: Great voice...

And, happily, not all her songs are sad. Think of the hugely popular remix of "Silence" made by Delirium (although the lyrics to that one are somewhat sad) or of "Possesion" (my personal favorite) which is not really sad and which I find an incredible song.

As I mentioned, it is a scripting (meaning private) method. Before LV 8, it was simply a matter of adding an ini file setting. In 8, it's more complicated. See the scripting board for more details.

If you're afraid of using unsupported methods, you can try looking for the full version of Rolf's library linked to in my post. It should probably also have VIs which use GetClipboardData.

You can check out this thread and the link at the end. I'm also pretty sure I saw a VI for doing this through the registry somewhere.

This is pretty much an echo of my own though...

You should be able to associate the extension with your application through Windows Explorer (right click the file and select Open and then select your executable). I haven't done any detecting of the opened file like this, but this might help you.

Each of my projects has its own labview.ini file. I've created different file extensions for each LabVIEW version (.lv7ini, .lv71ini,...) so that when I double click on the ini file the right version of LabVIEW is opened for the project. The action associated with the ini file is <labview version dir>\labview.exe -pref "%l"

since I don't :beer:

duty-drivers are always welcome (and sometimes they come back from the parties with the most amazing blackmail photos...)

GetClipboardData can be called from LV. Have a look at the VI attached here.

Correction - that VI copies images to the clipboard. If you want to get an image, there is an Application class scripting method called Get Clipboard Image (see attached).

Download File:post-1431-1160501184.vi

This topic is definitly one of those things that belongs as an article in the knowlege base under FAQ's...

Abstraction : You are not an animal, you are a human. Even tough you sometimes feel the envy to grunt...

I think this should be inheritance, not abstraction. Are you sure you weren't initialized using a constructor from the wrong class?

There are all kinds of LV books around (try Amazon). For some specific ones, you can try "A software engineering approach to LV" (old and hard to find), "essential GUI techniques", and "LabVIEW for everyone, third edition".

You can find A LOT of stuff in the NI site and in the Info LabVIEW mailing list. NI's site has a lot of articles and videos and the trick is to know how to find them.

Yes that's what I meant as well. Immediate actions on the referenced object. Why retrieve and store it in the first place ? That was only necesary for GOOP, but not for NI ! The GOOP-ers could not access the stuff under the bonnet of LabVIEW, but NI can.

The differences between the currently implemented static objects and referenced objects are very small. The diagram of a method would look the same. A big plus would be that there would be no object-set and object-get methods, or wrappers required. That's all just extra code that we need to carry around every time, which conflicts with a reason to go for OO: preventing code duplication.

If I understand Joris correctly, then I would reiterate his point in different wording - you define properties for a class and then, instead of needing the GMS pass, you simply wire it into a property node and select the property that you want, just as you would do for any object in the VI server hierarchy. NI should definitely be able to do this.

As an addition to this, if I remember correctly, Xcontrols do allow you to create user accessible properties. Has anyone considered using Xcontrols to do GOOP?

I only came up with this now, but here's what I thought - the control only serves as a means for holding the properties, you place the control in a VIT and create an instance for each object (since I don't think you can have Xcontrols in an array or, if you could, they would probably have identical properties).

Then, you use the reference (which should hopefully be strictly typed) to wire into a property node. I wonder if this can be done and how it would perform (I don't have 8.0 either)?

Maybe I should try this on my 8.2 eval at some point, just to see if it can be done.

The only way I would think that would be possible is if you HAVE wired a timeout into one of the Dequeues. Maybe it's hidden under the function? Maybe you wired 1 instead of -1 or created a 0 constant and didn't change the value?

If that's not the case, then this definitely sounds like a bug.

I only started using Ctrl-W recently, and I would probably adopt that method, but for some reason, Ctrl-W doesn't always work for me. I couldn't figure out why, since Ctrl-E seems to always work fine. I suppose it could be the W key, but I don't seem to have any problems with it.

Sorry, as a Stargate fan, the only Thor's Hammer I recognize is this one.

Welcome to LAVA. :beer:

Do you have any particular specialties or interests in which you can contribute uniquely?

Also, what does your avatar stand for? Is that a viking symbol?

But i am now convinced to stay with the autotool...

Why don't you use an enum for the selection so that your code is auto-documented, as the enum string will end up in the selector case?

This only changes the properties of this particular instance...

I definitely do NOT like USR since this limits this style of globals to shift register based patterns:

...And what about queue based patterns??

Or even a local which can also retain its value between runs?

OK, OK. Stop throwing those tomatoes! I know that locals are evil, memory-gobbling, cause-of-all-the-world's-troubles devices. Just bringing up the point, because there are cases where they're an interesting method for this.

There was a movie about 30-40 minutes long called "the way things go" or something similar which was a collection of pretty long Goldberg machines. Some were cool, some were just boring after a while. Then, of course, there were all the "Incredible Machine" games and their derivatives...

And the Cog ad has been a favorite for some time. They apparently did about 600 takes to get that one right...

There was also an X-files episode which featured several, but it wasn't incredible.