By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,621 Members | 1,178 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,621 IT Pros & Developers. It's quick & easy.

Variable scope in nested classes - can't get to my variable

P: n/a
in VB.NET I'm trying to access my variable without resorting to SHARED
scope.
Here's the situation: class MYLABEL inherits LABEL and has an additional
property called MYVAR. In MYLABEL I set an ADDHANDLER for ME.MOUSEDOWN event
to ME.MYHANDLER. PRIVATE SUB MYHANDLER (part of the MYLABEL class)
creates
a new context menu at runtime and does an ADDHANDLER for the context menu
item CLICK event to MYSUB. PUBLIC SUB MYSUB then creates an instance of a
new form (MYFORM) and does a MYFORM.SHOWDIALOG. In the MYFORM class I have
a button and in that buttons click event I need to access the variable MYVAR
(which is a property in the MYLABEL class).

Now, I know this description sounds complicated but it's not really. Here's
what happens. The user right clicks on a label and a context menu appears.
User clicks on a context menu choice which causes a new form (MYFORM) to
appear. Within the MYFORM the user enters data into a textbox, hits SAVE
button and that info needs to be transfered into the MYVAR variable (which
is
a property of MYLABEL).

My problem is that I can't get to the MYVAR variable. If it were two forms
I'd just pass a formname as a parameter to a procedure call , but because
there's a mousedown event in the middle (which has a specific signature for
parameters), I'm at a loss as to how to do this. Any help greatly
appreciated.
Nov 21 '05 #1
Share this Question
Share on Google+
5 Replies

P: n/a
You forgot to mention the scope of your MyVar property currently , what is
it: public, private, protected, etc...?

"JohnR" wrote:
in VB.NET I'm trying to access my variable without resorting to SHARED
scope.
Here's the situation: class MYLABEL inherits LABEL and has an additional
property called MYVAR. In MYLABEL I set an ADDHANDLER for ME.MOUSEDOWN event
to ME.MYHANDLER. PRIVATE SUB MYHANDLER (part of the MYLABEL class)
creates
a new context menu at runtime and does an ADDHANDLER for the context menu
item CLICK event to MYSUB. PUBLIC SUB MYSUB then creates an instance of a
new form (MYFORM) and does a MYFORM.SHOWDIALOG. In the MYFORM class I have
a button and in that buttons click event I need to access the variable MYVAR
(which is a property in the MYLABEL class).

Now, I know this description sounds complicated but it's not really. Here's
what happens. The user right clicks on a label and a context menu appears.
User clicks on a context menu choice which causes a new form (MYFORM) to
appear. Within the MYFORM the user enters data into a textbox, hits SAVE
button and that info needs to be transfered into the MYVAR variable (which
is
a property of MYLABEL).

My problem is that I can't get to the MYVAR variable. If it were two forms
I'd just pass a formname as a parameter to a procedure call , but because
there's a mousedown event in the middle (which has a specific signature for
parameters), I'm at a loss as to how to do this. Any help greatly
appreciated.

Nov 21 '05 #2

P: n/a
John,

I found it with user controls always difficult to see how the user made it.
Can you describe that a little bit, because in my opinion is the problem to
get to that MYVAR variable in that userControl MYLABEL.

To be more precise in my question, did you directly inherited "Label" or did
you drag a label on a usercontrol?

Cor
Nov 21 '05 #3

P: n/a
Here's a summary of the code:

public class MYCLASS
inherits label
private MYVAR
addhandler me.MOUSEDOWN, addressof ME.MYHANDLER

private sub MYHANDLER(takes the parametes of mouseeventargs, so I can't
pass MYVAR as a param... any way around that?)
--creates context menu at runtime which when clicked on calls MYSUB

public sub MYSUB
--creates runtime instance of a form MYFORM
MYFORM.SHOW

The MYFORM form has a button, and in that buttons click event, I need to
access MYVAR
Additional info:
I originally had the MYFORM class defn in a different .vb file. When I
created a wrapper module and stuck everything in there, and moved MYVAR
outside of the procs with a FRIEND MYVAR AS STRING then I succeeded in
accessing the variable. However when it's in the wrapper module, the
windows designer doesn't see the MYFORM as something it can edit. So it
looks like I need to move the MYFORM code to a seperate file when I want to
edit it in windows designer, then move it back to the wrapper module when it
runs... Any other suggestions as to how to do this better?
Nov 21 '05 #4

P: n/a
Declare MyVar as public in your class.

"JohnR" wrote:
Here's a summary of the code:

public class MYCLASS
inherits label
private MYVAR
addhandler me.MOUSEDOWN, addressof ME.MYHANDLER

private sub MYHANDLER(takes the parametes of mouseeventargs, so I can't
pass MYVAR as a param... any way around that?)
--creates context menu at runtime which when clicked on calls MYSUB

public sub MYSUB
--creates runtime instance of a form MYFORM
MYFORM.SHOW

The MYFORM form has a button, and in that buttons click event, I need to
access MYVAR
Additional info:
I originally had the MYFORM class defn in a different .vb file. When I
created a wrapper module and stuck everything in there, and moved MYVAR
outside of the procs with a FRIEND MYVAR AS STRING then I succeeded in
accessing the variable. However when it's in the wrapper module, the
windows designer doesn't see the MYFORM as something it can edit. So it
looks like I need to move the MYFORM code to a seperate file when I want to
edit it in windows designer, then move it back to the wrapper module when it
runs... Any other suggestions as to how to do this better?

Nov 21 '05 #5

P: n/a
Thanks for the quick reply...

I did think about declaring MYVAR as public, but on a "elegance" level I
hate declaring vars as public... it was always drilled into me that in
writing bulletproof code you aways strive for the smallest variable scope
possible, using public or global vars only when absolutely required. On a
more realistic level, I'm going to be having lots of instances of MYCLASS
floating around (possibly around 20-30) at the same time, so if I declare it
as public, won't the MYVAR variables be stepping on each other?

I guess the bottom line is that the "real" way to see MYVAR is to pass it
along as a parameter. So given the fact that one of the links in the chain
of procedures that are being called is a MouseDown event (which has a
predefined set of parameters), the question becomes this: Is there any way
to modify the parameter signature of the MouseDown event. Is there some
kind of re-definition or inheritance that you can use on a mouse event
(similar to the way you can inherit and extend any other control class)?
"Alien2_51" <da***************@monacocoach.removeme.com> wrote in message
news:2B**********************************@microsof t.com...
Declare MyVar as public in your class.

"JohnR" wrote:
Here's a summary of the code:

public class MYCLASS
inherits label
private MYVAR
addhandler me.MOUSEDOWN, addressof ME.MYHANDLER

private sub MYHANDLER(takes the parametes of mouseeventargs, so I
can't
pass MYVAR as a param... any way around that?)
--creates context menu at runtime which when clicked on calls
MYSUB

public sub MYSUB
--creates runtime instance of a form MYFORM
MYFORM.SHOW

The MYFORM form has a button, and in that buttons click event, I need to
access MYVAR
Additional info:
I originally had the MYFORM class defn in a different .vb file. When I
created a wrapper module and stuck everything in there, and moved MYVAR
outside of the procs with a FRIEND MYVAR AS STRING then I succeeded in
accessing the variable. However when it's in the wrapper module, the
windows designer doesn't see the MYFORM as something it can edit. So it
looks like I need to move the MYFORM code to a seperate file when I want
to
edit it in windows designer, then move it back to the wrapper module when
it
runs... Any other suggestions as to how to do this better?

Nov 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.