|
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).
|
|
|
|
|
Thanks, I'll give it a shot
|
|
|
|
|
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.
|
|
|
|
|
Dave 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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
good. i normally agree with you 100% 
|
|
|
|
|
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...
|
|
|
|
|
Is there any way to run the application developed in VB.net 2005 on Linux or Mac OS . I have heard that there are some wrapper applications which make it possible. Any one who has done this or tried for this ?
Regards
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
