Invoking a Button_Click() event from a seperate form
-
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 -
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?
Hi, this is a way that you can use if you are calling formB from formA, if not you can use the Sub Main to keep active forms references. In FormB Private m_f As FormA Public Sub New(f as FormA) m_f = f MyBase.New End Sub ... Call m_f.TheMethod In FormA ...ButtonX.Click Call TheMethod End Sub Public Sub TheMethod ... End Sub ... dim f as New FromB(Me) f.Show Hope this helps! NajiCo http://www.InsideVB.NET[^]
It's nice 2b important, but it's more important 2b nice...