Aristos Queue

Here.

It goes 7 to 0 then 0 to 7. How to offset the sequence so that it goes from 0 to 7 and then from 7 to 0 is left as an exercise to the reader.

It is saved in LV8.0.

I tried for a few hours to come up with something... didn't do so good.

First thought: Let's use Mouse Up and Mouse Down to ignore the Value Changed event. So when we get Mouse Down, we'll set a boolean that says "ah, we've started gathering data." Then, on a Mouse Up, if the boolean was set, we should actually acknowledge a Value Changed event. That doesn't work because you don't get a Mouse Up event if the user releases the mouse while not over the control, even though the value keeps changing while the user holds down the mouse button, even when not over the control.

So, I thought I'd get all clever and do this: on Mouse Enter, enable the knob. On Mouse Leave, disable the knob. Silly me, I thought this might stop us from changing the value of the control once the user left the region of the knob. I could thus register a Value Changed on Mouse Leave and on Mouse Up. Nope. Value happily keeps changing if you programmatically disable the knob while the mouse button is already down.

Ok. So then I used Mouse Enter and Mouse Leave to control the value... On a Mouse Leave, I'd set a boolean to false. While that boolean is false, if there were any Value Changed events, I'd just set the value right back to the old value. That worked, except for the horrible redraw problem -- lots of flickering from old value to new value.

So I tried creating a second knob stacked exactly on top of the first knob. That second knob would be hidden any time the mouse was not over the knob pair. On Mouse Leave, I woudl show the second knob, with its value set to whatever the value of the first knob was at the moment the mouse left. That was great at getting rid of the flicker -- but there was still the damn value tip strip. There's no way to hide, supress or disable that tipstrip. ARGH.

Anyway, my final VI is attached to this post. Anyone want to try carrying this further?

By the way... what we really need it seems is something akin to what is on a String control. A string has the option of "Update value while typing." Normally this is turned off, but you can turn it on if you really want a Value Changed on each keystroke. It seems like we'd like on knobs/sliders to have "Update value while dragging" --- and have it also default to off. (Though it would have to default to On for existing contols to provide the same behavior in existing programs).

QUOTE(pockey @ Mar 22 2007, 03:50 AM)

.\manager\ThEvent.cpp(116) : DWarn: DestroyPlatformEvent failed

Looks like something tried to shutdown as part of LV exiting last time, and LV didn't uninitialize correctly.

I wouldn't worry about it unless it becomes common.

I'll report the problem about the read-only directory. We ought to handle that better.

QUOTE(Darren @ Mar 22 2007, 05:00 PM)

Hey now, the fact that I work at NI has absolutely nothing to do with the fact that I'm totally pwning all of you in the LAVA arcade...

True. But the fact that you're totally pwning the arcade has a great deal to do with the fact that you work at NI. It's a little known fact that all our candidates for hire must be able to demonstrate competency on at least one game in the LAVA arcade.

Having said that, yes, I do wish some of the metrics about "time spent playing" were less available.

QUOTE(pockey @ Mar 22 2007, 02:39 AM)

Can you tell me why the path "C:\Documents and Settings\Workstation 2\My Documents\LabVIEW Data\lvfailurelog" doesn't work?

My only guess would be that maybe you don't have permission to write to that directory. Is it read only or something? Other than that, I have no idea.

Having said that... check if the log file actually got written out (in spite of what the error message says). If so, go ahead and post the log file here. Maybe we can puzzle out what happened.

QUOTE(Neville D @ Mar 19 2007, 02:37 PM)

Couldn't you just use the Pt. By Pt. function : Mean Pt by Pt.vi ?

(under Signal Processing>Pt by Pt> Probability & Statistics>Mean).

I didn't know about this VI -- I tend to be familiar with the language and not so much the libraries of VIs written in the language. But I opened it up... seems that, yes, the functionality is the same as that requested, but it's a pretty inefficient implementation. I played hide-the-dots with that VI for a while (if you're unfamiliar with that game, it's where you use Tools>>Profile>>Show Buffer Allocations to optimize LV code -- called hide the dots because you try to get down to as few dots on the terminals as possible) and I found a lot of places that could be improved.

If he's looking for speed, I think that the VI I posted will be substantially better. The Mean Pt by Pt.vi has more functionality than mine, but for what rkesmodel is attempting, I don't think he needs any further functionality.

This is kind of a dumb post, but I need a rules clarification from those who have higher scores than I on the game Plumber 2

( http://forums.lavag.org/arcade.html&code=play&g=62 )

At level 14, there are multiple destination pipes. It appears to me that one of these pipes is a real destination, and the other is a fake and if you route the water to the wrong pipe, you lose the game. Is there any way to distinguish the real destination from the false destination? Is it random which is the real one, or is it always the same one and you just have to learn which is the real destination at each level and remember the next time you play?

QUOTE(rkesmodel @ Mar 17 2007, 01:11 PM)

Better/faster method? All opinions appreciated.

You'll get less data movement if, instead of using Rotate 1D Array, you track which element needs to be replaced on each call. Start the value at zero, increment on each call, and reset to zero if it equals the size of your array. That way all that you do is substitute the value of the array instead of moving all the elements of the array. Attached is example VI (saved in LV8.0).

I moved my mouse to the other hand when I'm at home. It took a bit to get used to, but now I can hand the mouse off easily from one hand to the other. This avoids too much stress on one wrist and lets me rest one side when it gets tired.

QUOTE(leblanc @ Mar 14 2007, 03:58 PM)

well if labview supports oop you should be able to inherit the built in xml writer and override the render event which takes a string builder.. talking more of how its done in .net

Merely because LV has OO capacities does not mean that 20 years of libraries have been rewritten along OO principles.

QUOTE(Aitor Solar @ Mar 14 2007, 07:37 AM)

Imagine that, after all that hard work, NI decides to add that capablity to LV's native for loops. It would be crazy!

You're absolutely right. It wuold be crazy. So make sure to tell me if anyone does it. Then I'll make sure we never do something like for-loop-with-break.

QUOTE(jaegen @ Mar 13 2007, 10:38 AM)

Thanks Michael, that's exactly what I ended up doing. The only reason I brought this up was that it seems inconsistent to me to allow modification of the text colour at development time (via the font drop-down), but not programmatically.

It could be that the bg color is all the OS allows us to change. That would almost make sense -- I know that with the selected text, when you set the bg color in the system table, then the selected text color is calculated from the background to always be a visible color. I don't know about the unselected fg text, but it seems reasonable that it would be a calculated value as well.

QUOTE(Michael_Aivaliotis @ Mar 12 2007, 05:57 PM)

Are you saying we shouldn't be allowed to have classes with pure white appearance of wire?

Well, that's one option. Or I could just say, "Silly user, don't do that." But I think the best solution would be if I go change the default background for all VIs to diagonal multi-color stripes so that no matter what wire color/pattern you choose you can always see it against the background. Don't you think?

QUOTE(orko @ Mar 11 2007, 10:53 PM)

Although I heard a little rumor that it *may* be considered as an Advanced II topic...

REALLY?? (watch me jumping up and down excited)

Where did you hear this? Who do I need to encourage?

QUOTE(orko @ Mar 11 2007, 04:12 PM)

Brain spasms resulting from clauses like this are one of the reasons why I try my hardest to stay away from the LVGOOP forum...

Oh, I hope not. This is the absurd part of LVOOP, not necessarily the useful part of it. Weirdness like this exists in many corners of LV or any formal system. The "tongue twisters" I've presented here result from the worst possible presentation of a concept, rather than a clear explanation of of the concept. Just having a bit of fun, not trying to scare anyone off.

QUOTE(yen @ Mar 11 2007, 01:12 PM)

Not to get nitpicky, but shouldn't that be the other way around (each data type has a default value [e.g. numeric is 0] and each control has a default value [which is 0 by default for numerics])?

Or is this just a matter of semantics?

I suppose I should phrase it as "Each control has a default value. For each data type, there is a default default value for controls of that type."

QUOTE(PaulG. @ Mar 8 2007, 06:38 PM)

"bowchickabowbow"

Can LV go that far????!!!

I must be a PG-13 LV kinda guy. I'm still just wading ankle-deep in the R-rated world of variants.

I would've expected all of LV to be rated G. ;-)

QUOTE(crelf @ Mar 9 2007, 08:17 AM)

If you have only one input and their datatypes are the same class, you can, however, create an icon that looks like a wire

Hm... you just made me think of something sneaky... see attached VI (saved in LV8.2).

Open the top level VI of the attached LLB. The VI has a numeric control on the FP and a numeric indicator on the FP. Run the VI and the value of the control will be doubled and put into the indicator. But the block diagram has no visible wires connecting the two FP terminals and, indeed, nothing but those two FP terminals and a free label that says "Look ma! No wires!"

EDIT: Even better... look at the VI Hierarchy window and note that there are no subVIs shown.

Yes, I am going to file a CAR about this...

QUOTE(yen @ Mar 10 2007, 05:51 PM)

QUOTE(Aristos Queue @ Mar 10 2007, 05:22 PM)

This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch.

Just be glad that we decided to call it "dynamic dispatching." In Java and C++, this behavior is called "virtual," which would have given us "virtual virtual instruments."

In LV, each control has a default value.

Each data type has a default default value.

Which means that a LabVIEW class -- which is a data type whose default value is defined by the default value of a set of controls -- has a default default default value.

Let's suggest that someday we add the ability of a LabVIEW class to set its default value by running a VI at load time -- a feature requested by more than one user. Child classes would be able to override and extend the parent class' default value. You might initialize that value using a CBR to a run-time chosen subVI. That would give us "dynamic dynamic default default" values.

Then, if we add templates to the whole structure, we might end up with a dynamic dynamic dynamic dispatch VI which overrides the default default default default value of the class.

N layers of indirection is never enough. And now you understand why good tech writers are so valuable.

QUOTE(yen @ Mar 10 2007, 05:48 PM)

I don't remember who it was, but one blogger gave the example of being able to run a program they wrote in 1983 or so on XP or Vista simply by running the executable.

The bits of old programs themselves work and call OS APIs that exist. That doesn't mean that the application conforms to the installer security requirements, standard directory names, and the UI standards of the new OS.

QUOTE(zen @ Mar 10 2007, 05:04 PM)

After thinking on Tomi's questions, rereading his critial analysis report and playing with LabVIEW, I do not think my approach is the best way. Although my original question was how TestCase class's Run.vi to aquires list of method VI references bound in a child method, it seems I should find another way to implment this mechanism (or wait for NI implementing object reference ;p )

Here's where I think you want to go:

a) Remember that .lvclass files have all the functionality of .lvlib files -- classes are just libraries dedicated to the purpose of defining a data type. Given a path to your class, use the VI Server interface to get a list of all the VIs that are members of the class. This will only work inside the LV editor environment (and not the runtime engine), but that's ok for your purposes. Now you can call each of those methods... but...

b) ... a VI with a dynamic dispatch connector pane cannot be passed currently to a Call By Reference method. The wire will break. This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch. To dynamic invoke these methods today, create a non-dyanmic (static) VI that calls the dynamic VI on its block diagram. Then invoke the static VI in the Call By Reference node.

c) You can execute dynamic dispatch VIs directly using the VI's Run method. This might be a better choice for you in general since running the Run method would allow you to invoke VIs even if the conpanes are different.

QUOTE(Tomi Maila @ Mar 10 2007, 05:07 PM)

As far as I know XP software run unmodified in Vista with the exception of device drivers.

Untrue. The necessary modifications to make LV run in Vista -- just the LV editor environment -- is a list several tens of pages long. Many applications are having to make significant changes to comply with new security regulations and installer behaviors.

QUOTE(Mike Ashe @ Mar 9 2007, 01:50 PM)

Several nice goodies here, especially and ,

and I really can't wait to test

:beer:

You see... I knew you'd find http://forums.lavag.org/index.php?s=&showtopic=4225&view=findpost&p=25584' target="_blank">those music note icons useful soon enough. :ninja:

I've seen this kind of bug in development builds of LV when the inplaceness is improperly calculated and some function ends up writing on top of the constant string instead of making a copy for itself. Never seen it in a release build -- those sorts of errors usually show up pretty fast -- but it is possible. Post your VI and let's see what you've found...

QUOTE(Irene_he @ Mar 7 2007, 11:09 AM)

How much bad is using reinitialize to default node?

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

My opinion.