2 replies to this topic

[jaco0646]

Clicking on a control while its g-label is already running from a prior click will have no effect and the event is discarded. To prevent this, use Critical as the subroutine's first line...

I wish that Gui threads could also use Critical, Off to allow Gui controls to interrupt themselves.

Gui, Add, Button, w75, Toggle
Gui, Show, w200
return
GuiClose:
 ExitApp

ButtonToggle:
 Critical, Off  ;Allow this button to interrupt itself.
 bool := !bool
 While (bool) {
  ToolTip, looping
 }
 ToolTip
return

Or maybe something like #MaxThreadsPerGuiControl?

[Lexikos]

I think this highlights a need for separation between GUI and program logic. For instance, simply don't loop (or perform whatever time-consuming task) from within the GUI thread, and it won't be a problem.

Critical, Off ;Allow this button to interrupt itself.

That might make sense if Gui threads were Critical by default. It might also make sense if "Critical" intuitively meant that the button should not be able to interrupt itself. However, it doesn't make sense. Why should a non-critical subroutine be run when a critical one would not?

Or maybe something like #MaxThreadsPerGuiControl?

That seems more like a workaround than a solution. It might be consistent with hotkeys, but OnMessage does it differently and SetTimer doesn't have anything equivalent. I won't rule it out, but I'd like to see a better solution (that needn't necessarily retain backward-compatibility).

[jaco0646]

How about allowing Gui threads to interrupt themselves by default? Then Critical remains the same, for cases where that's undesirable.
EDIT: I changed my mind. That's a bad idea. Maybe another option for Gui, Add instead.