Michael Aivaliotis

QUOTE(Justin Goeres @ Jul 26 2007, 08:58 AM)

Nonetheless, this is a fairly decent likeness of me (after I added appropriate clothes):

http://forums.lavag.org/index.php?act=attach&type=post&id=6462''>http://forums.lavag.org/index.php?act=attach&type=post&id=6462'>http://forums.lavag.org/index.php?act=attach&type=post&id=6462

Damn, that looks just like you! It's uncanny.

QUOTE(MikaelH @ Jul 26 2007, 06:04 PM)

Of course you can get that information...

But it's a bit messy ;-)

I guess I could check but a bit lazy right now. Does this info get updated real-time with every window adjustment or only when LV shuts down?

QUOTE(dcooper @ Jul 24 2007, 08:44 AM)

Please add some sort of resizing option like the anchor property in .NET so I can specify how each front panel object is to be resized when the front panel resizes.

The current options such as "Scale object with pane" just doesn't cut it.

I once shared a room with Norm who is also a LAVA member. I had a blast! If you're going alone, I highly recommend this.

Also, as far as Justin is concerned. He's a personal friend, a blast to be around and an all around fun guy. You won't have any problems. Besides, who stays at the hotel during NIWeek anyway...

Remember to use the secure personal message system here on LAVA for chatting with each other. Don't post phone numbers or email addresses in this thread.

Michael, why did you have to be up against Steve Rogers?

Just another testament to how our civilization is becoming increasingly depraved and effete. This guy put a lot of effort and planning into doing something that, at best, was a useless and utter waste of time. Nice production and cinematography, though; there's probably a bright future for him in Hollywood, home of all things depraved and effete.

On topic to this thread, I'd like to mention a tutorial that I posted here on how to accomplish this.

The RSS feed is pretty quick

I'm surprised you just noticed it. It's been there for a while. The links you mention are by accident and I should remove it from there (i can do that i think...). It's intended for general links in posts as shown below:

http://forums.lavag.org/index.php?act=attach&type=post&id=6386

It only pops up when you hover over the little balloon icon. Hovering over the link does not show it. If you hover over an RSS or a wikipedia link or something like that it actually gives you the text not just the image:

http://forums.lavag.org/index.php?act=attach&type=post&id=6387

Also, because I believe in choice (and i was expecting complaints), you can totally turn it off. Go to the portal and scroll to the bottom left. You will see an option to turn it off. OR, click on the top right of the snap window and select disable.

http://forums.lavag.org/index.php?act=attach&type=post&id=6388

QUOTE(Ben @ Jul 17 2007, 01:08 PM)

My wife likes LabVOOP. Just de-emphesize the the "b" and pronounce like its a French term.

Ah, you mean LAVOOP. I love it. :thumbup:

Too bad it's not going to be released for another year or so.

I would use XP because it will have longer lifespan than 2000. I'm concerned about the LV5.1 aspect. My main concern is the LV drivers. Will the old 5.1 Drivers even install and work on XP? I think 5.1 uses the old serial VI's which don't use VISA.

goop is good!

I don't like labvoop. Sticking a b right next to a v makes it hard to say. Same with lvoop, or is it elvoop? More confusion.

Read this thread:

System button with image

I actually like using subvi's because I can open them in their own window. I can put one on one monitor and another monitor and so on. I like viewing multiple VI windows independently. Also, you lose the modularity with your approach. It's a lot easier to reuse code and debug problems when you use subvi's. Perhaps we can still use subvi's but have a special viewing mode that - when switched on - you can zoom into the subvi diagram and see what's inside instead of opening it. Perhaps this is what you meant. If so, I agree.

Just went through the Microsoft demo. The LabVIEW block diagram is a different beast than the web browser. It seems a bit of a stretch in my opinion. Also, this is designed to shrink screens down, is this what you are asking? Shrink large block diagrams down to size? As far as I can tell this technology is not meant for any desktop application. The concept however is still valid and a very interesting one. Thanks for the link.

Enjoy:

NIWeek 2007 Blog

Now new and improved with included video...

Go with what works. I prefer to do things in native LabVIEW then relying on graphic tricks. It makes the code easier to edit by several developers. Sometimes, however it's easier to use animated GIF's.

I think the reason for not having a variable GIF frame rate is because ideally this should be specified inside the GIF file and playing with that seems counterintuitive. Actually this is defined as an interframe delay. If you create an animated GIF with no interframe delays then LabVIEW pins this to 100ms as a safety factor. You can play with this by setting by placing

MinMNGFrameDelay = xxx

in your ini file, where xxx is the minimum delay in milliseconds. The smallest number this will honor is 10ms.

This is old setting and not sure if LabVIEW 8.x supports it. If it does then we should add it to the [wiki]LabVIEW configuration file[/wiki] page.

One of my favorites is http://community.ni.com/examples/scrolling-led-xcontrol' target="_blank">Aristos Queue's scrolling LED XControl.

I'm doing a presentation this year at NIWeek on XControls. I'm looking for examples of XControls that any of you have developed. If I determine that they are useful, I will present them at NIWeek and obviously give credit to you or your company in my presentation.

You can either attach your XControl to this thread in a zip file or email it privately to me at: michael (at) aivaliotis.com

QUOTE(Aristos Queue @ Jul 10 2007, 06:52 AM)

... such as having both VIs obtain a reference to the same named notifier. The VI that needs to be running uses Send Notification to indicate that it is running. The VI that needs to wait until the other is running does a Wait For Notification and thus doesn't proceed until the notification is received. If it happens that the first VI gets up and running first, that's ok, it just means the message is there and waiting for the second VI so it doesn't have to wait.

Yes, this works well.

One other solution is to use rendezvous. Rendezvous are tailor made for this use case. Now you know where you can use those obscure functions.

Well, I played around a bit and I got it working.

You can now drop data onto the graph, however the drag enter still does not work.

See attached (8.2.1).

QUOTE(jaegen @ Jul 9 2007, 12:02 PM)

Just FYI - there are some real issues with using a graph inside an XControl.

See here ("Data Change" only fires if different data is written to the terminal, not every time any data is written to the terminal)

Jaegen

I don't think this is related. The link you reference affects any control not just graphs.

QUOTE(ptit bras @ Jul 4 2007, 07:59 AM)

I think this is a bug. I tried to simplify the example and I removed the drag enter events on the DD_Main.vi. It still locked up. Also, I tried to simplify even more... I removed drag enter event from the Facade and I only used Drag Drop. I could now see the data name (without lockup) but when I probe the get drag drop data function error out, I see error:

http://forums.lavag.org/index.php?act=attach&type=post&id=6334''>http://forums.lavag.org/index.php?act=attach&type=post&id=6334'>http://forums.lavag.org/index.php?act=attach&type=post&id=6334

I would report this to NI for sure.

QUOTE(jccorreu @ Jul 9 2007, 04:35 PM)

I have not seen anywhere that specifies a subvi needs to be running in order to register for events. Nor have I seen much about what the purpose of having the Run vi invoke node wait until done.

I don't have an explanation for trying to register events on an idle VI, however I think I read somewhere that the VI should be running or reserved for running in order to register for front panel events.

Your assumption about "wait until done" is false. It has no affect on your problem. The issue is a http://wiki.lavag.org/Race_condition' target="_blank">race condition. You are performing the two tasks in parallel. It worked when execution highlighting was on because the VI was running before the registration happened. The slowdown gave the VI more time to run. The second approach is better since there is more chance that the VI will be running by the time you do the registration. I have even seen the second approach fail under certain conditions because the VI to run is very large and takes a while to load into memory and execute. By setting "wait until done" to false LabVIEW issues the Run VI command and keeps going on to the next piece of code without checking to see if the VI is actually running. If you really want determinism, there needs to be some kind of handshaking where the caller waits for confirmation that the VI is running before continuing.