Home > Archive > Visual Basic Syntax > March 2006 > VB 2005 variable declarations and method calls
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VB 2005 variable declarations and method calls
|
|
| Mark Berry 2006-03-30, 10:03 pm |
| Hi,
I'm moving from VB6 to VB 2005. Two questions:
1. One book I'm using has syntax like
Dim testConnection as SqlConnection = New
SqlConnection(connectionString)
However, the Help for the Dim statement says, "If you use New, you do not
use an initializer expression. Instead, you supply arguments, if required,
to the constructor of the class from which you are creating the variable."
And in fact, it seems that the following code is also allowed:
Dim testConnection as New SqlConnection(connectionString)
Are these actually identical? Is the latter example the preferred approach?
2. If the constructor has no arguments, I generally see code like this:
Dim testCommand As SqlCommand = testConnection.CreateCommand()
However when I type this into the IDE up to the "CreateCommand" and press
Enter, the IDE leaves off the parentheses:
Dim testCommand As SqlCommand = testConnection.CreateCommand
This seems very strange, since when I call a method without assigning its
result, the IDE adds the parentheses, e.g. I can type up to Open and press
Enter, and the IDE will add the parentheses:
testConnection.Open()
So again I am wondering if the Dim statements with and without the
parentheses is the same and whether one is preferred over the other.
Thanks for any clarifications.
Mark
| |
| Bob Butler 2006-03-30, 10:03 pm |
| "Mark Berry" <markb@sorrynoemail.com> wrote in message
news:%237LfqPGVGHA.2444@TK2MSFTNGP14.phx.gbl
> Hi,
>
> I'm moving from VB6 to VB 2005. Two questions:
VB 2005 is VB.Net; look for groups with dotnet in the name. It has
virtually nothing in common with VB except for the misleading name.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
| Richard Mueller 2006-03-30, 10:03 pm |
| Hi,
You may need to ask this question in a .NET newsgroup for a more informed
response.
It seems there are at least 6 ways to do many things in ADO, including .NET.
I believe it is really a matter of taste or style. To me the most important
factor is clarity, both for you and anyone supporting the code later. I like
to make things as clear and straightforward as possible, even at the expense
of more lines of code. I have never seen any performance consequences. For
example, I avoid using default properties, but instead assign things
explicitly so it will be clear even to someone as slow and forgetful as
myself months later. I prefer code similar to:
Friend WithEvents TestConnection As System.Data.SqlClient.SqlConnection
TestConnection = New System.Data.SqlClient.SqlConnection
TestConnection.ConnectionString = strConnect
This way I know exactly which property of the SqlConnection object is being
assigned (the ConnectionString property). Again, a matter of style. Also,
the IDE creates most of this code automatically for you. I just don't like
to trust it. For example the IDE assigns the connection string for me, but
breaks it up with line continuations in such a way that it cannot even be
read. I modify so it makes sense to me the poor mortal. Makes no difference
at all for performance, but a big difference in maintainability,
troubleshooting, and later modification.
For SqlCommand objects I've used:
Friend WithEvents TestCommand As System.Data.SqlClient.SqlCommand
TestCommand = New System.Data.SqlClient.SqlCommand
TestCommand.CommandText = "SELECT User_Name FROM MyDb"
TestCommand.Connection = TestConnection
My rule (which no one else is compelled to follow) is that anything that
saves the coder typing can cause problems. Using Friend instead of Dim just
makes it available throughout the project (but not public). If the IDE
leaves off the (), I would trust it on that.
--
Richard
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
"Mark Berry" <markb@sorrynoemail.com> wrote in message
news:%237LfqPGVGHA.2444@TK2MSFTNGP14.phx.gbl...
> Hi,
>
> I'm moving from VB6 to VB 2005. Two questions:
>
> 1. One book I'm using has syntax like
>
> Dim testConnection as SqlConnection = New
> SqlConnection(connectionString)
>
> However, the Help for the Dim statement says, "If you use New, you do not
> use an initializer expression. Instead, you supply arguments, if required,
> to the constructor of the class from which you are creating the variable."
> And in fact, it seems that the following code is also allowed:
>
> Dim testConnection as New SqlConnection(connectionString)
>
> Are these actually identical? Is the latter example the preferred
> approach?
>
> 2. If the constructor has no arguments, I generally see code like this:
>
> Dim testCommand As SqlCommand = testConnection.CreateCommand()
>
> However when I type this into the IDE up to the "CreateCommand" and press
> Enter, the IDE leaves off the parentheses:
>
> Dim testCommand As SqlCommand = testConnection.CreateCommand
>
> This seems very strange, since when I call a method without assigning its
> result, the IDE adds the parentheses, e.g. I can type up to Open and press
> Enter, and the IDE will add the parentheses:
>
> testConnection.Open()
>
> So again I am wondering if the Dim statements with and without the
> parentheses is the same and whether one is preferred over the other.
>
> Thanks for any clarifications.
>
> Mark
>
| |
| Rick Rothstein 2006-03-31, 4:08 am |
| > I'm moving from VB6 to VB 2005.
You have my sympathy. <g>
Rick
| |
| Al Reid 2006-03-31, 8:04 am |
| "Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message news:OkCSWyHVGHA.776@TK2MSFTNGP09.phx.gbl...
>
> You have my sympathy. <g>
>
> Rick
>
>
Rick,
Moving to VB2005 is really easy and it's a nice development tool and I find it to be more productive than VB6. However, don't try
to upgrade any existing vb6 projects. That's just asking for trouble and endless hours of grief.
--
Al Reid
| |
| Ken Halter 2006-03-31, 7:05 pm |
| "Al Reid" <areidjr@reidDASHhome.com> wrote in message
news:OLvI30LVGHA.4864@TK2MSFTNGP12.phx.gbl...
>
> Rick,
>
> Moving to VB2005 is really easy and it's a nice development tool and I
> find it to be more productive than VB6. However, don't try
> to upgrade any existing vb6 projects. That's just asking for trouble and
> endless hours of grief.
>
> --
> Al Reid
Funny how people are so willing to just toss months and months of work in
the trash these days... it's a "New World" I guess where "because it's new"
is far more important than "it's stable" or "it's backward compatible".
Where re-writing code everytime something new is released is completely
acceptable. Where "reusable code" is limited to just some framework a vendor
releases. iow, >your< code's not reusable, only theirs is. Hilarious.
Other than that, I agree that VS2005 is the "best so far" but it still blows
chunks. Check the dotNet groups for people complaining about E&C taking 20
seconds for each keystroke, even with 2gb of ram and a P4. Check how many
others are trying to figure out a way to deploy a tic-tac-toe sized app to a
buddies PC without deploying 20+ mb of framework.
The only way something like dotNet can be "more productive" is for a
developer (with hardly any codebase to grab onto) to rely on the framework
instead of their own fully debugged, tested, documented, etc, code. The IDE
surely isn't more productive... not when you have to wait for (what seems
like) days to get it to do >anything<.
Just as a test, restart your PC, when the PCs ready to start work, start
your stopwatch, fire (well, start) up VSNet and, when it finally gets around
to accepting keystrokes, drop a command button on a form, select it and hit
the F1 key. Stop the watch when MSDN shows anything useful. Report your
findings. I'll do the same in VB6 when I hear a response.
I'll try to stop complaining about dotNet's lack of a real immediate window
(had to sneak one in though ;-)
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
| |
| Al Reid 2006-03-31, 7:05 pm |
| "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message news:e7jAs5NVGHA.736@TK2MSFTNGP12.phx.gbl...
> "Al Reid" <areidjr@reidDASHhome.com> wrote in message
> news:OLvI30LVGHA.4864@TK2MSFTNGP12.phx.gbl...
>
> Funny how people are so willing to just toss months and months of work in
> the trash these days... it's a "New World" I guess where "because it's new"
> is far more important than "it's stable" or "it's backward compatible".
> Where re-writing code everytime something new is released is completely
> acceptable. Where "reusable code" is limited to just some framework a vendor
> releases. iow, >your< code's not reusable, only theirs is. Hilarious.
>
> Other than that, I agree that VS2005 is the "best so far" but it still blows
> chunks. Check the dotNet groups for people complaining about E&C taking 20
> seconds for each keystroke, even with 2gb of ram and a P4. Check how many
> others are trying to figure out a way to deploy a tic-tac-toe sized app to a
> buddies PC without deploying 20+ mb of framework.
>
> The only way something like dotNet can be "more productive" is for a
> developer (with hardly any codebase to grab onto) to rely on the framework
> instead of their own fully debugged, tested, documented, etc, code. The IDE
> surely isn't more productive... not when you have to wait for (what seems
> like) days to get it to do >anything<.
>
> Just as a test, restart your PC, when the PCs ready to start work, start
> your stopwatch, fire (well, start) up VSNet and, when it finally gets around
> to accepting keystrokes, drop a command button on a form, select it and hit
> the F1 key. Stop the watch when MSDN shows anything useful. Report your
> findings. I'll do the same in VB6 when I hear a response.
>
> I'll try to stop complaining about dotNet's lack of a real immediate window
> (had to sneak one in though ;-)
>
> --
> Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
>
>
Ken,
To a certain extent, my reply was tongue-in-ch .<g> I still use VB6 every day on existing projects and, as far as I can see, they
will remain in vb6. They DO NOT upgrade or easily migrate. On the other hand, there are internal applications that were never
written in VB that, due to the fact that the software vendor abandoned the product all together, are being rewritten using VB2005.
I haven't had the problems you report with the product. I don't doubt that you have had those problems, but I have had really good
luck. Granted it takes a long time for help to finally load and, if you're lucky, show something useful. On the other hand I have
never experienced the slow E & C that you describe.
All in all, given that I really didn't have much code to migrate, I have found vb2005 to be easy to learn and productive. YMMV.
And, since I never used the immediate window as a text editor, I don't miss the old immediate window as much as you do.
--
Al Reid
| |
| Mark Berry 2006-03-31, 7:05 pm |
| Richard,
Thanks for your on-topic comments! I also appreciate the off-topic
disucussion as I may one day be faced with upgrading a big project to from 6
to 2005. What worries me about that more than the VB shift is the shift from
ADO classic to .NET. I used disconnected ADO recordsets as my primary data
object model, so updating every reference to .NET is rather
daunting--especially when I recall the effort involved in learning how to
work around all the idiosyncracies of classic ADO.
Mark
| |
| Mark Berry 2006-03-31, 7:05 pm |
| I just found a good explanation of VB 2005 Initializers and Object
Assignments in the book "Programming Microsoft Visual Basic 2005: The
Language" by Francesco Balena, starting on page 48. He is very clear on
comparing and contrasting to VB6. I don't want to re-type three pages of
information, but one thing was particularly enlightening. Take the statement
Dim ds as New DataSet()
In VB6, that means dimension an auto-instancing object variable, but don't
create an object instance until it is assigned with a Set statement.
In VB2005, that means create the ds object NOW. There is no auto-instancing
behavior.
He also explains why VB2005 does not need the Set statement. In VB6, it was
required to disambiguate an object assignment from the use of default
properties. In VB2005, there are no default properties (unless the property
also takes an argument).
I kinda like the forced differentiation in VB6 between objects and
non-objects...this is going to take some getting used to.
Mark
| |
| Mark Berry 2006-03-31, 7:05 pm |
| Ken,
I think you can create "unmanaged code" that does not require the framework
with Visual C 2005 but not Visual Basic 2005.
Visual Basic 6 also requires a "framework" to run (the interpreter, UI
controls, etc.).
Mark
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:e7jAs5NVGHA.736@TK2MSFTNGP12.phx.gbl...
> "Al Reid" <areidjr@reidDASHhome.com> wrote in message
> news:OLvI30LVGHA.4864@TK2MSFTNGP12.phx.gbl...
> Other than that, I agree that VS2005 is the "best so far" but it still
> blows chunks. Check the dotNet groups for people complaining about E&C
> taking 20 seconds for each keystroke, even with 2gb of ram and a P4. Check
> how many others are trying to figure out a way to deploy a tic-tac-toe
> sized app to a buddies PC without deploying 20+ mb of framework.
|
|
|
|
|