Michael Aivaliotis

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) 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...

A new addition from GB

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.

QUOTE(Darren @ Jul 13 2007, 11:53 AM) Yes, I like it too. It will be in there.

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) 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) 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) Is it a LabVIEW bug or I forget something ? 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 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.

QUOTE(Aristos Queue @ Jul 9 2007, 07:26 AM) Just for completeness, I want to remind people that if you use a case structure to comment out code AND you still want it to stay in memory, you now need to use a boolean control on the front panel set to false instead of a boolean constant. The LabVIEW compiler is smarter now and will not include code if it's inside a case structure with a boolean constant set to false.

QUOTE(John Rouse @ Jul 7 2007, 11:10 PM) This is correct. Locking, writing then unlocking in a loop is bad and should be avoided unless the core of the OOP framework is optimized. For example, using the http://wiki.openg.org/OpenG_Class_Templates_for_LabVIEW_Object-Oriented_Programming' target="_blank">OpenG Template for queue based by-reference classes.

This is a known issue. Can't remember how to fix it but I think this is how: Installing LabVIEW 8.2.1 On Top of LabVIEW 8.2 Causes Broken VIs and Libraries I had the same problem and it was driving me nuts.

Clean up all block diagram wires

QUOTE(John Rouse @ Jul 6 2007, 09:23 PM) The main benefit of naming queues is if you are obtaining a queue by name somewhere. If not ,then this has no benefit. Queue references don't need names. QUOTE(John Rouse @ Jul 6 2007, 09:23 PM) The whole idea is to have a memory location that is specific to the process (object) instance and only that instance. This way two or three process's can operate independently and each process can have a method for doing/updating and seperate (reentrant) methods for monitoring. I'm not sure I follow. What OO framework are you using? OpenGoop, LVOOP? If you create a new instance of your object then doesn't each instance already have a place to store data? QUOTE(John Rouse @ Jul 6 2007, 09:23 PM) I understand the notifier but admittedly the behavior of notifiers is something I seldom can think of a "use case" for in my programming. Whats a really good use case for a Notifier (over a queue) anyway? Notifiers are basically occurrences with data. usually used to "wake up" loops and at the same time pass data to them. With the release of dynamic events and event structures, they become less important however still useful sometimes.

QUOTE(ohiofudu @ Jul 6 2007, 08:00 AM) Always. Old photos can be found http://forums.lavag.org/gallery.html' target="_blank">here.

You don't have to re-submit a zip file or even a screen-shot. Just leave those fields blank.

Btw, I really don't like that yellow background on the diagram. It doesn't feel right. Or is it just a side effect of the gif transform?