Re: Shared Method Problem With "Global" Storage

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.nospam@xxxxxxxxxx>
Newsgroups: microsoft.public.dotnet.languages.vb
Sent: Friday, October 19, 2007 1:19 PM
Subject: Re: Shared Method Problem With "Global" Storage


"eBob.com" <eBob.com@xxxxxxxxxxxxxxxx> schrieb
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



.