Calls between windows

I have the need to trigger some events in windows which don't have focus
and am not seeing any good way to accomplish this.

The scenario is that if specific window is opened and a process started
in that window, I need another window to know that the process is
running and configure itself accordingly.

I know I can use public variables, but they don't "trigger" an event
such as a form refresh.

I've tinkered with it, and it also does not seem possible for one form
to run an event in another window... for example, if form1 could run a
form2.refresh that would be a start.

Any wisdom appreciated.

Thanks in advance,
Beverly Howard

Dan
Wed Dec 26 10:30:00 CST 2007

Can I read "Window" as VFP form in the currently running exe? <s>

(If it's external to your app, look at SendKeys() in WSH.)

Any form can *certainly* make method calls on any other form. The trick is
in getting the object reference. (**NOT** the form name!) This command:

DO FORM YourForm NAME Fred LINKED

would create an object pointer (variable) named Fred. Any object having the
same scope as Fred can call methods of Fred thusly:

Fred.Refresh()

These object reference variables are exactly like character (etc.) memory
variables, and follow the same scoping rules.

A little more robust method is to have a form manager. These days they can
be based on the Collection base class. Your top-most level form class would
contain code so that each form "announces itself" to the collection, and the
collection stores a reference to the calling form, and on release your forms
say farewell to the form manager so it knows to release the reference. This
avoids some of the icky scope problems with forms starting and releasing at
different levels of your code, and gives you a central location to "find"
your form references. It's a little more work to set up, but can save a ton
of time later because you're designing interoperability into your framework.

Cook's choice, as usual. <s>

Dan


Beverly Howard [Ms-MVP/MobileDev] wrote:
> I have the need to trigger some events in windows which don't have
> focus and am not seeing any good way to accomplish this.
>
> The scenario is that if specific window is opened and a process
> started in that window, I need another window to know that the
> process is running and configure itself accordingly.
>
> I know I can use public variables, but they don't "trigger" an event
> such as a form refresh.
>
> I've tinkered with it, and it also does not seem possible for one form
> to run an event in another window... for example, if form1 could run a
> form2.refresh that would be a start.
>
> Any wisdom appreciated.
>
> Thanks in advance,
> Beverly Howard

Gregory
Wed Dec 26 10:58:24 CST 2007

Could this help ?
http://groups.google.com/group/microsoft.public.fox.programmer.exchange/browse_thread/thread/d37f8439d32abbf0/aef9e14fb625628e?lnk=st&q=gregory+fox+adam+form+beverly+do+_screen#aef9e14fb625628e

Gregory
_
"Beverly Howard [Ms-MVP/MobileDev]" <BevNoSpamBevHoward.com> wrote in
message news:OmPcVo9RIHA.5360@TK2MSFTNGP03.phx.gbl...
>I have the need to trigger some events in windows which don't have focus
>and am not seeing any good way to accomplish this.
>
> The scenario is that if specific window is opened and a process started in
> that window, I need another window to know that the process is running and
> configure itself accordingly.
>
> I know I can use public variables, but they don't "trigger" an event such
> as a form refresh.
>
> I've tinkered with it, and it also does not seem possible for one form to
> run an event in another window... for example, if form1 could run a
> form2.refresh that would be a start.
>
> Any wisdom appreciated.
>
> Thanks in advance,
> Beverly Howard

Beverly
Wed Dec 26 11:17:42 CST 2007

>> DO FORM YourForm NAME Fred LINKED <<

Thanks Dan... I think the above is what I was looking for.

The other thought that occurs is to put the trigger in the form getfocus
event, but, if I can make the above work, that looks like a better approach.

If I follow what you are saying, what I will do is to modify all the
existing DO FORM... statements to the above syntax?

If so, any thoughts on using the form property "name" as the NAME? i.e.
is that going to create any conflict down the line?

thanks again,
Beverly Howard

Beverly
Wed Dec 26 11:32:51 CST 2007

>>
http://groups.google.com/group/microsoft.public.fox.programmer.exchange/browse_thread/thread/d37f8439d32abbf0/aef9e14fb625628e?lnk=st&q=gregory+fox+adam+form+beverly+do+_screen#aef9e14fb625628e
<<

I remember those headaches ;-)

That thread was very helpful in getting a handle on using public
variables between forms and revisiting now shows I missed method
references...

More accurately, my mindset then was on looking at variable values to
make decisions where, now, allowing the user to switch between windows
brings up the need to run processes before the fact so what when the
window gets focus false assumptions are not in place.

Thanks,
Beverly Howard

Dan
Wed Dec 26 11:45:09 CST 2007

Beverly Howard [Ms-MVP/MobileDev] wrote:
>>> DO FORM YourForm NAME Fred LINKED <<
>
> Thanks Dan... I think the above is what I was looking for.
>
> The other thought that occurs is to put the trigger in the form
> getfocus event, but, if I can make the above work, that looks like a
> better approach.
> If I follow what you are saying, what I will do is to modify all the
> existing DO FORM... statements to the above syntax?

Yup! That's the ticket!

> If so, any thoughts on using the form property "name" as the NAME?
> i.e. is that going to create any conflict down the line?

No conflict at all... so long as each name property is unique. Remember that
the default name property is "Form1" (or "Form2", etc.) unless you've
changed it.

But I'm curious how you'd use it in the DO FORM call? The form instance
doesn't exist yet so there's no way to refer to it. <g>

Dan

Beverly
Wed Dec 26 12:22:22 CST 2007

>> But I'm curious how you'd use it in the DO FORM call? The form
instance doesn't exist yet so there's no way to refer to it. <g> <<

this is coming up in an IF wexist... context to set the form contents up
before activating the window... i.e. so it knows that it's going to be
dealing with a specific order# which has already been created by an
action in another window.

...the LINKED is also proving interesting... for some reason when I DO a
form as LINKED, it's altering some of it's properties... for example,
for some reason, the user can't exit or destroy it... at least I figured
out why it was auto closing on my first attempts ;-)

...back to the books.

Thanks,
Beverly Howard