LogMAN

It's not like my programs are perfectly designed at the beginning, but sometimes there are some functions I know I will use more often, so I take the time to make it more readable! The only thing I do always is correct wiring, because it makes it easier reading code after a day or so. You know: You can do 80% of work in 20% time, but you'll need 80% time getting the last 20% work done! (I forgot who said this sentence first ) So, after finishing a program in LabVIEW, I go through the code writing it more readable and placing documentation all over my VIs. It's hard work, but it worth the time. However - Your code is much more readable as most of the code I have to read all the day. Code like this: Caution: Bad code! is very common! One thing that's really great with your project: The way you organize your VIs in your *lvproj. So, don't worry and keep on programing, writing code more readable one step after another. (Do one thing better each project - ) Your MView programming language is well designed, as far as I concern. Even if I don't use your project as is, It's a great base concept for me to write a similar distribution! I was going write a similar project like yours, but I'm to lazy for taking the time of a concept like your's. So, thanks! I don't know much about memory management in LabVIEW, so it might worth the work of writing a new post (Interesting question). You could write an external DLL in a conventional language, using it in LabVIEW as "Memory" (Not Recommanded) You might try some of the 'In place element structure' functions (LabVIEW 2009 and 2010 are getting better with that step by step.) One thing about your memory management just now: It's an interesting way of thinking and writing something like heap and stack (pseudo, but however) in your project! Nice to read and something to use somewhere else... Thanks for that kind of idea too. Greetings, LogMAN

Thanks, it worked just fine. I know exactly what you mean. Using LabVIEW as IDE makes programming easy like playing a game. But design in LabVIEW is as important as description in conventional programming languages. A good way to clean programming is a design concept. You have to define your programming design and use it in all your programms. (Believe me, after some time it goes easier and easier) Here are some concept ideas I use normaly. They are easy and fast to implement after some training: 1. Do never create wires behind structures, you might search errors for hours!!! (Move wires above or below the structure.) 2. Use one connector pattern in all of your VIs (except of special VIs), with error in and error out connected to opposite connectors at the same place every time. (This will help you creating a "VI line" and using the "flow" concept of LabVIEW. (Even change the pattern of automatically created Sub-VIs.) 3. Do not move wires around like snakes. (I know it's hard at the beginning, so right clicking the wire and selecting "cleanup wire" helps ) 4. Programming VIs, larger than your desktop should only expand in one direction (horizontal, vertical). 5. Use labels on your block diagram for documentation. (I normaly use a special color for documentation labels) 6. If any function might be usefull somwhere else, create a sub-VI. (VI icons should at least have text within) 7. Are you using parallel loops, larger than your desktop? Create seperate VIs for each of them. 8. Move inputs on the left side, outputs on the right side of your block diagram. 9. move labels of inputs on the left border, labels of outputs on the right border. (Implemented as option in LabVIEW 2010) 10. Do never lecture your concept ideas... aaah... I know these concepts does not work always, but it's much easier to maintain your VIs, if you have a clean concept. The "Right Click Framework" is also a good way to clean VIs (Thanks to all). There are two snippets attached as sample for the concept. (First is original, second is changed) Wow, my hands are burning... I'll need something to cool my head. Cheers, 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