LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Lock panel resize programmatically, cause window to flick

Solved!
Go to solution

Hi All,

I want to avoid the user can resize the panel during a part of my code.

 

I tried a VI property with:

Front Panel Window -> Resizable

Putting it false and then true after some other code.

 

  • The problem is that when change this property cause window to flash. 

Is there any other way to change panel resize behaviour on the fly without the window flash issue?

 

Thanks 

 

0 Kudos
Message 1 of 30
(925 Views)

@Mal123 wrote:

Hi All,

I want to avoid the user can resize the panel during a part of my code.

 

I tried a VI property with:

Front Panel Window -> Resizable

Putting it false and then true after some other code.

 

  • The problem is that when change this property cause window to flash. 

Is there any other way to change panel resize behaviour on the fly without the window flash issue?

 

Thanks 

 


Try:

  • Involk Defer FP Updates = TRUE
  • Write property FP.Resizable
  • Insert a small Wait (0mSec would force the UI Thread to release)
  • Involk Defer FP Updates = FALSE

Let us know what you see!  If possible use TechSmith Capture (Formerly Jing) to demonstrate what you are seeing. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 30
(903 Views)

Hi,

I will try adding Defer FP Updates.

 

Thanks 

0 Kudos
Message 3 of 30
(885 Views)

Hi,

Unfortunately it doesn't work.

I attached the VI.

The front panel still blinks two times, when the FP.Resizable changes its state.

 

Someone know how to change FP.Resizable programmatically, but in a transparent mode for the user?

0 Kudos
Message 4 of 30
(855 Views)

Defer FP Updates doesn't work because this is not a redraw problem.

If you put a property node FP.NativeWindow before and after FP.Resizable, you will find the Windows handle changed.  That implies that LabVIEW creates a new FP.  That is why FP "flicks".

 

 

George Zou
Message 5 of 30
(840 Views)

This is a hack that seems to work about 80% of the time on my computer, the other 20% it blinks. Interestingly the Window Handle doesn't change with this hack.

 

Basically before you make the panel resizable, minimize it, then change the resizable part, then go back to standard state. Obviously you will want to remove any delays in there, like I did. Sometimes it blinks but not all the time.

mcduff_1-1690840821683.png

 

 

 

0 Kudos
Message 6 of 30
(816 Views)

Hi,

Thank you, with this code the only difference I see is that windows doesn't flicks, but now it goes down and then reappears.

Sincerely I prefer it flicks, it is less invasive.

Anyway, for a user both behaviors are not good, because the user doesn't request these behaviours, they are necessary only to protect a part of the code.

 

 

 

0 Kudos
Message 7 of 30
(780 Views)

@zou wrote:

Defer FP Updates doesn't work because this is not a redraw problem.

If you put a property node FP.NativeWindow before and after FP.Resizable, you will find the Windows handle changed.  That implies that LabVIEW creates a new FP.  That is why FP "flicks".

 

 


Interesting!.     Hmmmmm....

 

OK let's steal a trick from  OZ The Great and Powerful (pay no attention to that flicker behind the cursor!)

 

Try bracketing the FP.Resizeable writes with Cursor Set Busy and Cursor Unset Busy.  Then ask a coworker to observe the screen without telling them the panel flickers.  The Cursor change should draw the eye like a magician's gesture so you never actually see the trick with the other hand and, the flicker will only be noticed if you first know the trick.  Anyone who does notice the flicker will at least be impressed by the skillfully done slight of hand.


"Should be" isn't "Is" -Jay
Message 8 of 30
(753 Views)

I love this answer.

 

Putting the experience back in UX!

0 Kudos
Message 9 of 30
(733 Views)

@B_Strange wrote:

I love this answer.

 

Putting the experience back in UX!


The beauty of it all is; Users are TRAINED to ignore anything happening behind a busy cursor!  You could have random Dancers-a-Go-Go appearing on screen behind a busy cursor and nobody will notice.


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 30
(722 Views)