passing variables 2

[cameron40]

Can anyone tell me the most efficiant way to pass variables and data from one form to another
thanx

 

[robsuttonjr]

In the init of the form put at the very, very, very top (essential nothing above it including spaces):

PARAMETERS lcReceivedValue


When calling the form:
DO FORM frmSomeFormName WITH lcSentValue

The lcSentValue will be passed to the form named someformname then you can play with the lcReceivedValue. When done with the someformname you can state in say unload:

Return lcReturnedValue

To pass back to the caller a value

If passing to and from a form use something like:

DO FORM frmSomeFormName WITH lcSentValue TO lcReturnedValue

Look at the help on DO FORM for more details

DO FORM FormName | ? [NAME VarName [LINKED]] [WITH cParameterList]
[TO VarName] [NOREAD] [NOSHOW]






The more I learn the more I find I know nothing.

Rob

 

[JRB-Bldr]

Each form's encapsulation gets in the way of "easy" variable passing from one to another.

Either declare the variables PUBLIC and then assign values prior to the "pass" and RELEASE them after the "return".
Or use a common table that both Forms can access to hold and/or "pass" common variables.

Good Luck,
JRB-Bldr

 

[robsuttonjr]

The other frowned on method is to declare public variables in a main.prg (excuted before the forms) but I don't do that (anymore) cause its poor practice. Simply add more parameters with commas and pass what you need to the called form.
ie

PARAMETERS lcValue1, lcValue2, etc

DO FORM frmForm WITH lcValue1, lcValue2, etc

Makes for more reusable form that can be transported and always try to use form variables instead of public.

The more I learn the more I find I know nothing.

Rob

 

[craigsboyd]

Rob has outlined probably the best way to handle this though I would use the line "lParameters lcValue1, lcValue2" so the parameters end up with a local scope rather than private. Then in the init assign some form properties the value of these passed in parameters.

this.MyValue1 = lcValue1
this.MyValue2 = lcValue2

...you can define these form properties at design time using the appropriate item in the FORM menu or you can add them in the init as well using addproperty

this.addproperty("MyValue1", lcValue1)
this.addproperty("MyValue2", lcValue2)

...this will allow your values to have the same scope/duration as the form itself in that when the form gets destroyed these properties get released from memory.

Now, if you feel the need to use values that have a Public (Global) scope, you'll want to forego declaring Public variables as has already been mentioned and add properties to the _screen object instead. This is the preferred method of handling this in VFP OOP-style applications when it is necessary for values to have a global scope. Just add them as you would to a form...

_screen.addproperty("MyValue1", lcValue1)

...starting with VFP8 we even have a way to remove these properties should we feel the need to:

REMOVEPROPERTY(_screen,"MyValue1")

...before that about the best you could do was to set the value of the property to NULL

http://www.sweetpotatosoftware.com

 

[Mike Lewis]

Rob,

I hope you don't mind by picking up a couple of your points:

In the init of the form put at the very, very, very top (essential nothing above it including spaces):

There's no problem in putting spaces, or even comments, above the Parameter statement. The only restriction is that there must be no executable code above it.

PARAMETERS lcReceivedValue

I'd also suggest using LPARAMETER rather than PARAMETER. That way, the received parameters are local to the Init, which is good practice.


JRB-Bldr,

Either declare the variables PUBLIC and then assign values prior to the "pass" and RELEASE them after the "return".

This is not good practice. If you have to use public variables at all, they should be used sparingly, and they should all be declared in the same place, which is usually at the top of the main program. You should certainly not declare them on the fly like that.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[robsuttonjr]

I appreciate the input and corrections. My mind is like one of those things I can't remember... I have a general idea about things but I bow to those who can actually remember what they read and learn.
Thanks people and know you all are most valuable to me. Without this forum I would have never been able to call myself a 'programmer'.



The more I learn the more I find I know nothing.

Rob

 

[FoxKid]

Hi all,
When I am giving this command :
do form temp to xname
It is giving an error "The TO clause can only be used with model and formsets"
I am using pageframe in the form. Am I getting this error due to this only.
I want to return a value to a variable after unload event of the form.

pls. help
thanks and regards

 

[Stefan5627]

Foxkid,

You can only return a value from a modal form.
To make a form modal you must set the windowtype propertie to 1-Modal


hth,

Stefan

 

[FoxKid]

Thanks Stefan,
But can u please clear me one more thing and that is the difference between model and modeless and its uses in different places.

thanks and regards

 

[darrellblackhawk]

FoxKid:

A "Modal" form is what's called a "blocking" form. That is, the form disallows any other form within the application from getting the focus until the form is closed. Plus it has the nice and necessary feature of blocking program execution of the calling module's code until the form exits.

The primary purpose is to insure the user enter information or performs some important task on the modal form before the application moves on - such as entering authentication credentials to enter a secure state, and as mentioned above to insure proper sequencing of program flow.

A modeless form is a form that allows moving between any open forms in the application. By the way, this is why you can only return a value from a "Modal" form. If you need to return information from a "Modeless" form, you'll need to assign the value to a memory variable that's within the scope of whatever module/function, etc. that needs the info. I pass a character value to modeless forms, which is the name of a variable to assign the return value in.
i.e.

private cVarName
do form XYZ with "cVarName"

* Note that the module that calls form XYZ continues execution at the point so to actually make use of the value assigned to cVarName by form XYZ, the module must be in some type of loop.

* Form XYZ runs

* Form XYZ's init event

procedure init
  lparam cVarNameToAssign
  this.cVarNameToAssign = cVarNameToAssign
  * more initialization commands...
endproc

Procedure SomeMethodToAssignCVarName
* Note: this can be executed at any point while the
*       form is running. Matter of fact, this is a way
*       the form can inform the calling module of its
*       progress - although having a reference to an
*       object that's passed to the init method is better

  local cVarNameToAssign
  cVarNameToAssign = this.cVarNameToAssign
  &cVarNameToAssign = value_to_assign
endproc

* Form XYZ exits

* Calling module is still running or exited already based on the value assigned to cVarName by form XYZ

Note:
No matter what type of form is active in the application, this doesn't preclude accessing forms open in other applications.

Darrell

 

[FoxKid]

Thanks Darrell for your useful information and explaination.

 

[DSummZZZ]

nanusecure,

You should start a new thread for your post since it is a new subject not related to the current thread.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm