Michael Aivaliotis

Khalid, this is correct however it appears Fernandotid has LV61 so the solution is slightly different since that method changed in LV70. Also, there is a method that operates ONLY on the ctrl of interest. No need to capture the entire panel, only the graph. Find an image attached of how to do this in 61. PS. Fernandotid, considering the Forums just saved you $495, why not donate some of your new found wealth to LAVA?

Wishfully... Read again....

Hmm, this is a neat trick from that site:

See here and here for some ideas.

Coding Challenge Ok, LAVA Members You think you've got what it takes? Do you want to own a very desirable Grey LAVA T-shirt and White Mug? All you need to do is participate and win our first official LAVA coding challenge. Challenge Description: Model the ripple effects of moving a mouse over a liquid. Download the following AVI movie to view an example of the challenge. Download File:post-2-1126486112.zip The minimum requirement is that your mouse disturbs the background image when hovered over it. The disturbance must be as close as possible to that of a liquid (ripples). The size of the image must be 500px wide by 200px height. You may use IMAQ tools and viewers, however the goal is to accomplish this challenge using the default picture control that comes with LabVIEW. If you know of a better native way to do this in LabVIEW, go right a head. For bonus points you can implement the following features: Ability to load any user defined image (jpg or gif). Hovering the mouse over the image produces a light ripple effect. Click and drag the mouse produces a more pronounced ripple effect (waves). The liquid density can be configurable. Include random droplets of rain. Include wind effects. Include falling leaves. The toplevel VI submited must be named Making_Waves.vi and can be stored in an llb file if desired. The use of sub-vi's is allowed. Please include them all. Scores for this competition will be based first and foremost on the functionality of your model and realism. They will also be based upon coding style. For help with coding style, see Chapter 6 of the LabVIEW Development Guidelines attached: Download File:post-2-1126488648.pdf Note: All coding must be done in LabVIEW. No external code, DLLs, CINs, exes, ActiveX, .NET, etc (DLL's or libraries that are part of the core LV are allowed) Have fun! Submit all solutions to: codingchallenge@lavausergroup.org. Do not post them to this thread. The deadline is Nov. 30th 2005. You can use this existing thread to discuss the challenge or to ask questions. Good luck! PS. The winner will have the choice of showing a special icon next to their name on the Forums. They will also have a special signature image. The details of these images will be revealed soon.

Your solution is very nice. This is why I love the LAVA Forums... Great exchange of ideas. Keep it up guys... and gals.

Too many colours: Bad. Default OS attributes + colors: Good. Icons on buttons with text: Good. BTW, Irene, To reduce the amount of work, reduce the colors. Use the OS attribute. This way if they don't like the colors then let them change the OS colors which in turn will automatically change your panel colors. PS. Color=US, Colour=Canadian\British.

Very Nice! Now if only it would remove transparency when I hovered over it with the mouse and then return transparency when I remove the mouse. I would program it myself but I think the Mouse Enter event is only available in 7.1. Hmm, you could possibly create a timeout event and monitor if the mouse enters one of the dial controls.

Yes, picture as intended... But I am not a closet user since I don't actually use them.

Icons on desktop are bad form in my opinion. I hide them all, How can you find anything like that? Very messy and useless. How many applications do you really use on a daily basis? Put those in the root of your start menu. It's hard to think clearly and you can easily click on them by accident when programming. I like a clean slate. No need to delete them, just turn them off globaly:

Yes, your solution is good. Here is another one which is easier to implement and actually works quite nice. BTW, this is also used somewhere in Commander I think: http://forums.lavausergroup.org/index.php?showtopic=67

OOH nice one, I gotta try me some of that!

My customer's look at me strange when I tell them: "I improved the performance of the software by adding a delay". This technique is perfectly fine.

Here's the modified example to address the concerns about unregistering the mouse down if clicked outside the indicator. Download File:post-2-1126073019.llb

Where is your improved solution then? Read my signature...

As I understand it, you want to call the same VI twice. In one case you want the front panel to open and in the other case you do NOT want the front panel to open. Well, there are two ways to do this. One way is to setup the subvi node to behave differently for each call on the diagram. You right-click on the VI and select "sub-vi node setup". This will allow you to define how the VI will behave for that call and only that call of the VI. See images below: The other way is to place a property node inside the sub-vi that controls the behavior. Then you can feed in a control wire that activates the proper behavior. The default behavior would be not to show the panel unless the boolean is set TRUE.

A question on Info-LV prompted me to answer with an example here on the Forums: Here is a VI example (LV7.1) that acomplishes this. You need to register the Mouse Up event dynamically on the indicator that will receive the drop: Download File:post-2-1125948351.vi

This can't be done. The resize object only works for a single object. Grouping them doesn't work... sorry. Well, the instructions mentioned give you some capabilities with zero programming. Of course if you tap into the panel resize event and want to do some programming then you can do whatever you want. Anything is possible in LabVIEW once you use this event.

Why not write it in LabVIEW? Is it a driver or something?

This will not help you. The Eval Formula VI works at run-time allowing formula parsing and evaluation. The Scripting VI indicated above is a development tool that creates a formula node during edit time. Here is a picture of the code so you can create it yourself in 6.1

Oh no. Please don't use global variables of ctrl references. If you absolutely must store the reference somewhere, use a functional global (while loop with shift register). Also, I'm NOT a proponent of writing directly to front panel controls from one VI to another because it makes code unnecessarily obfuscated. When debugging problems, it's hard to know what is coming from where.

This error message is comming from Windows, not LabVIEW. It happens when you double-click a VI to launch it from file explorer. LabVIEW 7.1 takes very long to load (longer than previous versions). This triggers some sort of timeout in Windows because the associated application (LabVIEW) has not launched yet.

I may be wrong, but my understanding is that you can only run a LabVIEW EXE on the platform for which it was built on.

This is a bug. Originaly (pre-LV6i), the formula node used ^ for exponent. I think in LabVIEW 6i they changed the exponent to ** for the formula node. They forgot to change the Eval node. See attached image of the formula node online help for LabVIEW 51 showing the exponent notation used.

No, S-parameters are NOT patented, I was talking about the calibration algorithms. As far as LabVIEW's capabilities, I have yet to find any limitations. Even in the RF\Microwave field. Are you using any automation at the moment? If so, what software are you using? Another thing to look at is NI's add-on RF Software tools for your industry. Perhaps if you explain what specific problem you are trying to solve then I can guide in the right direction.