Pointer to String in VB2005

[Karl E. Peterson]

What always amazes me about people like the OP for this thread is that after
one visit to this group, they think they understand everything about it and
feel free to reject the advice and counsel of those who have spent years
volunteering their time here. It just boggles the mind that someone could
have such a high opinion of themselves as to think they could not possibly
be wrong.

Okay, you didn't get the memo -- only one GWB comparison per thread! ;-)

 

[Bob O`Bob]

If you really have the best interest of your employer/clients and
industry as a whole at heart, you'll exert your influence by letting
the ignorant folks who are asking you to work in VB# know that using a
proprietary MS language that MS doesn't write any of their own code in
is a bad idea because MS has proven that they can't be trusted to
protect any code invested in such language. Or you can just continue
with the Baaaaaa, baaaaaa, baaaaaa.... If you act like a sheep then
you'll be treated like a sheep and be herded around shorn and
slaughtered at someone else's whim.

I completely agree, though I would have used the word "respect" where you wrote "protect"


Bob
--

 

[Bob O`Bob]

You have got to admit there is a significant gap when the simplest of programs
need a complete rewrite to do the same task:

Private Sub Form_Load()
AutoRedraw = True
Print "Hello World"
End Sub

....or when a simple wait-cursor class can't be implemented AT ALL.



Bob
--

 

[Larry Serflaten]

Not sure whether you intended "you would" or "you could" there? One of those is
incorrect, of course, given they actually changed behavior (recycled) some commands.

....you'd find "they" were the same....

Did you take that to mean the commands? The topic was about language differences.
I made no distiction on functionality for the count. Return was listed as a statement in
both languages, yet they differ in usage. I figured adding the statement about methodology
had covered enough ground to also indicate there were more differences that were not
apparent on the surface.

LFS

 

[Paul Clement]

¤
¤
¤
¤ > The problem is that several of them refer to the "core language" (absent of language extensions)
¤ > only when it suits their argument. If you tell them that Microsoft has routinely broken code over
¤ > the years with changes to the language extensions then they'll chime on about how the "core
¤ > language" is what's truly important because it drives the "business logic" of their applications.
¤ > However, if you point out that over 90% of the core language is still intact, then they'll challenge
¤ > you run a Classic Visual Basic app through the upgrade wizard and then tell them that the
¤ > "languages" are the same.
¤
¤
¤ Considering the language's Statements and Functions make up the lion's share of
¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤
¤ VB5 Net Both
¤ Statements 95 51 33
¤ Functions 140 128 116
¤
¤
¤ Of VB5's 95 statements, only 33 were also found as statements in VB2005.
¤ Of VB5's 140 functions, only 116 were found listed under functions for VB2005.
¤
¤ That makes for 149 out of 235 possible commands where you'd find they
¤ were the same. That was a rough count, but on the surface they appear to
¤ be only about 65% the same....
¤
¤ And that does not take into account the difference in methodology of typical
¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ creating Objects, and of course 'Deterministic Finalization'....
¤
¤ You have got to admit there is a significant gap when the simplest of programs
¤ need a complete rewrite to do the same task:
¤
¤ Private Sub Form_Load()
¤ AutoRedraw = True
¤ Print "Hello World"
¤ End Sub
¤

Are you certain you checked all of the Visual Basic.NET namespaces? Did you include statements from
Classic Visual Basic that are actually extensions to the language? For example, AutoRedraw is an
extension to the language.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Karl E. Peterson]

...you'd find "they" were the same....

Did you take that to mean the commands? The topic was about language differences.
I made no distiction on functionality for the count.

Same keyword with different functionality equates to "not same" in my book.

Return was listed as a
statement in both languages, yet they differ in usage.

That's the one, specifically, I had in mind, yep.

I figured adding the
statement about methodology had covered enough ground to also indicate there were
more differences that were not apparent on the surface.

I was just amplifying, not criticizing. Carry on...

 

[Robert Morley]

Where on EARTH did you see THAT? My impression of the whole thing was that
the OP took exception to the tone of Karl's first reply, and would have been
quite content to follow the instructions and move on to a .NET group, had it
not been for that. Not once did I see him reject anybody's advice; in fact,
he followed it in trimming a couple of the groups off the reply list.

I think the real problem here is the letters "MVP"...it's been misspelled.
The correct letters should have been "EGO".



Rob

 

[Tom Shelton]

...or when a simple wait-cursor class can't be implemented AT ALL.

Bob
--

Private Sub button1_Click ( ByVal sender As Object, ByVal e As
EventArgs )
button1.Enabled = False
Using (WaitCursor wCursor = new WaitCursor ( Me))

' do stuff
System.Threading.Thread.Sleep ( 10000 )
End Using
button1.Enabled = true
End Sub

Public Class WaitCursor
Implements IDisposable
Private frm As Form
Private currentCursor As Cursor

Public Sub New ( ByVal frm As Form)
Me.frm = frm
currentCursor = frm.Cursor
frm.Cursor = Cursors.WaitCursor
End Sub


Public Sub Dispose ()
Me.form.Cursor = Me.currentCursor
End Sub
End Class

Nope. Can't be done.

 

[Tom Shelton]

Private Sub button1_Click ( ByVal sender As Object, ByVal e As
EventArgs )
button1.Enabled = False
Using (WaitCursor wCursor = new WaitCursor ( Me))

' do stuff
System.Threading.Thread.Sleep ( 10000 )
End Using
button1.Enabled = true
End Sub

Public Class WaitCursor
Implements IDisposable
Private frm As Form
Private currentCursor As Cursor

Public Sub New ( ByVal frm As Form)
Me.frm = frm
currentCursor = frm.Cursor
frm.Cursor = Cursors.WaitCursor
End Sub

Public Sub Dispose ()
Me.form.Cursor = Me.currentCursor
End Sub
End Class

Nope. Can't be done.

By the way, I forgot to include the handles clause on the button
click. But this was pretty much off the cuf anyway...

 

[Larry Serflaten]

¤ Considering the language's Statements and Functions make up the lion's share of
¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤
¤ VB5 Net Both
¤ Statements 95 51 33
¤ Functions 140 128 116
¤
¤ ....
¤ You have got to admit there is a significant gap when the simplest of programs
¤ need a complete rewrite to do the same task:
¤
¤ Private Sub Form_Load()
¤ AutoRedraw = True
¤ Print "Hello World"
¤ End Sub
¤

Are you certain you checked all of the Visual Basic.NET namespaces? Did you include statements from
Classic Visual Basic that are actually extensions to the language? For example, AutoRedraw is an
extension to the language.

As indicated, I went through the lists included under the language's Statements
and Functions sections in their respective Language Reference sections. I did
not look at properties (such as Form properties for AutoRedraw) nor did I
check any other classes/namespaces (such as System or other framework classes).

I said that at the start, and also indicated that these two sections make up the
lion's share of the 'core language'. Still, as was shown with the Hello World
example, there is a significant shift involved in the design and implementation
needed to do common tasks. That also has to contribute in the comparison
equation. While I would not disagree to a figure near 65%, you'd have to offer
some significant proof on your 90% similarity figure before I could let that go
unchallenged....

They are simply too different to to even attempt to pass that figure off as fact....

LFS

 

[RobinS]

By the way, I forgot to include the handles clause on the button
click. But this was pretty much off the cuf anyway...

And you left some C# in there.

should probably be

Using (wCursor as WaitCursor = new WaitCursor(Me))



Robin S.

 

[Tom Shelton]

And you left some C# in there.


should probably be

Using (wCursor as WaitCursor = new WaitCursor(Me))

Yes... I did it off the cuff, and since I do most stuff in C# now - I
sometimes do funny things like add ;'s. Still, the I think the point was made.

 

[Herfried K. Wagner [MVP]]

Did you take that to mean the commands? The topic was about language
differences.
I made no distiction on functionality for the count. Return was listed as
a statement in
both languages, yet they differ in usage.

True, but on the other hand the 'String' function has been renamed to
'StrDup', which seems functionally equivalent to the VB6 'String' function.

I measure the difference between VB6 and VB.NET by the availability of a
conversion tool that allows seamless conversion between the two programming
langugages. As most tools fail, I consider the difference to be big
(currently).

 

[Herfried K. Wagner [MVP]]

And you left some C# in there.


should probably be

Using (wCursor as WaitCursor = new WaitCursor(Me))

.... or even 'Using wCursor As New WaitCursor(Me)'.

 

[Herfried K. Wagner [MVP]]

Paul,

¤ Private Sub Form_Load()
¤ AutoRedraw = True
¤ Print "Hello World"
¤ End Sub
¤

Are you certain you checked all of the Visual Basic.NET namespaces? Did
you include statements from
Classic Visual Basic that are actually extensions to the language? For
example, AutoRedraw is an
extension to the language.

I think it's hard to draw the line between language and "extension to the
language" (library?) here. 'Load' and 'Unload' are statements, but they
targetting VB's forms and controls (which you seem to consider an extension
to the language). The '&' operator is clearly part of the language, but
'Right', 'Left', 'Mid', ... are part of a library.

My personal conclusion is that a distinction between language and language
extension (libraries that come with VB and are used in almost every VB
project extensively) doesn't make much sense here. The overall quality of
the migration support can be measured by the total effort it takes to
migrate a solution from VB6 to VB.NET, regardless of which components,
libraries, ... are used. I would not consider A to be a successor of B if
even the simplest program needs a manual rewrite, even if the core language
(its syntax) stayed completely intact and only support for the libraries has
been cancelled.

 

[Paul Clement]

¤ > Are you certain you checked all of the Visual Basic.NET namespaces? Did you include statements from
¤ > Classic Visual Basic that are actually extensions to the language? For example, AutoRedraw is an
¤ > extension to the language.
¤
¤ As indicated, I went through the lists included under the language's Statements
¤ and Functions sections in their respective Language Reference sections. I did
¤ not look at properties (such as Form properties for AutoRedraw) nor did I
¤ check any other classes/namespaces (such as System or other framework classes).
¤
¤ I said that at the start, and also indicated that these two sections make up the
¤ lion's share of the 'core language'. Still, as was shown with the Hello World
¤ example, there is a significant shift involved in the design and implementation
¤ needed to do common tasks. That also has to contribute in the comparison
¤ equation. While I would not disagree to a figure near 65%, you'd have to offer
¤ some significant proof on your 90% similarity figure before I could let that go
¤ unchallenged....
¤
¤ They are simply too different to to even attempt to pass that figure off as fact....

So are you disagreeing with the figure I supplied or whether the versions are completely different
languages or both?


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Tony Proctor]

Yes, but then what if you have an implementation of a script language,
written in VB6, which in turn relies on the Variant data type (as do most
script languages). Since there is no native support for that data type, it
cannot easily be moved across Tom

There are good reasons for why you might end up in this situation:
'scripting' is a powerful tool that's also advocated by MSFT themselves. It
isn't just related to HTML generation. It can be used to express business
rules in XML content, for instance. In the COM world, there's only the
Scripting control, which may have been removed anyway, and which cannot be
embedded in server-side code. There's better support for scripting in the
..Net world, but that doesn't help with portability of existing code.

Tony Proctor

["Followup-To:" header set to microsoft.public.dotnet.languages.vb.]

 

[mayayana]

As an MVP you might have the consideration to
drop the VB groups from your post and keep it in
..Net. Most of the people here are here to discuss
VB6 code, not to count angels on the head of a
dotnet pin.

 

[Paul Clement]

¤
¤ I think it's hard to draw the line between language and "extension to the
¤ language" (library?) here. 'Load' and 'Unload' are statements, but they
¤ targetting VB's forms and controls (which you seem to consider an extension
¤ to the language). The '&' operator is clearly part of the language, but
¤ 'Right', 'Left', 'Mid', ... are part of a library.

They may be a part of a library, but does that then render them an extension to the language?

If it does then you're correct and there is no longer a distinction. Personally I've maintained in
the past that if you break code it really doesn't matter whether the code exists an extension or
part of the core language. It needs to be re-written.

¤ My personal conclusion is that a distinction between language and language
¤ extension (libraries that come with VB and are used in almost every VB
¤ project extensively) doesn't make much sense here. The overall quality of
¤ the migration support can be measured by the total effort it takes to
¤ migrate a solution from VB6 to VB.NET, regardless of which components,
¤ libraries, ... are used. I would not consider A to be a successor of B if
¤ even the simplest program needs a manual rewrite, even if the core language
¤ (its syntax) stayed completely intact and only support for the libraries has
¤ been cancelled.

No disagreement, although I don't believe this defines the versions as completely different
languages. If I can work with many of the same statements, functions, operators and syntax that I've
used in the prior version then it wouldn't be particularly accurate of me to refer to the versions
as "completely different".

C# and Visual Basic.NET are completely different languages. They use different operators, different
syntax and different statements and functions. The only thing they share are the .NET Framework
libraries - extensions to their respective languages.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Ken Halter]

C# and Visual Basic.NET are completely different languages. They use
different operators, different
syntax and different statements and functions. The only thing they share
are the .NET Framework
libraries - extensions to their respective languages.

Funny... that's what this guy says about the, so called, similarities in VB
vs B#. The only thing they share are the letters "V" and "B" in their names.

VB6 Glass Ceiling
http://www.ddj.com/dept/windows/184406274