Zou

I added this gauge to an existing VI/proj. in LabVIEW 2014 SP1, and then customized it. The VI/proj. was upgraded from LabVIEW 2011 previously. Had a huge performance problem with a translucent button before, so I checked when I have performance issue again.

Is there a way to prevent this ? Or should I check every ctrl ?

It's getting and process redraw message like crazy ! Anyone had this kind of problem before? LabVIEW 2014 SP1, Windows 7 Pro. 64 bit. Tested with LabVIEW 2018 too. Control1.ctl

I got the same message from NI about the LabVIEW SoftMotion Module. We just switched from FlexMotion to SoftMotion this year !

Version 1.1.0 overwrites the .ini settings.

Can't you use property node=>Path Text=>Scroll Position instead?

> I do use application font but I was hoping not having to go through thousands of VIs to change their font setting. But it seems that's the only Do it programmatically. Here is what I would do: Change LabVIEW font option to Segoe UI or any specific font, make it panel default. Programmatically open each VI, and simulate a Ctrl-A to select all, then simulate a Ctrl-4 to set font to Current Font. Save the VI.

Sounds like a font problem. Don't use application font, or dialog font, ... choose a specific font, for example: Segoe UI

Create a wrapper dll in C to simplify the io parameter type.

Because LabVIEW doesn't use Windows objects, so LabVIEW controls have no object ID. Only LabVIEW knows where the controls are. To OS & other applications, there is nothing on the front panel. Only 2 exceptions: ActiveX & .Net containers. The containers are child windows. Therefore they should have an object ID.

Thanks for reply. We don't have a fixed distance. Currently, autofocus is the only problem we have. Our target is as large as an engine. No image process. Just save to file for record.

I was told that most camera don't have auto-focus.

I'm looking for a color camera with built-in auto-focus feature. Please help. George

Thanks for the quick response. The exe uses a 3rd party HW and SDK. The SDK, once called, left something in the memory. I can't get rid of it. And I can't run it the 2nd times until restart LabVIEW. So I've to put it in a separate process.

I can get VI refnum and set/get control values, but I can't find any method to trigger a button click event or any value change even. Anyone did this before?

That's because NI takes care of the cross platform issue. The source code for LabVIEW itself is implemented depending on OS. For those features LabVIEW doesn't support (yet), you can implement them yourself.

LabVIEW objects are not Windows object, so you can't create LabVIEW ctrls dynamically. However, you CAN create Windows objects (e.g. text box, for both numeric ctrl & string, picture box for images, and static obj for decor. etc.) on the FP dynamically with or without a container (a child window if no container). Animations, skins, drag & drop, etc. all can be done with Windows API, just like other programming languages (e.g. C#, VB) do.

Right. That's an acceptable work around. As for loading the gif, you can always read all the images in the gif using C#/.net, and display them with a LabVIEW picture control. I did this before long time ago.

Steen Schmidt Wrote: > Just ran into this today. Wanted to use the attached animated gif, but it runs really slow on a FP (as state image on a button actually). The gif is intended to show on a button.

If you use a .net PictureBox on a button, then you won't be able to click the button in that area. It would be better to draw on the front panel directly without a control, just like all LabVIEW controls.

Just tested this image () on LabVIEW 2016. The problem is those short delays.

Which version of LabVIEW you tested? I haven't try this for recent versions.

There is a time delay specified in the animated GIF file for every frame. It is like: frame1, delay1, frame2, delay2, ... LabVIEW doesn't support the delays, uses a constant instead. You can control the frame rate in C#, but not in LabVIEW.