# Disable(0) - Window frozen - Responds to Esc key - New in Clarion 11.1 **URL:** \ **Category:** tips\ **Tags:** c11, c11.1\ **Created:** [August 17, 2021, 4:27am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400 "2021-08-17T04:27:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [August 17, 2021, 4:27am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/1 "2021-08-17T04:27:23Z")
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).` Cheers Bruce ---
**Author:** ![Mike\_Duglas](https://clarionhub.com/user_avatar/clarionhub.com/mike_duglas/32/1061_2.png) [@Mike\_Duglas](https://clarionhub.com/u/Mike_Duglas)\ **Post date:** [August 17, 2021, 8:53am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/2 "2021-08-17T08:53:33Z")
It is not a bug, it is a long awaited feature. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [August 17, 2021, 9:08am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/3 "2021-08-17T09:08:58Z")
hi Mike, yeah, as I said, not a bug, but a difference. Can you give me some ideas of where this feature may be useful? Cheers Bruce ---
**Author:** ![Mike\_Duglas](https://clarionhub.com/user_avatar/clarionhub.com/mike_duglas/32/1061_2.png) [@Mike\_Duglas](https://clarionhub.com/u/Mike_Duglas)\ **Post date:** [August 17, 2021, 10:12am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/4 "2021-08-17T10:12:33Z")
I would like to know that too. ---
**Author:** ![Clarion\_clarion](https://clarionhub.com/user_avatar/clarionhub.com/clarion_clarion/32/636_2.png) [@Clarion\_clarion](https://clarionhub.com/u/Clarion_clarion)\ **Post date:** [August 17, 2021, 10:51am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/5 "2021-08-17T10:51:03Z")
šŸ˜‚ šŸ˜‚ šŸ˜‚ šŸ˜‚ šŸ˜‚ šŸ‘ ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [August 17, 2021, 12:09pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/6 "2021-08-17T12:09:06Z")
> [@Bruce](#): > > Can you give me some ideas of where this feature may be useful? When used with a timer, it could perhaps force periodic opportunities for meditative enlightenment. ---
**Author:** ![Mike\_Duglas](https://clarionhub.com/user_avatar/clarionhub.com/mike_duglas/32/1061_2.png) [@Mike\_Duglas](https://clarionhub.com/u/Mike_Duglas)\ **Post date:** [August 17, 2021, 12:44pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/7 "2021-08-17T12:44:37Z")
ENABLE(0) enables the window. 0{PROP:Disable} always returns false. ---
**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\ **Post date:** [August 17, 2021, 2:31pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/8 "2021-08-17T14:31:36Z")
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? ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [August 17, 2021, 4:12pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/9 "2021-08-17T16:12:19Z")
It does seem natural to augment the SELECT(0) suite with new functionality. ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [August 17, 2021, 4:25pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/10 "2021-08-17T16:25:24Z")
Did you happen to check whether subclassing is also disabled on a disabled window? ---
**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\ **Post date:** [August 17, 2021, 5:21pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/11 "2021-08-17T17:21:07Z")
> [@jslarve](#): > > It does seem natural to augment the SELECT(0) suite with new functionality. Donā€™t understand? 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. I have not tried subclassing. ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [August 17, 2021, 5:33pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/12 "2021-08-17T17:33:16Z")
That was a joke, Carl ---
**Author:** ![Mike\_Duglas](https://clarionhub.com/user_avatar/clarionhub.com/mike_duglas/32/1061_2.png) [@Mike\_Duglas](https://clarionhub.com/u/Mike_Duglas)\ **Post date:** [August 17, 2021, 5:46pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/13 "2021-08-17T17:46:51Z")
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 ``` ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [August 17, 2021, 6:32pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/14 "2021-08-17T18:32:30Z")
Thanks Mike, plus more voluminous text so Iā€™m allowed to post message of thanks with more than the minimum number of characters. ---
**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\ **Post date:** [August 17, 2021, 6:56pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/15 "2021-08-17T18:56:16Z")
The Help on ENABLE says > 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 šŸ˜± ---
**Author:** ![Bostjan\_Laba](https://clarionhub.com/user_avatar/clarionhub.com/bostjan_laba/32/2498_2.png) [@Bostjan\_Laba](https://clarionhub.com/u/Bostjan_Laba)\ **Post date:** [August 22, 2021, 2:21pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/16 "2021-08-22T14:21:01Z")
Also, when doing disable(0) on Frame and then STARTing a procedure where thereā€™s an MDI window, it causes a GPF, which was not the case in CW 11.0 ---
**Author:** ![cwsumner](https://clarionhub.com/letter_avatar_proxy/v4/letter/c/919ad9/32.png) [@cwsumner](https://clarionhub.com/u/cwsumner)\ **Post date:** [August 23, 2021, 7:40pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/17 "2021-08-23T19:40:37Z")
Anything that breaks existing software, is a bug. Just because Micro$oft does it, does not make it right. 8-} ---
**Author:** ![PeterShaw](https://clarionhub.com/letter_avatar_proxy/v4/letter/p/7ba0ec/32.png) [@PeterShaw](https://clarionhub.com/u/PeterShaw)\ **Post date:** [December 13, 2025, 9:16am UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/18 "2025-12-13T09:16:31Z")
Thanks , I just switched from 11 to 11.1 and was going crazy with this ! Cheers ---
**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\ **Post date:** [December 13, 2025, 11:04pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/19 "2025-12-13T23:04:55Z")
Looking at this again LibSrc BuiltIns.CLW has this declaration for Disable: ```clarion !!! !!! Dims controls on the window. !!! !!! Field number or field equate label of a control, or the first control in a range of controls. If omitted, defaults to zero (0). !!! Field number or field equate label of the last control in a range of controls. DISABLE(SIGNED firstfeq=0, SIGNED lastfeq=0),NAME('Cla$DISABLE') ``` Both parameters have a default `Feq=0` so if you accidentally coded `DISABLE()` with no parameters you would have the same problem as `DISABLE(0)`. I would edit to remove the first `Feq=0` so it would cause a compile error: ```clarion DISABLE(SIGNED firstfeq, SIGNED lastfeq=0),NAME('Cla$DISABLE') !shipped with firstfeq=0 ``` * * * I have not converted to 11.1. One way to protect from this would be to rename the BuiltIns to `Rtl_Disable()` then code your own replacement like below that spots (0): ```clarion DISABLE PROCDURE(SIGNED FirstFeq, SIGNED LastFeq=0) !Replace Cla$DISABLE CODE IF FirstFeq<> 0 THEN !Non-Zero is good Rtl_DISABLE(FirstFeq,LastFeq) !Rtl_DISABLE() should be Cla$DISABLE RETURN END DebugOut('Problem! DISABLE(0) Called on Window: '& 0{PROP:Text} &' ... more debug ... FOCUS() FIELD() ACCEPTED() EVENT() and FieldNames of those etc') IF LastFeq>0 THEN Rtl_DISABLE(1, LastFeq). !Let range work IF ~EXISTS('C:\Clarion11') THEN !Some way to know Not on Dev Machine RETURN END DISPLAY() !Make Window Visible CASE Message('DISABLE(0) bug on current Window with heading '& 0{PROP:Text}, | 'Disable(0) Bug',,'Continue|Assert|GPF') OF 2 ; ASSERT(0,'DISABLE(0)') OF 3 ; PEEK(0, GpfMe#) END RETURN ``` The BuiltIns.CLW will need to be copied into the project folder and modified there. The replacement DISABLE function will need to be in the compile stream. This problem could happen so easily with a typo typing `DISABLE(?CusName)`, but missing the `?` so `DISABLE(CusName)`. The Customer Name is a STRING, so converts to a Number as Zero. Iā€™ve noted a similar problem with `SELECT(?CusName)` where if you miss the `?` you get `SELECT(0)` which starts an Accept All and saves a Form. ---
**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\ **Post date:** [December 16, 2025, 9:04pm UTC](https://clarionhub.com/t/disable-0-window-frozen-responds-to-esc-key-new-in-clarion-11-1/4400/20 "2025-12-16T21:04:07Z")
> [@CarlBarnes](#): > > This problem could happen so easily with a typo typing `DISABLE(?CusName)`, but missing the `?` so `DISABLE(CusName)`. The Customer Name is a STRING, so converts to a Number as Zero. That is not good. I make that kind of typos (too) often and I used that the compiler gives an error. I donā€™t think that this is a good change for whatever reason is is done.