Michael Aivaliotis

I wouldn't cry for too long. I know scripting is still there. NI just changed the ini keys, that's all. I don't recall what they are but I'm sure someone here can give us a hand...

For some reason I never had a need for this before. I usually perform some calculations to decide where to draw next. It would be nice if I could figure out the current location of the pen in a picture control. I hope some of you gurus out there have this already or even better... is it available in LV?

Since the release is now official. Go over to NI's site, gather your ammunition and start discussing your opinions on LabVIEW 8 in our new dedicated LabVIEW 8 forum. I'm sure all of us have opinions on the matter. So let's hear them. Yes, that means all you former beta testers too...

Well the performance penalty is relative. If you work with a team of developers and others have to dubug and work on your blockade of wires then it suddenly becomes an issue. They throw it back in your face and ask you to redo it. So ya, your performance goes down. Can you explain what an "off-normal" condition is? I still don't follow your argument. Using the mechanical action "latch when released" covers this. I have not (since the event structure came out) seen any condition where I would have to "make sure" the button was going down. I may be missing something here, so please enlighten me. I disagree with any code on a diagram that is superfluous. It just causes the programmer to pause and have to think about what is going on. Slows comprehension of the code. Makes me think, "ok, so why is this like this?"

Nice little trick. Doesn't use scripting but is still a big time saver. Thanks :thumbup:

Ok, this one is more a personal preference but others might find it usefull. As I get older :thumbdown: I find I need more of these aids to keep my programming speed up to the same level as you young'ins. Change your Windows settings as shown in the first image. You will see a noticable difference in the grab handle colours (they turn red). Helps in other areas as well.

Nice tool! Some nitpicks on style though. Have you considered the use of bundling all the shift register elements into one cluster and only requiring a single wire to cross through your cases? Those wires take up a lot of real estate and it can be messy to debug. Another thing. Why do you take the buttons and feed the value into a case structure inside the event frame? This is unnecessary coding. Obviously the button value is true otherwise you wouldn't be in that event case. If you are worried about button staying down then set the mechanical action to "switch when released" Which they should all be set to anyway. I'm not following the purpose of the cases in every event frame.

Trying to find someone that has the following already: Take an array of strings and generate a "string type" case structure that has a case for every element in the array.

I'll list the winner and probably the next several runner ups. You can submit as many as you want until the deadline and I'll pick the best.

Of course, no problem.

Looks like Brian's been busy. It's great to see LabVIEW VI Scripting used in a real product. I guess LAVA Members should be getting their complimentary unlocked, password free, unlimited use version soon? Class Browser for LabVIEW

This is alright. The picture functions you mention are fine.

try this.

Your definition of a block as related to the array information does not jive. In any case, regardless, what you probably want is to use the array subset function. You can feed in the start index and length of the the elements you want. This should handle what you want.

Yes, you are correct. I've been throught this exact dilemma before. There is no object (decoration) that mimics the WinXP themes stuff. This is a real wish, to tie-in somehow to the winXP skinning.

I agree with PJM, attach an example please.

I don't see this posted, if it is, oh well. Make your coercion dots stand out by making them bright red:

More annoying singing people... I don't know what this is but.. I gotta get me some of that!

I say let them have it! People who've been programming in a bubble all their lives need to be shaken up. I'm sorry, how else are we to improve the overall quality of the stuff we have to dig through on a daily basis. Let's say it like it is. It's crappy code. I sometimes see it here on the forums too, people parlaying "advanced" read: obfuscated, programming techniques. My answer to customer's requests for feature additions to existing badly written code: No problem, anything can be done (it really can). It will only cost you x dollars. If they disagree, all the better, I need my weekends for personal time, not for digging through some interns "learning" project. I just hope if you are the programmer who ends up doing the fix that you are honest with the customer about the amount of work required. Let's not whore ourselves out to the lowest bidder. Bottom line, as long as I have breath in me I will educate and preach proper programming standards, regardless of the audience response. Hopefully, if enough of us blow in the right direction, we can start a wind of change in the world of badly written LabVIEW code.

So, the moral of the story is... Provide a test harness to test all VI's before release. A much simpler preventative measure would be to position the inputs and outputs at the same alignment. This way you don't have to think too much about wiring mistakes. Having them swapped like that is asking for problems. Another thing in this example is the coercion dots. Correct connection removes coercion. The coercion in this case would raise a flag to the programmer. This is why I change the colour of my coercion dots to bright red instead of the dull grey.

Well, why put the burden of figuring out which panel is active on the operator? It's the developer's job to make this obvious right? One solution is to hide the panel that does not have the focus. Programming this is easy but the problem is that the operator will be confused when different panels become visible or invisible. The reason behind this behavior is not immeadiatly apparent to them. Another solution is to leave everything as it is and just flash the titlebar of the VI which has the focus. This can be done using the windows API utilities that are available on NI's site and other places (i wish I had the link handy). I believe this will even flash the bar if it is minimized.

Convert your flat sequence architecture to a state machine. See the FAQ for more information: What is a state machine?

Still waiting for your summary...

This does not seem to be a problem in the "classic" version of the table. I assume you are using the default 3D one. This is probably a bug but there is a workaround that "unlocks" the colour picking on the background. See the attached AVI that shows the solution. Download File:post-2-1126592671.zip As you can see, the background colour selection "unlocks" once you hover over the first (far left) user defined colour.