Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Eliminating multiple refresh()
Message
From
29/04/2002 11:09:24
 
 
To
29/04/2002 10:40:25
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00650236
Message ID:
00650412
Views:
17
Agnes,

Thanks for the suggestions. My comments are embedded below:

>>I have a related question. I work with an accounting system called Accountmate. They have a set of classlibraries used on all their forms. I am trying to rework their class libraries for a number of reasons. But I didn't realize there is so much overhead with refresh(). In the refresh of each of their control classes, they have a line: this.enabled=thisform.editmode
>>Each form starts out with editmode false, with the focus in a lookup control (the lookup controls refresh is: this.enabled=!thisform.editmode) After the user does a key lookup and selects a key value, the editmode is switched to true, and then a thisform.refresh() is called.
>>
>>So, my question is: what would be a more efficient way to reset the enabled property for each control on the form?
>>
>>TIA
>>
>Hi David,
>this will run into philosophical problems ::).
>
>If it is as simple as
>
>this.enabled=thisform.editmode
>
>and is really for every control class, it would be much faster:
>
>thisform.lockscreen = .t.
>*to  what ever is to do
>thisform.editmode = lNewValue
>THISFORM.SETALL('ENABLED',thisform.editmode)
>..
>thisform.lockscreen = .F.
>
>
>This runs thru containers too.
>
The setall() sounds good. I was considering that

>It will have problems if somethings enabled property depends on something else then "thisform.editmode".
>
>In this case the following is faster then the REFRESH thing
>is
>
>thisform.lockscreen = .t.
>*to  what ever is to do
>thisform.editmode = lNewValue
>THISFORM.control1.enabled = thisform.editmode and what_else_enables_this_control
>THISFORM.control2.enabled = ...
>..
>thisform.lockscreen = .F.
>
>because it doesn't fire on each REFRESH().
>It gives you more control than SETALL, but ends up in a lot of coding.
>
Yes, that is a lot of coding, which is what I am looking to avoid.
I think that a compromise would be to issue setall() with screen locked. Then, selectively disable the controls that had other conditions besides the editmode (which there are) with:
THISFORM.control1.enabled = thisform.editmode and what_else_enables_this_control

as you suggested


>Maybe you can mix both ways, also have a look at SETALL's 3.th parameter.
>

I assume by the above that you mean that I vary whether I will enable it by the class. I'm not sure that would be a deciding factor here.

>If you really like to be a hard OOP crack, put on each control class a assign method for enabled method (This is up form vfp 6.0 I guess?)
>Then you can use THISFORM.SETALL and do the fine stuff inside of each control, use DODEFAULT() for inheritance and so on.
>This is fine OOP style to give the control the knowlege about control's properties.
>
>I, personnaly, avoid OOP in this case, because it means one call (SETALL) will end up in n enabled_assign calls. The way VFP is programmed, a straight programm is always a lot faster then calling methods. (A total of a hundred controls is not as much as it may look. If you play with inheritance each control using DODEFAULT() or the like it will be cruel)
>

I am new to some of these more advanced oop techniques. I haven't yet used Acess and Assign. So I will experiment with it. It sounds like you are saying, however, that the execution would be slow, and that is what I am trying to avoid. So I will experiment with it.

PS- I never responded to your response to me on SET CLASSLIB (if you remember) - I got sidetracked. I will come back to that one (soon I hope)

>HTH
Yes, very much so. Thanks.

>Agnes
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform