Invoking a Button_Click() event from a seperate form
-
This is a bad idea. The function you're calling, since it's used by BOTH forms, should be moved to a seperate class as a, possibly, shared method. You will, of course, have to supply this new method, through the method parameters, with the data it needs to do its job.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave Kreskowiak wrote:
This is a bad idea. The function you're calling, since it's used by BOTH forms
I agree. It would open a can of worms for debugging headaches...
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
-
if formA is the one that created formB: - formA needs to pass over a delegate to formB so that B can call back to A. - another method, however not a good one, is for A to pass over a pointer of itself to B then B can call this routine (routine must be changed to public for this to work).
-
Hi, I have two seperate forms. Lets just call them FormA and FormB. I have a function in FormA called Button_Click(). How would I (while in FormB) call this function? I have tried, while in the FormB code, using Form_FormA.Button_Click. But that doesn't seem to work. Can anyone help me with this?
-
FormA.Button.PerformClick
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
That only works if FormB has a reference to the existing FormA object and that reference is called FormA. Not a good idea.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
That only works if FormB has a reference to the existing FormA object and that reference is called FormA. Not a good idea.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Dave, It sure sounded like the 2 forms are part of a single project. If they are, then each has a reference to the other in My.Forms.
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
TomGarth wrote:
If they are, then each has a reference to the other in My.Forms.
I never use it and never will. It's just too VB6'ish to me. I'd rather they did it the correct way then work around it and learn a bad habit they can't transfer to another language.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
TomGarth wrote:
If they are, then each has a reference to the other in My.Forms.
I never use it and never will. It's just too VB6'ish to me. I'd rather they did it the correct way then work around it and learn a bad habit they can't transfer to another language.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Maybe I don't understand what you're saying. Manipulating forms from other forms in a single application is perfectly normal, and not a bad habit. If you have 2 forms in your application and 1 is open, how much code do you write to open the other one?
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
-
Maybe I don't understand what you're saying. Manipulating forms from other forms in a single application is perfectly normal, and not a bad habit. If you have 2 forms in your application and 1 is open, how much code do you write to open the other one?
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
It's not having one form open another that's the problem. It's having one form manipulate the controls of another that violates the rules of encapsulation.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
It's not having one form open another that's the problem. It's having one form manipulate the controls of another that violates the rules of encapsulation.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
It's not having one form open another that's the problem. It's having one form manipulate the controls of another that violates the rules of encapsulation.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
You say Bad Habit, I say RAD!!! ...and VB6 rocks, and so did VB5, 4, 3, etc.
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
TomGarth wrote:
You say Bad Habit, I say RAD!!!
I say unsupportable...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
just for my education... in your shared method or method within a class idea... if the click routine only contains data/controls that are within formA. is a delegate the answer or do you have another technique?
If I read this correctly... If the click handler only does some kind of setup for the form itself, then yes, I'd use a delegate to make the call. But, I've never sen the need to have a child dialog, or any other form, tell another form how to set itself up. I've always used a shared state object and/or events fired by the data model to tell the subscribers that they might want to adapt to a change in the data.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
If I read this correctly... If the click handler only does some kind of setup for the form itself, then yes, I'd use a delegate to make the call. But, I've never sen the need to have a child dialog, or any other form, tell another form how to set itself up. I've always used a shared state object and/or events fired by the data model to tell the subscribers that they might want to adapt to a change in the data.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007the only situation I can think of is when formB is a modal form and it's answer will dictate what formA will do... dim oFrm as formB If oFrm.showdialog() = DialogResult.OK Then 'change the state of formA . . . if they are independent of each other then I would agree...
-
You say Bad Habit, I say RAD!!! ...and VB6 rocks, and so did VB5, 4, 3, etc.
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
-
TomGarth wrote:
VB6 rocks, and so did VB5, 4, 3
Oh, I soooo hope you are being sarcastic.
_____________________________________________ Flea Market! It's just like...it's just like...A MINI-MALL!
I hope he is being sarcastic. Needs to put the [sarcasm] ... [/sarcasm[ tags around it, if he is.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
-
the only situation I can think of is when formB is a modal form and it's answer will dictate what formA will do... dim oFrm as formB If oFrm.showdialog() = DialogResult.OK Then 'change the state of formA . . . if they are independent of each other then I would agree...
nlarson11 wrote:
when formB is a modal form and it's answer will dictate what formA will do...
Then FormB exposes it's status as properties. FormA then decides what it's going to do with that data and alters its own user interface accordingly. FormB should never know anything about the form that launched it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
You say Bad Habit, I say RAD!!! ...and VB6 rocks, and so did VB5, 4, 3, etc.
Tom Garth Developer R. L. Nelson and Associates, Inc., Virginia
TomGarth wrote:
...and VB6 rocks, and so did VB5, 4, 3, etc.
I sure hope your high on something. It's the only explanation for a statement like that.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
nlarson11 wrote:
when formB is a modal form and it's answer will dictate what formA will do...
Then FormB exposes it's status as properties. FormA then decides what it's going to do with that data and alters its own user interface accordingly. FormB should never know anything about the form that launched it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007I think we missed/missing each other's points. if i'm in formA and I create and instance of formB, I have 2 options of displaying formB... SHOW and SHOWDIALOG if i use SHOW then you are correct, formB shouldn't need to know anything about A but if it does, use a delegate. if I use SHOWDIALOG that A is waiting for B to respond with the user's choice of pressing OK or Cancel or whatever choices remain in the enum dialogresult. So B will return the answer and A reacts accordingly. No different then an OK/Cancel messagebox. I personally have no issue with A reacting to B in this situation...
-
I think we missed/missing each other's points. if i'm in formA and I create and instance of formB, I have 2 options of displaying formB... SHOW and SHOWDIALOG if i use SHOW then you are correct, formB shouldn't need to know anything about A but if it does, use a delegate. if I use SHOWDIALOG that A is waiting for B to respond with the user's choice of pressing OK or Cancel or whatever choices remain in the enum dialogresult. So B will return the answer and A reacts accordingly. No different then an OK/Cancel messagebox. I personally have no issue with A reacting to B in this situation...
Whoops! Sorry, I misread your previous post. We're both on the same page!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Whoops! Sorry, I misread your previous post. We're both on the same page!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007