S
Smokey Grindle
Whats the easiest way to make a global function in VB 2005? The old way was
make a module, is that still the standard? thanks!
make a module, is that still the standard? thanks!
L
lord.zoltar
Yup, you can still use modules. You can also use namespaces to group
data.
A
AMDRIT
I think the new preferred way is to use a singleton. Example
myglobals.instance.somedata="Test String"
public class myglobals
'Singleton Variables
private shared pobjGlobals as MyGlobals
'Instance Variables
private pstrUserName as string
private pintUserID as integer
private pstrSomeData as stirng
'Singleton Creation
shared sub new
pobjGlobals = new MyGlobals
end sub
'Instance Access
public shared readonly Property Instance as MyGlobals
get
return pobjGlobals
end get
end property
'Instance Methods
public function Login(userName as string, password as String) as boolean
'test credentials
'once successful,
me.pstrUserName = 'Some User Name
me.pstrUserID = 'Some User ID
end function
Public Function Add(intVarA as integer, intVarB as integer) as integer
return intvar1 + intvarB
end Function
'Instance Properties
public readonly property UserID as integer
get
Return pintUserID
end get
end property
Public Property SomeData as string
get
return pstrSomeData
end get
set(value as string)
pstrSomeData = value
end set
end property
end class
But yes, modules are still available.
myglobals.instance.somedata="Test String"
public class myglobals
'Singleton Variables
private shared pobjGlobals as MyGlobals
'Instance Variables
private pstrUserName as string
private pintUserID as integer
private pstrSomeData as stirng
'Singleton Creation
shared sub new
pobjGlobals = new MyGlobals
end sub
'Instance Access
public shared readonly Property Instance as MyGlobals
get
return pobjGlobals
end get
end property
'Instance Methods
public function Login(userName as string, password as String) as boolean
'test credentials
'once successful,
me.pstrUserName = 'Some User Name
me.pstrUserID = 'Some User ID
end function
Public Function Add(intVarA as integer, intVarB as integer) as integer
return intvar1 + intvarB
end Function
'Instance Properties
public readonly property UserID as integer
get
Return pintUserID
end get
end property
Public Property SomeData as string
get
return pstrSomeData
end get
set(value as string)
pstrSomeData = value
end set
end property
end class
But yes, modules are still available.
F
Fabio
Smokey Grindle said:
Since modules are compiled as static classes, if you use a static (shared)
class you will be more in the ".net way".
A
_AnonCoward
:
: Whats the easiest way to make a global function in VB 2005? The
: old way was make a module, is that still the standard? thanks!
Try shared methods. These methods are available to every instance of a
type and can even be accessed without an actual instance being
declared (e.g.: the System.Console.WriteLine() method). It should be
noted that shared methods cannot operate on non-shared members of the
class. The following will not compile:
=========================================
Public Class [class]
Private i As Integer = 0
Public Shared Sub Method()
Console.WriteLine(i)
End Sub
End Class
=========================================
Ralf
: Whats the easiest way to make a global function in VB 2005? The
: old way was make a module, is that still the standard? thanks!
Try shared methods. These methods are available to every instance of a
type and can even be accessed without an actual instance being
declared (e.g.: the System.Console.WriteLine() method). It should be
noted that shared methods cannot operate on non-shared members of the
class. The following will not compile:
=========================================
Public Class [class]
Private i As Integer = 0
Public Shared Sub Method()
Console.WriteLine(i)
End Sub
End Class
=========================================
Ralf
H
Herfried K. Wagner [MVP]
Smokey Grindle said:
Yes.
T
Tom Leylan
I will suggest it is "easy" but I'm doubtful that it is the "standard" or
(if it is at this point) that it will remain so.
http://msdn2.microsoft.com/en-us/library/7825002w(VS.80).aspx
I'd like to caution the OP against modules. As the number of public
functions increases you'll tend to want to organize them in some way,
classes do this for you in a natural way.
Perhaps as an exercise you could list (here) the names of 3 or 4 functions
which you might consider putting into a module. What are their names and
(if isn't obvious) what do they do?
(if it is at this point) that it will remain so.
http://msdn2.microsoft.com/en-us/library/7825002w(VS.80).aspx
I'd like to caution the OP against modules. As the number of public
functions increases you'll tend to want to organize them in some way,
classes do this for you in a natural way.
Perhaps as an exercise you could list (here) the names of 3 or 4 functions
which you might consider putting into a module. What are their names and
(if isn't obvious) what do they do?
H
Herfried K. Wagner [MVP]
Tom Leylan said:
Even modules organize functions. This only doesn't necessarily implicate
that they can only be used with qualification (module name). The Visual
Basic Runtime Library is a perfect sample.
Functionality similar to the functionality in the Visual Basic Runtime
Library. Extended mathematical functions, for example which are used
extensively in the context of the project.
T
Tom Leylan
Hi Herfried: Let me begin by stating that I believe we disagree on certain
programming fundamentals and so opinions (yours and mine both) should be
weighed by the degree of "VB-ishness" we prefer. I don't think I'm wrong in
stating you like it and I've only actually liked VB since VB.Net hit the
scene.
The question for me usually comes down to "how does every other .Net
language manage to get along with out modules?" I'm staring at the VB
run-time library right now so perhaps you can explain (as you see it) the
reason that .ControlChars is a class and .Conversion is a module? I see
for instance a module contains ErrorToString(ByVal ErrorNumber As Integer)
As String
What is the upside to this not being a method of an Error object? What does
anybody gain by having a public function that you pass integers to? It is a
wrapper (isn't it?) for the Err.Number property. So why would ErrorToString
be used when the Err object contains the number, the description and more?
Let's look at DateAdd( Interval, Number DateValue). One must actually pass
the date value to use along with the interval and such and it returns a
DateTime. If you have a DateTime variable anyway wouldn't .AddDays(),
..AddMonths(), .Add() and the other methods .IsLeapYear(), etc. be handy as
well? Is there a benefit to an extra set of arbitrarily named functions?
Let's see what would the code look like in C# dt.AddDays(7) what would it
look like in Python.Net, or Delphi.Net or any other .Net language? I think
dt.AddDays(7) will do it in every case. The benefit is clearly "it doesn't
matter what language you write in you can read the code." I can't say for
certain but I doubt there is an IncrementPeriod function in Delphi.Net which
takes some number of parameters but I am assured there is DateTime.AddDays.
Does anybody (not converting a VB6 app) uppercase strings by using UCase()
rather than String.ToUpper()? Again I ask is that so experienced developers
in every other DotNet language is confused?
I'm not advocating that everybody do what I say I'm simply offering an
opposing viewpoint. I would however tell anybody doing it in a project that
I controlled to please stop and when I've removed the reference to the
VisualBasic namespace, the code had better still compile.
programming fundamentals and so opinions (yours and mine both) should be
weighed by the degree of "VB-ishness" we prefer. I don't think I'm wrong in
stating you like it and I've only actually liked VB since VB.Net hit the
scene.
The question for me usually comes down to "how does every other .Net
language manage to get along with out modules?" I'm staring at the VB
run-time library right now so perhaps you can explain (as you see it) the
reason that .ControlChars is a class and .Conversion is a module? I see
for instance a module contains ErrorToString(ByVal ErrorNumber As Integer)
As String
What is the upside to this not being a method of an Error object? What does
anybody gain by having a public function that you pass integers to? It is a
wrapper (isn't it?) for the Err.Number property. So why would ErrorToString
be used when the Err object contains the number, the description and more?
Let's look at DateAdd( Interval, Number DateValue). One must actually pass
the date value to use along with the interval and such and it returns a
DateTime. If you have a DateTime variable anyway wouldn't .AddDays(),
..AddMonths(), .Add() and the other methods .IsLeapYear(), etc. be handy as
well? Is there a benefit to an extra set of arbitrarily named functions?
Let's see what would the code look like in C# dt.AddDays(7) what would it
look like in Python.Net, or Delphi.Net or any other .Net language? I think
dt.AddDays(7) will do it in every case. The benefit is clearly "it doesn't
matter what language you write in you can read the code." I can't say for
certain but I doubt there is an IncrementPeriod function in Delphi.Net which
takes some number of parameters but I am assured there is DateTime.AddDays.
Does anybody (not converting a VB6 app) uppercase strings by using UCase()
rather than String.ToUpper()? Again I ask is that so experienced developers
in every other DotNet language is confused?
I'm not advocating that everybody do what I say I'm simply offering an
opposing viewpoint. I would however tell anybody doing it in a project that
I controlled to please stop and when I've removed the reference to the
VisualBasic namespace, the code had better still compile.
M
Michel Posseth [MCP]
Hi Tom
Personally i only use Modules when i want to replace built in methods for
custom methods ( for instance the better IIF function ) so i believe a
module still has a verry handy functionality in VB .
There are several reassons why someone might use the VB methods in favor of
the framework methods
1. the VB methods are sometimes shorter ( saves typing , and thus coding
speed )
2. The VB methods sometimes behave different as there .Net counterparts
3 The VB methods often have built in validation ( where you should write a
try catch block for the .Net counterpart )
Well about this i would say read my comments on this article and you see my
personal opinion
http://www.codeproject.com/useritems/novbruntimeref.asp?df=100&forumid=327076&exp=0
Note that he has withdrawn his comments to me ( wich was verry rude ) as i
did not give up on him to convince him from my point of view , i hope it has
the same effect on you .
In short VB is a RAD because of the shortcuts in the framework that the vb
namespace provides no need for RAD ? and want strict framework code ?
move to C# would then be my advice .
By the way i can code in both but i prefer VB as i started with VB on the
C64 on 13th years of age , but i am certainly not a C# basher VB and C#
are just 2 tools that might be prefered in different situations
regards
Michel Posseth
Personally i only use Modules when i want to replace built in methods for
custom methods ( for instance the better IIF function ) so i believe a
module still has a verry handy functionality in VB .
There are several reassons why someone might use the VB methods in favor of
the framework methods
1. the VB methods are sometimes shorter ( saves typing , and thus coding
speed )
2. The VB methods sometimes behave different as there .Net counterparts
3 The VB methods often have built in validation ( where you should write a
try catch block for the .Net counterpart )
Well about this i would say read my comments on this article and you see my
personal opinion
http://www.codeproject.com/useritems/novbruntimeref.asp?df=100&forumid=327076&exp=0
Note that he has withdrawn his comments to me ( wich was verry rude ) as i
did not give up on him to convince him from my point of view , i hope it has
the same effect on you .
In short VB is a RAD because of the shortcuts in the framework that the vb
namespace provides no need for RAD ? and want strict framework code ?
move to C# would then be my advice .
By the way i can code in both but i prefer VB as i started with VB on the
C64 on 13th years of age , but i am certainly not a C# basher VB and C#
are just 2 tools that might be prefered in different situations
regards
Michel Posseth
Tom Leylan said:
F
Fabio
"Michel Posseth [MCP]" <[email protected]> ha scritto nel messaggio
I'm an "old" vb6 enthusiast developer.
But you loose much more in readability and in OOP point of view.
And as said by Tom, you make your code difficult to understand to non-vb
"players".
Right.
They do inside much more controls (that by my point of view should be done
by the programmer for the issue "do you know what are you doing?").
This extra code make the old-vb-compatible code much more slow (But this is
secondary, I prefere that the code was more clear than more fast).
I don't really know whay vb1/2/3/4/5/6 programmers was always complaining
for the "language low quality" and now that the laguage is grown up they
still whant the old vb1/2/3/4/5/6 style.
Maybe sometime someone is right when they say vb programmers are a sort of
looser nerds
I'm an "old" vb6 enthusiast developer.
But you loose much more in readability and in OOP point of view.
And as said by Tom, you make your code difficult to understand to non-vb
"players".
Right.
They do inside much more controls (that by my point of view should be done
by the programmer for the issue "do you know what are you doing?").
This extra code make the old-vb-compatible code much more slow (But this is
secondary, I prefere that the code was more clear than more fast).
I don't really know whay vb1/2/3/4/5/6 programmers was always complaining
for the "language low quality" and now that the laguage is grown up they
still whant the old vb1/2/3/4/5/6 style.
Maybe sometime someone is right when they say vb programmers are a sort of
looser nerds
H
Herfried K. Wagner [MVP]
Fabio said:
OOP is a tool, not a goal. Yes, you are loosing object-orientation, but I
believe that object-orientation is not always the best tool. Take the
'Math' class as an example.
\\\
x = Sin(a) * 2
///
seems more natural than
\\\
x = Math.Sin(a) * 2
///
In the latter case readability gets worse and the only way to make it better
is by importing the 'Math' class. In the case of the mathematical functions
it's absolutely irrelevant that the functions are members of a certain
class. Qualification by class name only blows up code and thus reduces
readability.
Does that really matter? There are so many things which are different in
various programming languages. You can also say that other programming
languages not providing the functionality VB provides make understinding VB
code hard to non-vb "players", which is certainly often the case in
practice. So that's only a POV.
I see that an an advantage in certain cases. Why write
\\\
If s IsNot Nothing AndAlso s.Length > 0 Then
...
End If
///
if I can simply write
\\\
If Len(s) > 0 Then
...
End If
///
C
Cor Ligthert [MVP]
Amdrit
Why is this better than a module?
And it is not a singleton that word is not used in the VB language.
(While it is as well no singleton in the C world).
Your difficult class written as a nice module could be
Public Module myGlobals
private probjeGlobals as MyGlobabls
etc.
Those are therefore private to the module, only the dim is automaticly
public.
In my idea is a good written VB module therefore much nicer than a so called
often named shared class.
Cor
Why is this better than a module?
And it is not a singleton that word is not used in the VB language.
(While it is as well no singleton in the C world).
Your difficult class written as a nice module could be
Public Module myGlobals
private probjeGlobals as MyGlobabls
etc.
Those are therefore private to the module, only the dim is automaticly
public.
In my idea is a good written VB module therefore much nicer than a so called
often named shared class.
Cor
C
Cor Ligthert [MVP]
Anon,
Be aware that it is not OOP, you forgot to tell that.
Cor
Be aware that it is not OOP, you forgot to tell that.
Cor
M
Michel Posseth [MCP]
I am with you Herfried ,
You reflect my opinion in your previous post
I see VB.Net as a much richer .Net programming language ( as C# ) because
of the shortcuts in the framework that it provides
regards
Michel
You reflect my opinion in your previous post
I see VB.Net as a much richer .Net programming language ( as C# ) because
of the shortcuts in the framework that it provides
regards
Michel
C
Cor Ligthert [MVP]
Tom,
As I read your message is it like as some people who wish that all Americans
are talking only true English. However that does not even exist, every
neighbourhoud in England has its own words.
By the way I find a good written module always nicer than those Singleton
and Static class approaches were almost nobody knows what is meant with
that, but as I see an approach to give the module to C languages.
And everbody seems forever to forget that the module has in Net private
members, which did not exist in VB before 2002.
Cor
As I read your message is it like as some people who wish that all Americans
are talking only true English. However that does not even exist, every
neighbourhoud in England has its own words.
By the way I find a good written module always nicer than those Singleton
and Static class approaches were almost nobody knows what is meant with
that, but as I see an approach to give the module to C languages.
And everbody seems forever to forget that the module has in Net private
members, which did not exist in VB before 2002.
Cor
Tom Leylan said:
C
Cor Ligthert [MVP]
Herfried,
Right, exact as it is and much nicer than all those ugly C variants on this.
I wish the OP to point on the faq that there are a lot of people who think
that OOP has to do with C derived languages and that therefore the way
something is used in those languases is the Net way. Nothing is less worth.
Often VB.Net is much nicer implementing OOP, probably because they don't
have to do with C legacy..
Cor
Right, exact as it is and much nicer than all those ugly C variants on this.
I wish the OP to point on the faq that there are a lot of people who think
that OOP has to do with C derived languages and that therefore the way
something is used in those languases is the Net way. Nothing is less worth.
Often VB.Net is much nicer implementing OOP, probably because they don't
have to do with C legacy..
Cor
T
Tom Leylan
Hi Michel:
I fear this will be a difficult thread to follow as everybody arches their
back and prepares to defend their turf
To be honest few people measure productivity in terms of "typing time" and
method name length. I have yet to suggest to any programmer and have never
heard any manager say "why did you name that method BalanceDue when BD is
only two characters... hey let's save some time here". I have on the other
hand asked them why the public variable they are using everywhere in the
program is named decBD.
As regards the other points that means developers are relying on subtleties.
They are choosing a method for some side effect benefit. That is a losing
game, software development is about "plain and obvious" not clever. Which
VB methods behave differently? One more thing to keep track of and to me
one more reason to avoid them.
I read the article and I read your responses. I understand how people feel
and possibly there are some benefits to be derived from the VisualBasic
namespace. I would add it the moment I needed something from it but that
won't be the UCase method.
This is a fallacious argument C# is not VB minus some function calls. As
you know C# is a case sensitive language, uses braces to delimit blocks of
codes and has a semicolon statement terminator. These are things
(particular case sensitivity) that impact the very thing you mentioned
earlier, coding speed. You suggest saving 4 letters in a method name but
are ignoring the multitude of times that an otherwise insignificant case
difference leads to re-editing and re-compiling.
Not using UCase() when .ToUpper is available isn't a reason to switch to
another language.
Well if I had VB on the Singer-Frieden printing terminal (and it's paper
tape input) I might have started with it also.
I fear this will be a difficult thread to follow as everybody arches their
back and prepares to defend their turf
To be honest few people measure productivity in terms of "typing time" and
method name length. I have yet to suggest to any programmer and have never
heard any manager say "why did you name that method BalanceDue when BD is
only two characters... hey let's save some time here". I have on the other
hand asked them why the public variable they are using everywhere in the
program is named decBD.
As regards the other points that means developers are relying on subtleties.
They are choosing a method for some side effect benefit. That is a losing
game, software development is about "plain and obvious" not clever. Which
VB methods behave differently? One more thing to keep track of and to me
one more reason to avoid them.
I read the article and I read your responses. I understand how people feel
and possibly there are some benefits to be derived from the VisualBasic
namespace. I would add it the moment I needed something from it but that
won't be the UCase method.
This is a fallacious argument C# is not VB minus some function calls. As
you know C# is a case sensitive language, uses braces to delimit blocks of
codes and has a semicolon statement terminator. These are things
(particular case sensitivity) that impact the very thing you mentioned
earlier, coding speed. You suggest saving 4 letters in a method name but
are ignoring the multitude of times that an otherwise insignificant case
difference leads to re-editing and re-compiling.
Not using UCase() when .ToUpper is available isn't a reason to switch to
another language.
Well if I had VB on the Singer-Frieden printing terminal (and it's paper
tape input) I might have started with it also.
T
Tom Leylan
Actually VB is a tool not a religion.
Re: your Sin() example:
It is completely relevant if you use an alternative math library. It is
important for many to understand that not all software is like the software
that we personally produce. Nobody I know qualifies Sin() with Math they
import Math at the top. And again the reason is because one can import a
scientific math library in it's place and gain whatever benefit that might
have without changing the code below.
Yes in the business world it matters very much. Confusion cost money.
Programmers are hired on a budget there isn't some infinite amount of money
available and it is common for the "VB-guy" to be asked to write non-VB code
and the C# guy to fill in when the VB-guy is sick or quits.
Please note my careful wording of the example in my post it isn't C# vs VB
it is the VB function library versus "every other dotnet language."
Striving to be different for no apparent benefit is the problem. Where a
funny hat if that is the VB-er's goal.
But that's the point isn't it. Import the Visual Basic namespace and do it
your way who said you couldn't? I only say you can't if you work for me.
If it becomes a major headache we can create our own class and implement
Len() as a function along with the 100 or so other things we find repetitive
and annoying. It is what we would do if we encountered something we needed
that wasn't currently in the framework or the VB namespace. That library
can be used by both the VB development team and the C-Sharp team.
T
Tom Leylan
Michel:
Languages aren't (necessarily) supposed to be rich. The language should be
straightforward, the libraries should be rich. Nothing prevents C#
developers from creating a rich set of alternative functions so they can use
UCase() instead of .ToUpper().
You're still making it a VB vs C# thing and it isn't. It is (the DotNet
family of languages including VB.Net) vs some compatibility layer in VB.Net.
We're not dumb if Str() and Sin() and UCase() were excellent ways to save
time everybody and their mother would simply write such things.
Are we to believe that only VB is clever enough to have thought of this? Or
that C# developers like to waste time typing? Step back a moment and try to
understand we'd adopt anything that was a good idea. Option Explicit Off
was never a "really cool thing that C# doesn't have." It was a dumb idea
that cost untold millions in lost time and money debugging things.
If UCase() is handy I suggest that you will find it added to other DotNet
languages in time. I wouldn't hold my breath
Languages aren't (necessarily) supposed to be rich. The language should be
straightforward, the libraries should be rich. Nothing prevents C#
developers from creating a rich set of alternative functions so they can use
UCase() instead of .ToUpper().
You're still making it a VB vs C# thing and it isn't. It is (the DotNet
family of languages including VB.Net) vs some compatibility layer in VB.Net.
We're not dumb if Str() and Sin() and UCase() were excellent ways to save
time everybody and their mother would simply write such things.
Are we to believe that only VB is clever enough to have thought of this? Or
that C# developers like to waste time typing? Step back a moment and try to
understand we'd adopt anything that was a good idea. Option Explicit Off
was never a "really cool thing that C# doesn't have." It was a dumb idea
that cost untold millions in lost time and money debugging things.
If UCase() is handy I suggest that you will find it added to other DotNet
languages in time. I wouldn't hold my breath