Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Release a form
Message
 
 
À
18/11/2004 04:16:10
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Titre:
Versions des environnements
Visual FoxPro:
VFP 7 SP1
Database:
Visual FoxPro
Divers
Thread ID:
00960885
Message ID:
00962647
Vues:
14
Thomas,

Miroslav started the thread talking about huge numbers visible form objects.

>Yes and no - it was not a very good explained example on my part.
>I am usually quite happy with the possibilities that containership gives me, even if the concept of talking to other objects via .parent is not always seen positive, as it can lead to [too] tight coupling. But TANSTAAFL works here as well, and I hadn't considered the price of containment to large enough to measure.

Exactly.

If that construct code I posted before is changed to this there is an order of magnitude performance difference:
dimension laObjects[2000]

? "start create", seconds()
for i = 1 to 2000
   laObjects[i] = createobject( "commandbutton" )
endfor
? "finish create", seconds()

laObjects = .null.
? "finish destruct", seconds()
The 2000 objects construct in 0.13 seconds and destruct in 0.02 seconds.

>I was specifically talking about business[rule] objects, which I sometimes "cast" as visual objects during development time to repeatedly start/test business rules, which on normal operation [field validation for example] get called by the business layer. Usually on release the common parentclass of the rule objects is redefined as non-visual class and/or the "behaviour code" of many rule objects for one table is moved into one object for the whole table. So *after* development not only there is no need to interact visually - it is the prefered way of operating <g>. The "business rule container" doesn't need containership, I only have to be able to access each rule with a specific name, although I prefer to be able to iterate over all rules/rule objects as well.

I use container as my base cObject class. Every bizobj derives from this class. Using container allows me to easily use designtime containership where it is appropriate, like building up more complex components from simpler ones. The containership allows messages to be broadcast both inwards and outwards. For example the outermost object can broadcast a property setting to every contained child object. All of this is easily done via the Objects[] collection and this.parent.

But I just leave these classes as container and never redefine them, but they are never visible components at runtime. Even if they are AddObject()'d into a form that is using it's services they stay .Visible = .f. If they are created via CreateObject() they can't be visible.
df (was a 10 time MVP)

df FoxPro website
FoxPro Wiki site online, editable knowledgebase
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform