LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Lock panel resize programmatically, cause window to flick

Solved!
Go to solution

Ahahah this is a very good trick!

 

But I would think the power of LabVIEW goes beyond these tricks!

0 Kudos
Message 11 of 30
(927 Views)

Is there any other way to block the window resize programmatically?

0 Kudos
Message 12 of 30
(914 Views)

@Mal123 wrote:

Ahahah this is a very good trick!

 

But I would think the power of LabVIEW goes beyond these tricks!


If Zou is correct, and I believe he probably is, then the limitation is in the Windows OS.  In theory, you could hack the whole OS and change the flicker that is bothering you.   Be ready to spend a lot of developer years to that effort if Microsoft even shares enough proprietary information with you. 

 

Your case, To Wit: A Windows Application that is sometimes resizable and other times not.  Is not a case I have ever seen with any other Windows Application. 

 

Explain WHY you want the behavior and we can suggest alternate approaches that are closer to the norm for a Windows Application UX.


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

Hi,
Yes, during the window resize all graphs on the front panel update x,y scales and plot area bounds to fit in their panes.

During this operation I want to defer panel resize to the user.


But I cannot defer the panel update because of other activities (for example some panes could move dynamically) and they need to update during the resize.

Defer the panel resize is necessary to avoid consecutive user actions on windows tile bar during the graphs and panes are resizing. Otherwise errors could happen.

 

For example a conditional event "panel resize?" instead a "panel resize" event could solve, but it's not available. I imagine it depends on native windows behaviour.

 

0 Kudos
Message 14 of 30
(888 Views)

@Mal123 wrote:

Is there any other way to block the window resize programmatically?


If Set Cursor Busy is acceptable, which disable mouse and keyboard input on the FP, you can use Windows API - EnableWindow:

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enablewindow

to disable mouse and keyboard input for the frame and FP.  User won't be able to resize, close, minimize or maximize the window.  There will be no flick.  But you should still be able to update your graph.  "after some other code", make sure you call this function again to enable input regardless what error you get !!!

You should also use Set/unset Cursor Busy to let user know that your VI does NOT hang up.

 

George Zou
Message 15 of 30
(867 Views)

Hi,

Yes, this is useful! Kudos!

Could you please send me .vi for LV2013.

I imagine it uses external .dll.

 

I don't like very much external.dll, because I saw problems to build and/or run applications in 32 or 64 bit.

But also a simple mouse busy is ok.

 

Thanks

0 Kudos
Message 16 of 30
(855 Views)

I saw that unfortunately set mouse busy and disable doesn't work on panel resize.

The windows panel resize always win.

😞

 

0 Kudos
Message 17 of 30
(846 Views)
Solution
Accepted by topic author Mal123

VIs in LabVIEW 2013 attached.

 

It works on my computer while the window is disabled.

 

The dll is users32.dll, an OS dll.  LabVIEW is using it.  No need to build into your installer.  No need to deliver to your user.

 

 

 

 

George Zou
Download All
Message 18 of 30
(833 Views)

Great! It works and solve  my problem!

 

I know user32.dll is a 64 bit version of the 32-bit version included for compatibility with 32-bit applications and located at %windir%\SysWOW64\user32.dll

 

 

 So, do you think I can create my .exe application with this .dll and it will work in both 32 and 64 bit OS?!

It should be fantastic!

0 Kudos
Message 19 of 30
(817 Views)

I know user32.dll is a 64 bit version of the 32-bit version included for compatibility with

> 32-bit applications and located at %windir%\SysWOW64\user32.dll

Don't worry about the path.  Just use the file name.

LabVIEW is using it, so the right version of the dll is already in memory.

It should work for both 32/64 bit.

 

George Zou
0 Kudos
Message 20 of 30
(812 Views)