LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically resizing Front Panel does not repaint

I am trying to extend the width of a front panel at run time when a user hits a button. The problem is
that the contents of the newly exposed front panel section are not redrawn. I have to either drag
another window over that section or minimize-maximize it to get it to repaint.

My issue is how can I get the front panel to refresh/repaint, or if that is not possible what other
ways are there to do resizing. I have tried changing the "Window Bounds" and "Panel Bounds" properties of
the VI (not at the same time) as well as using LVWUtil32 (Windows API Function Utilities (32-bit) for
LabVIEW). Each of these methods results in the same problem.

Thanks for the help!
Naveen
0 Kudos
Message 1 of 9
(5,090 Views)
HI Naveen,

It seems to me that you are having Problem with your Graphics Hardware, rather than labview. Generally the window should be repainted by system.

If you go to Display Properties -> Settings -> Advanced -> Troubleshooting or Graphic Acceleration - You may see the slider to full Acceleration. Under this setting the OS basically relegates most graphic duties to Graphic Hardware.

What you may want to do is to Move the slider a couple of notches back. And then try your VI's. Infact try all the settings on your Slider. See if it works at No Acceleration.

The Problem for me is I do not Have this Problem and cannot even simulate it to try a solution.

Another Solution is this -

There is a vi Property Class called "Front Panel" Which can be access
ed from Vi Server. Under this Class you will see a Property "Defer Front Panel Update" Generally this Property is used to Prevent a redraw. But if this Property is set to False, Labview immediately redraws the Panel.

What you may want to do is after resizing to let you program go through this Property Node set to False and See if this Helps.

By The way, the way you have to wire this Property is to Open a Vi Ref, Wire it to Property Node, Select Property as "Front Panel". Right Click on "Front Panel" and Click on Create-> Property -> Defer Front Panel Update. Wire the Referneces of the these Objects, with the output of "Front Panel" going to "Defer FP Update".

I hope your ver of Labview has these Properties. I am Using 6.1

I hope you can take it from there!!

Please advise How you solved the Problem. Good Luck!!

Mache


Another Solution which you can try is this
Good Luck!

Mache
0 Kudos
Message 2 of 9
(5,089 Views)
Well, I got it working.. I did everything you suggested and a few other things that I though of,
prompted by your comments, but none of it changed a thing! So, I decided to start from scratch and just
have a VI resize itself and immediatly close. Worked great. So, the solution turns out to be that you
cannot resize a VI while inside an Event Handler. At least that's how I got it to work, moving the code
outside of the event handler.

Thanks for the help 🙂

Naveen
0 Kudos
Message 3 of 9
(5,089 Views)
I can confirm Naveen's report that the panel resize only works when the code is OUTSIDE an event structure.

Since there is no obvious reason why a panel resize should not work WITHIN an event structure, I would qualify this as a bug (or at least call it "incorrect behaviour").

Naveen, did you report this to NI?


Franz
0 Kudos
Message 4 of 9
(5,089 Views)
I hadn't reported it, but I will now that you've brought it to my attention.

Naveen.
0 Kudos
Message 5 of 9
(5,089 Views)
A second confirmation.
I used the event structure to decide when to update the panel, then I had the panel update OUTSIDE of the event structure and it workes fine.

I used the FP.PanelBounds property (for my specific app) but the FP.WinBounds also works (outside the EVENT structure)

In addition to using the panel (and window) properties in LabVIEW, I also tried calling the WinAPI functions directly to resize my window. It worked but with the same caveats as presented above i.e. this is deffinately a problem caused by something in the event structure.

Hope this helps anyone else looking for answers
0 Kudos
Message 6 of 9
(5,089 Views)
This is a tricky one, but I ran into the same problem and found the workaround in NI's knowledge base. Using the property node "Windows (Panel) bounds" is ok and I would say it is recommended LabVIEW style. To get it working you should select the case that does the resizing, and then open the event structure's context menu (right click on event structure frame). There is one menu item "Lock Panel until event handler completes". This is selected by default. The name of this property explains it all. Deselect it, and have fun!

Sorry for the late answer!
0 Kudos
Message 7 of 9
(5,089 Views)
I've been using LV for 7 years now and I too have just run into the programmatic resize / LV event structure bug you mentioned. It is very irritating and was difficult to figure out the cause / solution.

IMO: This is yet another bug with the event structure in LV 6.1. I don't have LV7 installed yet so I don't know if this problem has been solved.

I've seen other non LV paradigm behaviour which occurs if you put event structures inside of case structures that result in locked up front panels as well.

(Try putting an event structure on each side of a true/false case box and letting them default to lock front panel. If you try to run this it will lock up under 6.1 and you'll have to use the case box to kill LV.)

This erratic behaviour of the eve
nt structure needs to be fixed ASAP by NI so that it behaves in a manner consistent with the long established LabVIEW diagram flow paradigm.

I've done a lot of multithreaded and event driven programming under Microsoft Visual C++, Microsoft Visual Basic, and National Instruments LabVIEW going back for 7 years now and the behavior of the event structure under the "lock panel" option is in my opinion inconsistent both with anything I understand about event driven or MT code as well as with LV programming.

I have unchecked the "lock panel" box on the event structure and it immediately cured my problem. The other suggested fixes here (h/w acceleration, defer redraw) had no effect.

Best Regards,

ddeclue@bellsouth.net
0 Kudos
Message 8 of 9
(5,089 Views)
Hi Everyone,

Thank you SO MUCH for sharing the solution to this really goofy problem! It is 9:20PM the night before a customer demo, and I can't tell you how thrilled I am that you guys took the time to post the solution here! THANK YOU!
0 Kudos
Message 9 of 9
(4,909 Views)