Mandy
you will need to pass a reference of the parent form to the child form when the child form is created

EG on the child form create a property called oCallingForm
when you create the child(popup) form you need to set the
do form (???) with this
("this" is therefore a parameter object pass to the child form

In the Child form's Init you need to have a parameters line - one of these will then receive the reference to the passed form and set oCallingform on the child form

Then anywhere in the child form you can reference anything (property or method) on the parent form by using the oCallingForm property of the child form to preface it

so somewhere in your child form , you can issue oCallingForm.refresh() - or oCallingForm.RunMyMethod() or get values from the parentform in a similar manner


Sorry if this sounds convoluted - that's because it is, but once you get your head around pasing references it becomes quite simple and Very powerful. perhaps others on here may be better at explaning than I am !

Colin

Mandy,

Colin has given you one method of getting a reference to the calling form. There is also another approach.

In the child form, create the custom oCallingForm property, as per Colin's suggestion. Then in the Load event of the child form, do this:

THISFORM.oCallingForm = _SCREEN.ActiveForm

From that point on, the child form will have access to all the properties and methods of the calling form. So, for example, if the calling form has a button named cmdPaste, and you want to run the code in that button's Click event from within the child form, you could do this:

THISFORM.oCallingForm.cmdPaste.Click

The point is that, when the Load event of a child form executes, the calling form is still the active form. So you can always get an object reference to it, without having to pass a parameter.

I'm not saying that this method is necessarily better than Colin's suggestion. It just a different way of achieving the same goal.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Mike, great idea

Thanks to both of you!!! Colin and Mike... MAGIC!! Thank you thank you thank you... i read your instruction many times, and after sometime it worked!!! Thank you so much again... you are so generous... Godbless you...

Because I used such dated UI, I generally know the name of the calling form.

Thus for an frmAddContract the parent would be frmContracts and I used this
kind of code to invoke code on it:


** Correction pasted below **

Regards

Griff
Keep ing

Mandy,

Mike and Colin have answered your question "as asked"...... but it's probably worth adding that that is not a great way of doing things. At some point in the future someone may be working on the parent form and decide to change the button's name or move it onto one the pageframe tabs or whatever and not know about the other form referencing that button.

Better to move the code out of the button's click event and put it into it's own method on the form itself. Then have the button's click event call

thisform.transactcode()

or whatever you call it and the other form call

thisform.ocallingform.transactcode()



hth

n

Quote (Nigel)

At some point in the future someone may be working on the parent form and decide to change the button's name or move it onto one the pageframe tabs or whatever and not know about the other form referencing that button.

Of course, you are right, Nigel. As you said, I just answered the question "as asked", which isn't always the best thing to do.

Quote (Griff)

CODE -->

IF TYPE("CONTRACTS.GRID1") = "O"
	CONTRACTS.SENDINDUCTIONMAIL.CLICK()
ENDIF 

But if the form is called frmContracts, shouldn't you be testing for TYPE("frmContracts.GRID1"), and executing frmContract.SENDINDUCTIONMAIL.CLICK()? Or have I misunderstood? And what if the object reference to frmContracts is out of scope when executing this code?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Doh! What can I say...


Sun must be getting to me

The frmCONTRACTS scope had never occurred to me, it has always been in scope, but if it were not the .click() on the button (sendInductionEmail)
would not happen, well spotted.

Regards

Griff
Keep ing

There is a forum 'etiquette' question Mike; should I have corrected my original post, and thus perhaps made you alter yours or it would look odd, or is posting a new item with
the code amended more or less correct?

Regards

Griff
Keep ing

That's a good question, Griff. I have struggled with it myself.

If you just correct the original post without any further comment, it would make the subsequent posts (the ones drawing attention to the issue and suggesting a correction) look odd - and could be confusing as well. You could then ask the person who posted the subsequent posts to edit or remove them. But that would be complicated, and would rely on that person actually seeing that request in a timely manner.

If you leave the original post as is, but acknowledge the issue and perhaps post the corrected version in a later post (as you did this time, Griff), then anyone who sees the original post without bothering to look further will receive incorrect information.

Maybe the answer is to add a note to the original post, saying something like: "UPDATE: See correction below".

I don't know. What do other folk think?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Mike, i like your suggestion of adding an update note, and referencing a correction.

Seconded, and done, sorry for hijacking the thread.

Regards

Griff
Keep ing

Thanks Nigel and Griff...

Nigel i'll try to study and do what you have suggested... sounds good to me too... thanks again..