LogMAN

Hi, j_meier I think the MView.lvproj file is missing in your new build. However, your code is just amazing!!! Very efficient... It's true, caring large VIs is important and necessary. If you need space on your block diagram, hold the 'Ctrl' key and use the left mouse button to make space. Release the mouse button to commit. Carefull: marking an rectangle will cause all code to move in 2D. To make space in one direction, move your mouse until there is a straight line (almost not visible). Tip: Use a dummy- VI for testing. Yes, it's hard to read and the VIs need some Artwork, but the functionalities are amazing!!! I suppose your code will be used in many projects from now on (Of course after some enhancements). Cheers, LogMAN

No wonder I never encounter an error like that. I've never used classes in project libraries. So, problem solved ... somehow ...

That's interesting... I've attached two files to prove. (TrayIcon.RegisterEvents and TrayIcon.EventHandler are of private scope) Changing the classes content to private will cause the files within the palette to show a red cross. I also need to update my last post: Protected items are shown with a red cross too. Sorry, but if your class is public and you have full access to all contents, it might be a bug.

Hi, vugie The VIs are marked as "private". So, if you use libraries or classes and a VI is marked private, it'll be shown this way. The problem is: You can't use these VIs until your VI is part of the class or library. To solve the problem, open the library or class and mark them as "public". Note: VIs with red crosses are private. VIs with yellow crosses are protected. VIs without crosses are public. Greetings, LogMAN

Hi Suvin, I've saved the snipped for LV86. Distribute.vi There is also the Object_distribution package for OpenG attached (also for 8.6) Object_distribution_86-1.2-0.ogp I suppose you are already using JKI VIPM. Greetings, LogMAN Edit: sorry, VI was broken - now it's fine.

Hi, venky 2810 This should not be a big problem. While building the installer LabVIEW ask you to insert the LabVIEW DVDs. If you insert the DVDs in your machine and selecting the correct drive name it should work. Greetings, LogMAN

two minutes to late... Jim's first.

Hi, Ton I support the answere of mje with one additional thought: I suppose your application is running in two asynchonous loops, which results in multiple threads on your machine. Multiple threads (multithreading) forces programms, which are not using the CPU at this moment to switch to background, so another application could run for a couple of miliseconds. If you execute your sender loop to send the "stop" command, it it's using the CPU completely by sending the command and directly destroying the event, so there is no point for the computer to force the process to the background. By adding a wait functionality, the thread will be halted for just a millisecond or less, even with a zero connected to the terminal. Within this milisecond your listener loop is able to receive the event request to execute. After that, the sender thread comes back and destroys the event. So the behavior you've described is not a bug, but a multithreading dependend problem. To solve this problem, you could force the sender thread to wait for just a milisecond as you did. But this way of programming is not very good, because as mje already said, it results in undefined states. You should consider to add some synchronisation functionality in your code as I would do, or just don't destroy the event, because LabVIEW will take care of that on it's own (also not good style). Greetings, LogMAN

Just click at the particular entry and change it (as shown in the picture)

We have used LV2009 for one large project and never since. That was because of many failures. For instance: Error in Line XYZ in MemoryManager.cpp. LabVIEW crashed with this error every 2-3 runs. Also after we updated to LV2009 SP1... We switched back to LV8.6.1f1 and everything works fine. Also the VI and EXE files were larger (LV2009: 15Mib / LV8.6.1f1: 12Mib) We use almost everything of LabVIEW, except of Mathscript and Remotepanels. Our applications have about 200 - 300 self made VIs. We are in need of better multicore processing, but LV2009 is to unstable. But I think, wether to use LV2009 or not depends on your needs. If you do parallel computing and need more performance using multicore processor, LV2009 might be a good choice. If you only do "normal" stuff, LV8.2 or LV8.6 / LV8.6.1f1 is the better choice for now. Install LV2009 on one computer, load some of your projects and do some tests. (Also perform some errors!!!) Greetings, LogMAN