Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Communicating between forms

0 views
Skip to first unread message

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 16, 2007, 5:26:21 PM8/16/07
to
Since having multiple sessions going at once is new to me, I'm looking
for references on the best way to pass information between forms?

For example, if a form in the background has a selected value in a
private data session field and I am in a different form and want to use
that value in the focused form, how do I reference that value?

Thanks in advance.
Beverly Howard

Dan Freeman

unread,
Aug 16, 2007, 6:04:45 PM8/16/07
to
If the 2nd form doesn't *need* a private data session, leave it set to the
default session. It will, instead, share the calling form's.

You can also send forms a parameter (DO FORM Whatever WITH lcValue), which
is received in the called form's INIT method. Store it in a property of the
called form.

If you have an object reference to the calling form, you can query
properties of that form object. I've been known to bring that about this
way:

Do Form Whatever With Thisform

Dan

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 17, 2007, 2:33:51 PM8/17/07
to
each form has it's own dataset... for example, the customer screen to
find, edit/update the customer, then the order screen which I simply
want to fill the customer# (pointing to a related database) with the
customer number currently showing on the customer form.

At this point, assume that using public objects might be the best way to
do this on the assumption that they will be updated in the other forms
when they are repopulated in the source form.

On the

DO FORM Whatever WITH lcValue

...don't think will work with what I am attempting since both forms will
already be open so the user can switch back and forth to select/reslect
and fill the value into the other.

Back to the experimentation worktop ;-)

Beverly Howard

Jack Jackson

unread,
Aug 17, 2007, 3:25:09 PM8/17/07
to

At what point to you want the order screen to change? Any time a new
customer is selected on the Customer screen? If so, then I would do
something like:

Have a PUBLIC object with properties for all of the items (like
customer number) that need to be communicated between forms. In that
object have methods to set each of the properties.

Whenever a form (like Customer) needs to change the 'current' customer
number, it calls the SetCustomer method in the public object. That
method stores the new customer number and then loops through all of
the forms (Screen.Forms), and any that have a specific method, say
ChangeCustomer, call that method to let the forms that care know that
the customer number has changed.

When a form opens that cares about the customer number, in its Load or
Init event it would get the current customer number from the public
object.

Another approach is to have the forms that care about each property
register with the public object. The public object would keep a list
of forms that want to be notified about each item.

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 17, 2007, 4:10:49 PM8/17/07
to
my brain is beginning to hurt ;-/

>> At what point to you want the order screen to change? Any time a new
customer is selected on the Customer screen? If so, then I would do
something like: <<

Nothing will happen automatically... the user will need to take an
action in one form to retrieve the info from the other.... for example,
right click on the customer number field to insert the number from the
current customer record... going to run some experiments and be back.

Thanks for the inputs.

Beverly Howard

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 17, 2007, 4:58:58 PM8/17/07
to
Thanks for the inputs...

Am achieving what I need via a public object carrying a value from one
form to the next...

...but, that exposed the fact that the data sessions are not as I
expected... relationship in one form is impacting the data display in
the first form... the learning continues.

Beverly Howard

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 17, 2007, 5:06:33 PM8/17/07
to
think i see it... form/properties/datasession...

...breaktime

Beverly Howard

Dan Freeman

unread,
Aug 17, 2007, 5:16:51 PM8/17/07
to
I can almost see the sweat on your brow from here. <g>

Dan

Gregory Adam

unread,
Aug 18, 2007, 8:06:13 AM8/18/07
to

>
> DO FORM Whatever WITH lcValue
>
> ...don't think will work with what I am attempting since both forms will
> already be open so the user can switch back and forth to select/reslect
> and fill the value into the other.
>

Beverly,

Add a method to the form - like OrderChange(CustNumber)
The other form can go through the screen's forms collection, find the form
there based on it having a method (see Pemstatus)
If the form is not there - it could launch it. If the form is already there
then it would just call the method - ie =FormObj.OrderChange(...)

Here's a function I use to find an instantiated form based on the caption -
which you can change

function Form_get_caption(_Caption)

_Caption = lower(m._Caption)

local obj
for each obj in _screen.Forms
do case
case type('m.obj.WindowType') == T_UNDEFINED

case at(m._Caption, lower(m.obj.Caption)) = 1

return m.obj
endcase

endfor
return null
endfunc

Here's one based on the Name of the form
#define TRUE .t.
#define FALSE .f.

eg find form Beverly

local obj

if( Form_get_name(@m.obj, 'Beverly') )
=m.obj.Customer_Change(123)
endif


function Form_get_name(obj, FormName)

local Success
Success = FALSE

FormName = lower(m.FormName)

for each obj in _screen.Forms
do case
case type('m.obj.WindowType') == T_UNDEFINED

case lower(m.obj.Name) == m.FormName
Success = TRUE
exit
endcase

endfor

do case
case m.Success

otherwise
obj = null

endcase

return m.Success

endfunc


Gregory
_

Bernhard Sander

unread,
Aug 18, 2007, 10:03:36 AM8/18/07
to
Hi Beverly,

> >> At what point to you want the order screen to change? Any time a new
> customer is selected on the Customer screen? If so, then I would do
> something like: <<
>
> Nothing will happen automatically... the user will need to take an
> action in one form to retrieve the info from the other.... for example,
> right click on the customer number field to insert the number from the
> current customer record... going to run some experiments and be back.

If you ever have heard of design pattern: one solution for the communication
between forms would be the mediator pattern. In effect, it is close to what Jack
suggests.

Regards
Bernhard Sander

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 18, 2007, 1:25:48 PM8/18/07
to
>> good suggestions <<
>> code samples <<

ahhhhhhhhhhh.... the headache is abating

Thanks all... still learning and progressing.

Beverly Howard

Gene Wirchenko

unread,
Aug 19, 2007, 2:31:43 AM8/19/07
to
"Beverly Howard [Ms-MVP/MobileDev]" <BevNoSpamBevHoward.com> wrote:

> >> good suggestions <<
> >> code samples <<
>
>ahhhhhhhhhhh.... the headache is abating

Not to worry. There will be others. <BEG>

>Thanks all... still learning and progressing.

I am still learning, too. One problem is sometimes it feels as
if the "still" means not moving.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 19, 2007, 11:52:08 AM8/19/07
to
>> Still <<

Ouch! That hurt! ;-)

Beverly Howard


Beverly Howard [Ms-MVP/MobileDev]

unread,
Aug 19, 2007, 11:52:58 AM8/19/07
to
Thanks... very valuable and at a time when (I think) I can absorb it.

Thanks,
Beverly Howard

Gregory Adam

unread,
Aug 19, 2007, 1:11:02 PM8/19/07
to
"Beverly Howard [Ms-MVP/MobileDev]" <BevNoSpamBevHoward.com> wrote in
message news:%23hkqEkn...@TK2MSFTNGP03.phx.gbl...

> Thanks... very valuable and at a time when (I think) I can absorb it.
>
> Thanks,
> Beverly Howard


I would stay away from public variables if I could

Gregory
_

Eric Selje

unread,
Aug 21, 2007, 8:21:44 PM8/21/07
to
Well, you need one public variable, which is your application object.
One property of your application object should be a forms manager, which
implements the mediator object as mentioned.

Wanting a forms manager is a good reason to start all apps from a framework.

HTH,
Eric

Rush Strong

unread,
Aug 21, 2007, 10:51:52 PM8/21/07
to
Not to be picky, but that public variable could be scoped as private to
your calling program. Still visible to all subordinates, but goes away
when the program dies.

- Rush

Salty Dog

unread,
Sep 8, 2007, 9:44:30 AM9/8/07
to
On Aug 21, 9:51 pm, Rush Strong <rpstr...@gmail.com> wrote:
> Not to be picky, but that public variable could be scoped as private to
> your calling program. Still visible to all subordinates, but goes away
> when the program dies.
>
> - Rush

To continue on the picky theme, PRIVATE isn't really a scope, so if
it's private, but in the top-level, it's essentially PUBLIC (though
you're right, it sticks around if you don't explicity release it or
quit VFP).

Rush Strong

unread,
Sep 8, 2007, 1:50:33 PM9/8/07
to
Damn, I've been out picked.

[Shades of Deliverance?]

 - Rush
0 new messages