Disable(0) - Window frozen - Responds to Esc key - New in Clarion 11.1

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

6 Likes

It is not a bug, it is a long awaited feature.

1 Like

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

I would like to know that too.

:joy: :joy: :joy: :joy: :joy: :+1:

When used with a timer, it could perhaps force periodic opportunities for meditative enlightenment.

ENABLE(0) enables the window. 0{PROP:Disable} always returns false.

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?

1 Like

It does seem natural to augment the SELECT(0) suite with new functionality.

Did you happen to check whether subclassing is also disabled on a disabled window?

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.

That was a joke, Carl

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
2 Likes

Thanks Mike, plus more voluminous text so I’m allowed to post message of thanks with more than the minimum number of characters.

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 :scream:

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

1 Like

Anything that breaks existing software, is a bug.

Just because Micro$oft does it, does not make it right. 8-}

1 Like