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

Shared Method Problem With "Global" Storage

P: n/a
I have this nasty problem with Shared methods and what I think of as "global
storage" - i.e. storage declared outside of any subroutines or functions.
In the simple example below this "global" storage is ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results in
the error reflected in the comment. I don't see any ambiguity in what I am
trying to do. I suspect there is some syntatic solution but I have been
unable to find it.

Thanks much for whatever solution and/or understanding you can provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean

#Region " Windows Form Designer generated code "
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub

Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance member
of a class from within a shared method or shared member initializer without
an explicit instance of the class.

'do one thing
Else 'do something else
End If

End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
CalculateSomething()

If ButtonHasBeenClicked Then
'do something here; no problem referencing ButtonHasBeenClicked
here
End If
End Sub

End Class

Module Module1
Public Sub CalculateSomething()
Form1.WhatEver()
End Sub
End Module
Oct 19 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"eBob.com" <eB******@totallybogus.comschrieb
I have this nasty problem with Shared methods and what I think of as
"global storage" - i.e. storage declared outside of any subroutines
or functions.
It's called a "field".
In the simple example below this "global" storage is
ButtonHasBeenClicked. In this simple example code in Form1 calls a
routine in Module1 which then calls code back in Form1 (subroutine
WhatEver). WhatEver needs to access ButtonHasBeenClicked but the
reference to ButtonHasBeenClicked results in the error reflected in
the comment. I don't see any ambiguity in what I am trying to do. I
suspect there is some syntatic solution but I have been unable to
find it.

Thanks much for whatever solution and/or understanding you can
provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean

If it is not Shared, every instance of the Form has it's own value in this
field.

Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance
member of a class from within a shared method or shared member
initializer without an explicit instance of the class.

In a shared Sub, you can not access an instance field withouth having a
reference to the object. The field of which instance do you want to access?
Or maybe not even one instance has been created. Therefore this fails. Don't
declare the Sub as Shared.

'do one thing
Else 'do something else
End If

End Sub
Module Module1
Public Sub CalculateSomething()
Form1.WhatEver()
End Sub
End Module
If you wanted to access a Form in a Module, you would have to pass the Form
to the procedure. It is better not to access the Form in a Module. Why don't
you put the code into the Form? If the code in the Module is to be reused,
make an abstract definition of the procedure's purpose, pass in and out the
data needed, and call it from the Form.
Armin

Oct 19 '07 #2

P: n/a
On Oct 19, 11:01 am, "eBob.com" <eBob....@totallybogus.comwrote:
I have this nasty problem with Shared methods and what I think of as "global
storage" - i.e. storage declared outside of any subroutines or functions.
In the simple example below this "global" storage is ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results in
the error reflected in the comment. I don't see any ambiguity in what I am
trying to do. I suspect there is some syntatic solution but I have been
unable to find it.

Thanks much for whatever solution and/or understanding you can provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean

#Region " Windows Form Designer generated code "
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub

Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance member
of a class from within a shared method or shared member initializer without
an explicit instance of the class.
The error message means EXACTLY what it says. You are trying to refer
to an instance variable - a variable that is associated with a
specific instance of a class, in a shared method. A shared method is
NOT associated with any particular instance of a class. It is
associated with the class itself. VB sort of hides this distinction
with it's dubious feature of allowing you to call shared methods via
instance variables (an honor that C# will share as of version 3.0).

Anyway, what all of the above means is that you can not access
ButtonHasBeenClicked in the manner you are attempting, since a shared
method has NO knowledge of which version of ButtonHasBeenClicked to
reference...

What this means is that you need to:

1) declare ButtonHasBeenClicked as shared, which means if you have
multiple instances of your form - all of them will share the same
ButtonHasBeenClicked, which is probably not what you want.

2) Remove the shared modifier from the sub, so that it is a member
method (this means that there is an implicit Me reference passed to
the sub/function - which means you can then refer to the
ButtonHasBeenClicked variable as your doing now.

3) Keep your sub/function shared, but make it take a parameter that
specifies the instance you are interested in: sub somesub (byval
theForm as myform). Then you can use that instance variable to get a
hold of ButtonHasBeenClicked.

Personally, I would probably use #2 if this sub/function has no
utility beyond your specific form. And don't think that this will
cause multiple versions of the funciton/sub to be in memory at once
(I've seen people concerned by this before) - because it won't. All
instances of the class still call the same code, but the compiler adds
a additional parameter to the funciton sub, that takes the
instance....

Anyway, HTH

--
Tom Shelton

Oct 19 '07 #3

P: n/a
Hi Armin, Thanks for your response. Please see my further question below
interspersed with the code and your comments ...

----- Original Message -----
From: "Armin Zingler" <az*******@freenet.de>
Newsgroups: microsoft.public.dotnet.languages.vb
Sent: Friday, October 19, 2007 1:19 PM
Subject: Re: Shared Method Problem With "Global" Storage

"eBob.com" <eB******@totallybogus.comschrieb
>I have this nasty problem with Shared methods and what I think of as
"global storage" - i.e. storage declared outside of any subroutines
or functions.

It's called a "field".
>In the simple example below this "global" storage is
ButtonHasBeenClicked. In this simple example code in Form1 calls a
routine in Module1 which then calls code back in Form1 (subroutine
WhatEver). WhatEver needs to access ButtonHasBeenClicked but the
reference to ButtonHasBeenClicked results in the error reflected in
the comment. I don't see any ambiguity in what I am trying to do. I
suspect there is some syntatic solution but I have been unable to
find it.

Thanks much for whatever solution and/or understanding you can
provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean


If it is not Shared, every instance of the Form has it's own value in this
field.

> Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance
member of a class from within a shared method or shared member
initializer without an explicit instance of the class.


In a shared Sub, you can not access an instance field withouth having a
reference to the object. The field of which instance do you want to
access?
Or maybe not even one instance has been created. Therefore this fails.
Don't
declare the Sub as Shared.
But if I don't make WhatEver Shared then I can't call it from the Module1
code.

Two things probably contribute to my confusion in this area. 1) In the real
project I am working on
I am using Modules simply to keep the code more manageable. The application
is mining some web sites
and I use a different Module for each site. Code which is common to all
sites is in the Form1.vb code.
And 2) apparently there can be more than one Form1, but I see Form1 as being
associated with my running
application. It's the "topmost thing". It wouldn't make any sense, for the
(admitedly simple) applications I've written, to have
more than one.

What I don't get is that if I refer to ButtonHasBeenClicked in a subroutine
in the Form1.vb
code there is no question about which instance is being referenced. But
when I call (from the Form1.vb code) a subroutine
in a Module, .Net suddenly has no knowledge of what instance the code is
working on. I can
solve this problem by simply cutting and pasting the subroutine in the
Module to the Form1.vb code,
right? (But then my Form1.vb code would get unmanageably large.)

Part of my problem, I see now, is that I have misunderstood and am misusing
the Module concept. Right? But what do you do to
keep the size and organization of code files more manageable? I need some
way to segregate the code which is unique to mining web site A from the
code which is unique to mining web site B.

Sorry to be crying on your shoulder. What I know about VB.Net is
self-taught and there are major holes in my understanding.

Thanks, Bob
>
> 'do one thing
Else 'do something else
End If

End Sub

>Module Module1
Public Sub CalculateSomething()
Form1.WhatEver()
End Sub
End Module

If you wanted to access a Form in a Module, you would have to pass the
Form
to the procedure. It is better not to access the Form in a Module. Why
don't
you put the code into the Form? If the code in the Module is to be reused,
make an abstract definition of the procedure's purpose, pass in and out
the
data needed, and call it from the Form.
Armin

Oct 19 '07 #4

P: n/a
Hi Tom, Thanks very much for your response. Please see my further
questions below interspersed with your reply. Also, I hope you will look at
my
reply to Armin's response.

"Tom Shelton" <to*********@comcast.netwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...
On Oct 19, 11:01 am, "eBob.com" <eBob....@totallybogus.comwrote:
>I have this nasty problem with Shared methods and what I think of as
"global
storage" - i.e. storage declared outside of any subroutines or functions.
In the simple example below this "global" storage is
ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which
then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results in
the error reflected in the comment. I don't see any ambiguity in what I
am
trying to do. I suspect there is some syntatic solution but I have been
unable to find it.

Thanks much for whatever solution and/or understanding you can provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean

#Region " Windows Form Designer generated code "
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub

Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance
member
of a class from within a shared method or shared member initializer
without
an explicit instance of the class.

The error message means EXACTLY what it says. You are trying to refer
to an instance variable - a variable that is associated with a
specific instance of a class, in a shared method. A shared method is
NOT associated with any particular instance of a class. It is
associated with the class itself. VB sort of hides this distinction
with it's dubious feature of allowing you to call shared methods via
instance variables (an honor that C# will share as of version 3.0).

Anyway, what all of the above means is that you can not access
ButtonHasBeenClicked in the manner you are attempting, since a shared
method has NO knowledge of which version of ButtonHasBeenClicked to
reference...

What this means is that you need to:

1) declare ButtonHasBeenClicked as shared, which means if you have
multiple instances of your form - all of them will share the same
ButtonHasBeenClicked, which is probably not what you want.
In my heart of hearts I KNOW that there will only be one instance of the
Form1 class.
So actually his solution works. But I don't like the estethics of it. It
seems to be a serious
misuse of the intended use of Shared.
2) Remove the shared modifier from the sub, so that it is a member
method (this means that there is an implicit Me reference passed to
the sub/function - which means you can then refer to the
ButtonHasBeenClicked variable as your doing now.
But if I remove Shared from the subroutine then I can't call it from the
Module1 code.
>
3) Keep your sub/function shared, but make it take a parameter that
specifies the instance you are interested in: sub somesub (byval
theForm as myform). Then you can use that instance variable to get a
hold of ButtonHasBeenClicked.
I think that I will probably go this way. This problem will come up again
when I implement
my one and only message logger for my one and only Form1 application, so I
might as well
get used to it. Thanks again for your response. Bob

Personally, I would probably use #2 if this sub/function has no
utility beyond your specific form. And don't think that this will
cause multiple versions of the funciton/sub to be in memory at once
(I've seen people concerned by this before) - because it won't. All
instances of the class still call the same code, but the compiler adds
a additional parameter to the funciton sub, that takes the
instance....

Anyway, HTH

--
Tom Shelton

Oct 19 '07 #5

P: n/a
On Oct 19, 3:07 pm, "eBob.com" <eBob....@totallybogus.comwrote:
Hi Tom, Thanks very much for your response. Please see my further
questions below interspersed with your reply. Also, I hope you will look at
my
reply to Armin's response.

"Tom Shelton" <tom_shel...@comcast.netwrote in message

news:11**********************@k35g2000prh.googlegr oups.com...
On Oct 19, 11:01 am, "eBob.com" <eBob....@totallybogus.comwrote:
I have this nasty problem with Shared methods and what I think of as
"global
storage" - i.e. storage declared outside of any subroutines or functions.
In the simple example below this "global" storage is
ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which
then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results in
the error reflected in the comment. I don't see any ambiguity in what I
am
trying to do. I suspect there is some syntatic solution but I have been
unable to find it.
Thanks much for whatever solution and/or understanding you can provide.
Bob
Public Class Form1
Inherits System.Windows.Forms.Form
Dim ButtonHasBeenClicked As Boolean
#Region " Windows Form Designer generated code "
#End Region
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub
Public Shared Sub WhatEver()
If ButtonHasBeenClicked Then ' Cannot refer to an instance
member
of a class from within a shared method or shared member initializer
without
an explicit instance of the class.
The error message means EXACTLY what it says. You are trying to refer
to an instance variable - a variable that is associated with a
specific instance of a class, in a shared method. A shared method is
NOT associated with any particular instance of a class. It is
associated with the class itself. VB sort of hides this distinction
with it's dubious feature of allowing you to call shared methods via
instance variables (an honor that C# will share as of version 3.0).
Anyway, what all of the above means is that you can not access
ButtonHasBeenClicked in the manner you are attempting, since a shared
method has NO knowledge of which version of ButtonHasBeenClicked to
reference...
What this means is that you need to:
1) declare ButtonHasBeenClicked as shared, which means if you have
multiple instances of your form - all of them will share the same
ButtonHasBeenClicked, which is probably not what you want.

In my heart of hearts I KNOW that there will only be one instance of the
Form1 class.
So actually his solution works. But I don't like the estethics of it. It
seems to be a serious
misuse of the intended use of Shared.
2) Remove the shared modifier from the sub, so that it is a member
method (this means that there is an implicit Me reference passed to
the sub/function - which means you can then refer to the
ButtonHasBeenClicked variable as your doing now.

But if I remove Shared from the subroutine then I can't call it from the
Module1 code.
3) Keep your sub/function shared, but make it take a parameter that
specifies the instance you are interested in: sub somesub (byval
theForm as myform). Then you can use that instance variable to get a
hold of ButtonHasBeenClicked.

I think that I will probably go this way. This problem will come up again
when I implement
my one and only message logger for my one and only Form1 application, so I
might as well
get used to it. Thanks again for your response. Bob
Personally, I would probably use #2 if this sub/function has no
utility beyond your specific form. And don't think that this will
cause multiple versions of the funciton/sub to be in memory at once
(I've seen people concerned by this before) - because it won't. All
instances of the class still call the same code, but the compiler adds
a additional parameter to the funciton sub, that takes the
instance....
Anyway, HTH
--
Tom Shelton- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -
Bob, reading both replys I'm begining to get a better understanding of
what your trying to accomplish, and let me say your desire to separate
common code, from implementation specific code is the correct one.
But, with all due respect, you're approching it the wrong way....

First, I would separate ALL logic involved in mining the websites from
the UI. That logic is more appropriately placed in a Class. In fact,
I would most likely move it to it's own class library, so that the
logic is able to be used from multiple different applications/
interfaces.

Second, as for separating out the logic... There are several ways to
approach this, but I think the simplest at this point would to be
through inheritance. In that case, I would probably create somthing
looked like (air code follows!):

public mustinherit class WebMinerBase

public overridable sub
DoCoolStuffButAllowSubClassesToAlterBehavior()
' common code
end sub

public mustoveride sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()

' factory method to create subclass to handle the address
public shared function CreateWebMiner (byval address as string) as
WebMinerBase
if address = google then
retrun new GoogleMiner()
else if address = ebay then
return new EbayMiner()
endif
end function
end class

public class GoogleMiner
inherits WebMinerBase

public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()
' google specific implementation
end sub
end class

public class EbayMiner
inherits WebMinerBase

public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()
' Ebay specific implementation
end sub
end class

' client code in form

private sub button_click (byval sender as object, byval e as
eventargs) handles button.click
dim webminer as WebMinerBase = WebMinerBase.CreateWebMiner(addres)
webminer.DoCoolStuffButAllowSubClassesToAlterBehav ior()
webminer.DoCoolStuffAndInsistSubClassesProvideAnIm plementation()
end sub

Anyway, the point is to abstract common logic into tthe base class,
and the implementation specific into subclasses. Then you can use a
generic interface, and through polymorphism get specific behavior...

Anyway, just a thought.

--
Tom Shelton

Oct 19 '07 #6

P: n/a
Tom, Thanks very much for sharing your knowledge and taking the time to do
so. I reallly! like your solution/approach. It would never have occurred
to me as I have done very little OO programming. I have written only a few
very simple classes and have never written a class which is then inherited.
But I understand the concepts of your approach. I don't know if I can
justify restructuring my current project. New function always seems to
trump improving the structure. Thanks again for all of your help. Bob

"Tom Shelton" <to*********@comcast.netwrote in message
news:11**********************@e34g2000pro.googlegr oups.com...
On Oct 19, 3:07 pm, "eBob.com" <eBob....@totallybogus.comwrote:
>Hi Tom, Thanks very much for your response. Please see my further
questions below interspersed with your reply. Also, I hope you will look
at
my
reply to Armin's response.

"Tom Shelton" <tom_shel...@comcast.netwrote in message

news:11**********************@k35g2000prh.googleg roups.com...
On Oct 19, 11:01 am, "eBob.com" <eBob....@totallybogus.comwrote:
I have this nasty problem with Shared methods and what I think of as
"global
storage" - i.e. storage declared outside of any subroutines or
functions.
In the simple example below this "global" storage is
ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which
then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to
access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results
in
the error reflected in the comment. I don't see any ambiguity in what
I
am
trying to do. I suspect there is some syntatic solution but I have
been
unable to find it.
>Thanks much for whatever solution and/or understanding you can
provide.
>Bob
>Public Class Form1
Inherits System.Windows.Forms.Form
> Dim ButtonHasBeenClicked As Boolean
>#Region " Windows Form Designer generated code "
#End Region
> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub
> Public Shared Sub WhatEver()
> If ButtonHasBeenClicked Then ' Cannot refer to an instance
member
of a class from within a shared method or shared member initializer
without
an explicit instance of the class.
The error message means EXACTLY what it says. You are trying to refer
to an instance variable - a variable that is associated with a
specific instance of a class, in a shared method. A shared method is
NOT associated with any particular instance of a class. It is
associated with the class itself. VB sort of hides this distinction
with it's dubious feature of allowing you to call shared methods via
instance variables (an honor that C# will share as of version 3.0).
Anyway, what all of the above means is that you can not access
ButtonHasBeenClicked in the manner you are attempting, since a shared
method has NO knowledge of which version of ButtonHasBeenClicked to
reference...
What this means is that you need to:
1) declare ButtonHasBeenClicked as shared, which means if you have
multiple instances of your form - all of them will share the same
ButtonHasBeenClicked, which is probably not what you want.

In my heart of hearts I KNOW that there will only be one instance of the
Form1 class.
So actually his solution works. But I don't like the estethics of it.
It
seems to be a serious
misuse of the intended use of Shared.
2) Remove the shared modifier from the sub, so that it is a member
method (this means that there is an implicit Me reference passed to
the sub/function - which means you can then refer to the
ButtonHasBeenClicked variable as your doing now.

But if I remove Shared from the subroutine then I can't call it from the
Module1 code.
3) Keep your sub/function shared, but make it take a parameter that
specifies the instance you are interested in: sub somesub (byval
theForm as myform). Then you can use that instance variable to get a
hold of ButtonHasBeenClicked.

I think that I will probably go this way. This problem will come up
again
when I implement
my one and only message logger for my one and only Form1 application, so
I
might as well
get used to it. Thanks again for your response. Bob
Personally, I would probably use #2 if this sub/function has no
utility beyond your specific form. And don't think that this will
cause multiple versions of the funciton/sub to be in memory at once
(I've seen people concerned by this before) - because it won't. All
instances of the class still call the same code, but the compiler adds
a additional parameter to the funciton sub, that takes the
instance....
Anyway, HTH
--
Tom Shelton- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Bob, reading both replys I'm begining to get a better understanding of
what your trying to accomplish, and let me say your desire to separate
common code, from implementation specific code is the correct one.
But, with all due respect, you're approching it the wrong way....

First, I would separate ALL logic involved in mining the websites from
the UI. That logic is more appropriately placed in a Class. In fact,
I would most likely move it to it's own class library, so that the
logic is able to be used from multiple different applications/
interfaces.

Second, as for separating out the logic... There are several ways to
approach this, but I think the simplest at this point would to be
through inheritance. In that case, I would probably create somthing
looked like (air code follows!):

public mustinherit class WebMinerBase

public overridable sub
DoCoolStuffButAllowSubClassesToAlterBehavior()
' common code
end sub

public mustoveride sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()

' factory method to create subclass to handle the address
public shared function CreateWebMiner (byval address as string) as
WebMinerBase
if address = google then
retrun new GoogleMiner()
else if address = ebay then
return new EbayMiner()
endif
end function
end class

public class GoogleMiner
inherits WebMinerBase

public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()
' google specific implementation
end sub
end class

public class EbayMiner
inherits WebMinerBase

public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementat ion()
' Ebay specific implementation
end sub
end class

' client code in form

private sub button_click (byval sender as object, byval e as
eventargs) handles button.click
dim webminer as WebMinerBase = WebMinerBase.CreateWebMiner(addres)
webminer.DoCoolStuffButAllowSubClassesToAlterBehav ior()
webminer.DoCoolStuffAndInsistSubClassesProvideAnIm plementation()
end sub

Anyway, the point is to abstract common logic into tthe base class,
and the implementation specific into subclasses. Then you can use a
generic interface, and through polymorphism get specific behavior...

Anyway, just a thought.

--
Tom Shelton

Oct 20 '07 #7

P: n/a

"eBob.com" <fa******@totallybogus.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...
Tom, Thanks very much for sharing your knowledge and taking the time to
do so. I reallly! like your solution/approach. It would never have
occurred to me as I have done very little OO programming.
That's cool. I'm happy to share.
I have written only a few very simple classes and have never written a
class which is then inherited.
OOP done right, is a really good way to approach the building of software -
it is well worth studying/practicing. But, it's not always the right way
either - and it can be overdone.
But I understand the concepts of your approach. I don't know if I can
justify restructuring my current project. New function always seems to
trump improving the structure.
This I have to disagree with you. I think refactoring structure, can
actually lead to longer term benifits in maintainablity and extensability.
If I might, I'd suggest you take a look at Martin Fowler's "Refactoring:
Improving the Design of Existing Code". It's actually a pretty light read,
it's only like the first 4 or 5 chapters that explain the concept - the main
bulk of the book is really just a bunch of suggested refactorings. Those
chapters are at least worth of a skim, to see the descriptions, so that you
can recognize them in your code - but each chapter can be read in detail as
you encounter that particluar "code smell" :)
Thanks again for all of your help. Bob
No problem. Happy to help.

--
Tom Shelton

Oct 20 '07 #8

P: n/a
Hi Armin,

I can see that you have now 2MB connection. Creating long messages with a
lot of non necessary stuff in it.

(Just a reminder to your own correct messages in past)

This is of course not only meant for Armin

:-)

Cor

Oct 20 '07 #9

P: n/a
"Cor Ligthert[MVP]" <no************@planet.nlschrieb
Hi Armin,

I can see that you have now 2MB connection. Creating long messages
with a lot of non necessary stuff in it.
???

Not necessary stuff? I would say it's exactly the information he was
missing. Look at his post: There was a lack of understanding of shared and
instance members and what modules are. That's what I explained. Giving
detailled information about the internals can sometimes also be enlighting,
better than not knowing what's going on in the background forever.

As his answer shows it was not so bad.
(Just a reminder to your own correct messages in past)

This is of course not only meant for Armin

:-)
:-(
Armin

Oct 20 '07 #10

P: n/a
Armin,

I found it terrible long, however when I saw it wrong, then as for ever in
those cases.

Sorry,

Cor

Oct 20 '07 #11

P: n/a
I think the following code will solve your problem. Having the
module hard coded to Form1 makes it non-reusable. Convert your module to a
class, 'WebMiningSupport' and declare all your routines as shared. Then you
can reuse the code with all your projects/forms that need it. You could also
solve this problem by defining an interface that all the forms that want to
use the support dll must implement. Then the support routines would accept
a parameter of the 'interface' type.

Public Class Form1
Dim ButtonHasBeenClicked As Boolean

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub

Public Sub WhatEver()
If ButtonHasBeenClicked Then
'do one thing
Else 'do something else
End If
End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
CalculateSomething(AddressOf WhatEver)

If ButtonHasBeenClicked Then
'do something here; no problem referencing ButtonHasBeenClicked
here()
End If
End Sub

End Class

Module Module1
Delegate Sub mycallback()
Public Sub CalculateSomething(ByVal theCB As mycallback)
theCB()
End Sub
End Module
--
Terry
"eBob.com" wrote:
I have this nasty problem with Shared methods and what I think of as "global
storage" - i.e. storage declared outside of any subroutines or functions.
In the simple example below this "global" storage is ButtonHasBeenClicked.
In this simple example code in Form1 calls a routine in Module1 which then
calls code back in Form1 (subroutine WhatEver). WhatEver needs to access
ButtonHasBeenClicked but the reference to ButtonHasBeenClicked results in
the error reflected in the comment. I don't see any ambiguity in what I am
trying to do. I suspect there is some syntatic solution but I have been
unable to find it.

Thanks much for whatever solution and/or understanding you can provide.

Bob

Public Class Form1
Inherits System.Windows.Forms.Form

Dim ButtonHasBeenClicked As Boolean

#Region " Windows Form Designer generated code "
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
ButtonHasBeenClicked = True
End Sub

Public Shared Sub WhatEver()

If ButtonHasBeenClicked Then ' Cannot refer to an instance member
of a class from within a shared method or shared member initializer without
an explicit instance of the class.

'do one thing
Else 'do something else
End If

End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
CalculateSomething()

If ButtonHasBeenClicked Then
'do something here; no problem referencing ButtonHasBeenClicked
here
End If
End Sub

End Class

Module Module1
Public Sub CalculateSomething()
Form1.WhatEver()
End Sub
End Module
Oct 20 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.