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

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

7 Likes
2

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

1 Like
3

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

4

I would like to know that too.

5

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

6

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

7

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

8

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
9

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

10

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

11

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.

12

That was a joke, Carl

13

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
14

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

15

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:

16

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
17

Anything that breaks existing software, is a bug.

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

1 Like
18

Thanks , I just switched from 11 to 11.1 and was going crazy with this ! Cheers

1 Like
19

Looking at this again LibSrc BuiltIns.CLW has this declaration for Disable:

      !!! <summary>
      !!! Dims controls on the window.
      !!! </summary>
      !!! <param name="firstfeq">Field number or field equate label of a control, or the first control in a range of controls. If omitted, defaults to zero (0).</param>
      !!! <param name="lastfeq">Field number or field equate label of the last control in a range of controls.</param>
 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:

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

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.

1 Like
20

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.