"Pane Size" event does not get triggered by programmatically maximizing/restoring

[milad_berlin]

Hi community,

the Pane Size event does not get triggered by programmatically restoring/maximizing the VI, using the property node FP.State.

The same problem occurs, when using the This VI - Panel Resize event.

The event does get triggered when using the Windows restore/maximize button, or double clicking the titlebar.

The reason why I am trying to achieve this programmatically, is that I wrote a fullscreen app which does not have a titlebar/menubar. I need the event for some manual scaling.

Info: Windows 10 64 Bit, LabVIEW 64 Bit 21.0.1f2

[Jamosgee]

This is the expected behavior. The solution is to execute the same code as in the event, at the location where you are programmatically restoring/maximizing.

[altenbach]

Events are primarily for user interactions (e.g. writing a value via local variable or value property will NOT trigger a "value change" event, except if we do a val(sgnl) property that will fire it even if the value does not change).

There are probably good reasons for that. I am sure you can work around it by some other means.

(Yes, there are some other signaling event that would be nice to have, such as the ability to programmatically trigger a "cursor move" event, for example.)

[milad_berlin]

I think you guys are correct:

Seems to be linked to the user "clicking and dragging". 

But personally I think if the pane/panel size changes, the pane/panel size events should trigger regardless.

Thank you for your insights.

[srlm]

> But personally I think if the pane/panel size changes, the pane/panel size events should trigger regardless.

Not triggering on programmatic changes is key to avoiding infinite cycles of events and being certain of the order in which events occur when they do trigger. The only exception (that I know of) is the Application:Application Instance Close event that triggers even on programmatic exit of LabVIEW and programmatic closing of the project. The LV R&D team debated that one a lot before deciding that there were just too many ways to trigger the close of a context for an application to ever guard them all.