Ahahah this is a very good trick!
But I would think the power of LabVIEW goes beyond these tricks!
@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.
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.
@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.
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
I saw that unfortunately set mouse busy and disable doesn't work on panel resize.
The windows panel resize always win.
😞
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!
> 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.