So, this isn’t a bug, but a difference in behaviour between Clarion 11.0 (build 13630 and earlier) and Clarion 11.1
In Clarion 11.0 and earlier calling Disable(0)
appears to have no effect.
In Clarion 11.1 calling Disable(0) “disables” the window (functionally) but not visually. All window behaviour is prevented - so the mouse does not work to move the window, minimise, maximise, system menu do not respond to mouse or keyboard, indeed all mouse events are completely ignored.
The window does respond to the Esc key (and closes), as long as it has focus. (And it can’t seem to get focus back after losing the focus.) I’ve also seen very limited visual (but not “real”) response to the Tab key.
So if you get this “dead window” effect, it’s likely because some code is doing a DISABLE on a value which is 0. Specifically I discovered it in Premiere, which disables a bunch of controls from properties - as in disable(self.OkButton)
where the OkButton property was 0. This was fixed to read if Self.OkButton then disable(self.OkButton).
The Disable(0) Window cannot be Moved nor Minimized. The System Menu cannot be accessed, but Alt+F4 does close the Window. The behavior seems odd that there is no visual clue it is disabled. To most users the Application will appear frozen and that’s how the bug will be reported.
I think this is a bad idea that will reveal some accidental bad code that’s been fine for decades. If this feature is needed there should be an explicit new command like DisableWindow() or a property PROP:DisableWindow that can =True or =False. BTW 0{PROP:Disable}=1 also works like DISABLE(0) as expected.
This kind of non-visual Window Disable can be done prior to 11.1 by opening a second or inner ACCEPT loop and selectively processing only the messages wanted e.g. Alert keys. I thought there was a PROP: to indicate Inner Accept but I cannot find it?
DISABLE(0) is logical given that HIDE(0) works. A DISABLE(0) is like a HIDE(0) window that nothing can be done, but is visible. Also DISABLE() with no control will disable the Window.
FYI, DISABLE(0) sends WM_CANCELMODE and calls EnableWindow(false), so to prevent from disabling a window we can (I have tested, it works) subclass a window (not a client) and overwrite 2 messages:
CASE wMsg
OF WM_CANCELMODE
RETURN 0
OF WM_ENABLE
IF wParam = FALSE !- EnableWindow(false) was called
!- remove WS_DISABLED style
dwStyle = this.GetWindowLong(GWL_STYLE)
dwStyle = BAND(dwStyle, BNOT(WS_DISABLED))
this.SetWindowLong(GWL_STYLE, dwStyle)
RETURN 0
END
END
If the first control and last control parameters are omitted, ENABLE reactivates all controls on the window.
I tested doing DISABLE(1,LastfField()) ; ENABLE( ) and that did Not “reactivate all controls”. Of course it did work to ENABLE(1,LastfField()). So the Help is not correct