Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Do form to - cannot return object - unload runs 2x
Message
De
15/08/2006 20:59:32
Cetin Basoz
Engineerica Inc.
Izmir, Turquie
 
 
À
15/08/2006 19:58:02
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 8 SP1
OS:
Windows XP SP2
Divers
Thread ID:
01145663
Message ID:
01145850
Vues:
14
>jim:
>
>when you issue, in form1, a "do form form2 with variable" command, is the variable listed in "lparameters" in the init of form2 the variable from form1?
>
>just trying to understand. thanks.
>
>paul

Paul,
With that code actually you don't need to pass the variable to form (however you should).
* Form1 code
oretval_email = createobject("MyEmailClass")

DO FORM form2 with oretval_email
Here oretval_email is visible to any routine called from there (and to routines called from the called). IOW it is not local to 'form1 code' and in form2 is visible.
* Form2 Init
LPARAMETERS toObj
Thisform.oParmObj = toObj
Here toObj is passed parameter oretval_email's reference. IOW:

oretval_email.property1 = "somevalue"
or:
toObj.property1 = "somevalue"
are equivalant. You're changing property1 of the same object.

lparameters however makes toObj local to the init routine.

If oretval_email is visible in form2 then why do you need to pass and create a property (Thisform.oParmObj) in form2 to reference it? Well if you don't and directly use 'oretval_email' in form2 then all callers of form2 would be restricted to exactly use 'oretval_email' as that object's name (you sort of aliasing your variable in form2 though it's exactly reference to the same object).

Now after saying that I want to propose another way:
Here there is a dependency between oretval_email and form2. Form2 assumes (probably doesn't simply assume but check) oretval_email has a property named property1, propertySomething etc. To satisfy this dependency caller should know what type of object to pass to form2. Of course this is not hard to manage but each time you call form2 you first create the 'oretval_email' first. Instead it might look like:
local loEmail,frmEmail
do form getEmailInfo name frmEmail
loEmail = frmEmail.oEmail
Then it's getEmailInfo form creating the object. ie:

* getEmailInfo init
this.oEmail = createobject("MyEmailClass")

* in getEmailInfo any method might modify properties of thisform.oEmail

No code in unload or destroy to return something. But instead of calling release you call thisform.hide(). When hide() is called in a modal form, code following:

do form getEmailInfo name frmEmail

is executed. At that point caller has a reference to form itself (name frmEmail) and directly gets a copy of oEmail:

loEmail = frmEmail.oEmail && this line would be reached after hide().

Now that caller has what it wants, 'release's the hidden form:

frmEmail.release()
&&and the frmEmail itself
release frmEmail

PS: Not only oEmail, caller can reach any object of 'getEmailInfo' through 'frmEmail'. ie: If in that form there were 2 textboxes named txtStart,txtEnd for a date range, caller could get their values:
local ldStart,ldEnd
ldStart = frmEmail.txtStart.Value
ldEnd   = frmEmail.txtEnd.Value
Cetin
Çetin Basöz

The way to Go
Flutter - For mobile, web and desktop.
World's most advanced open source relational database.
.Net for foxheads - Blog (main)
FoxSharp - Blog (mirror)
Welcome to FoxyClasses

LinqPad - C#,VB,F#,SQL,eSQL ... scratchpad
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform