DCPushButtonXP is slow if I use the Hide option

[hz_scotty]

In _dcxbutt.prg I occasionally get an error at about line 703
"IF! :: isShadowOnMouseOver .OR. :: mouseMode == 1" where ":: isShadowOnMouseOver = NIL".
No idea why. As a workaround, I have added these lines in front of the relevant point.
<code>
IF Valtype (:: isShadowOnMouseOver) == 'U'
:: isShadowOnMouseOver: =. t.
ENDIF
<endcode>
IF! :: isShadowOnMouseOver .OR. :: mouseMode == 1
This eliminated the error for me.

[rdonnay]

That's a good enough workaround for you.
It appears you have an older DCDIALOG.CH.

I made a different fix in my source code.

[Tom]

Maybe that improvement should be adapted to other controls aswell, Roger, since not only pushbuttons can have a hide clause which shouldn't be evaluated if the parent isn't visible anyway.

[rdonnay]

Tom -

I had thought of that and made the following change to _DCCLASS.PRG.
It has to also test for a parent being a tabpage, because if the tabpage is minimized Xbase++ parts returns a .T. for ::visible(). I consider that a flaw in their code.

Code: Select all

STATIC FUNCTION _WhenHideEval( lEnable, lShow, lProtect, oXbp )

IF Valtype(oXbp:whenBlock) = 'B'
  lEnable:= Eval(oXbp:whenBlock,oXbp)
  IF lEnable
    oXbp:enable()
  ELSE
    oXbp:disable()
  ENDIF
ENDIF

IF Valtype(oXbp:hideBlock) = 'B' .AND. oXbp:isVisible() ;
      .AND. IIF(oXbp:parent:isDerivedFrom('XbpTabPage'),IIF(oXbp:parent:Minimized,.f.,.t. ),.t. )
  lShow := !Eval(oXbp:hideBlock,oXbp)
  IF lShow
    oXbp:show()
  ELSE
    oXbp:hide()
  ENDIF
ENDIF

IF Valtype(lProtect) == 'L' .AND. Valtype(oXbp:protectBlock) = 'B'
  lProtect := Eval(oXbp:protectBlock,oXbp)
ENDIF

RETURN oXbp

[Tom]

I'll test that in our applications. Thanks! And have a fantastic day!

[skiman]

Hi Roger,

Looks me as a very good idea. I will also test it.

Just wondering if the same could be done for the WHEN clause? Could it be necessary to evaluate the when clause if an object isn't visible. I suppose it depends of the content of the codeblock, but normally this codeblock isn't used to set other vars.

Meanwhile I made the following change. This makes a little difference in some of my screens. On a server with 30 users working via remote desktop it can make a difference.

Code: Select all

STATIC FUNCTION _WhenHideEval( lEnable, lShow, lProtect, oXbp )
if IsMethod(oXbp,'PARENT') .AND. (!oXbp:parent:isVisible().or. oXbp:parent:isDerivedFrom('XbpTabPage').and.oXbp:parent:Minimized ))
	return oXbp
endif
...

[Tom]

I had the same idea, Chris. I'm still thinking about the consequences. We do have lot more WHENs than HIDEs. HIDE hides and shows, but WHEN en- or disables. It should be ensured that all controls are usable when needed. I think they are with your changes, which are the same I made.

Anyway, the clause we use most is EDITPROTECT. This works completely different. EDITPROTECT removes the focus from a control which's EDITPROTECT-block fires .T.

On a server with 30 users working via remote desktop it can make a difference.

On any workstation that calls dialogs again and again it can make a difference. Count the hours, the days, the weeks, the months, the years. Every 10th of a second counts.

[skiman]

Hi Tom,

Meanwhile I changed it. Seems you can have an object without parent. When testing I had a simple dialog without parent, and an error appeared.

Code: Select all

if !oXbp:isVisible().or. (IsMethod(oXbp,'PARENT') .AND. oXbp:parent:isDerivedFrom('XbpTabPage').and.oXbp:parent:Minimized )
	return oXbp
endif

On any workstation that calls dialogs again and again it can make a difference.

Yes, 100% true. But if the difference is 1/10 of a second in a dialog, a user won't notice immediately. But on a server with 30 users, the performance of the server will benefit of it.

Anyway, each improvement makes an application better, and the overal feeling when working with it will be better, which is the main goal of this little improvements.

[Tom]

Mmmh. Did some testing with the improvement. It seems that the sequence of the objects during creation is important, but that can't be really true. Anyway, if an object and it's parent have the same condition for being hidden or not, I face the phenomenon that the parent gets shown but some of the children not. The parent (a DCSTATUSBAR in one case) is created first, the child is a DCCOMBOBOX. Same with listboxes. Statics and pushbuttons and others show up, but the list- and comboboxes stay hidden. Strange. All object have the same HIDE codeblocks.

[skiman]

I don't have that situation, so I can't confirm this behaviour.

I'm using dcstatusbars with buttons. The HIDE clauses is only for the buttons. This is still working with the modification.

I use DCSTATIC's with HIDE clause. The child objects don't have HIDE clauses, they follow the dcstatic. Eventually they have WHEN clauses. This is working with the modifications, but I was wondering if these objects are visible at that moment. So if these when blocks are evaluated, even if their static parent is invisible.