Lots to .like but lots to .NOT like - Serial Port support etc

[Tln1]

At the risk of getting flamed to a crisp.... I have been playing around with
VB.NET for a little over a month now. For the most part I really like .NET,
but there are some major concerns for me:

1) Why is there no native serial port support in the CLR? Relying on a wrapped
VB6 ocx - very inelegant. This is a huge issue for me, many of you could
probably give a rip about this but when millions of serial devices still
need to be accessed and programmed? The omission of this functionally by
MS floors me - am I missing something here?

2) Using the familiar VB6 type methods to read/write large files is a joke
- the performance is terrible. The only way to do efficient file IO in VB.NET
is using the new stream classes. I was hoping I could utilize much of my
file IO code base for a while - that will not be possible.

3) Converting VB6 projects to VB.NET using the wizard? Well, unless you already
have a well conditioned VB6 project (thinking port to VB.NET) and not more
than several forms, you can forget that as well. Any complexity at all will
basically require you to start from scratch in VB.NET.

4) Debugging - makes me long for VB6, edit and continue was one of the best
features on earth, please oh God (BG) bring it back.

5) Form loading - give me more speed Scotty!

There are many other smaller issues but I should not be too picky - there
is for the most part more good than bad. I love the math class, my old ‘C’
code converts to VB.NET easily. The reality has finally sunk in however,
it will be a year before I am anywhere near proficient with VB.NET. I will
have to rewrite virtually all my code to work well in .NET. Many late nights,
classes and fat books await me. I just hope my brain does not explode from
the workout its gonna get. This VB.NET stuff is paradigm shift in VB programming
- make no mistake about it.

Go easy on me now you guys,
Regards,
Terry

[james]

I agree it's hard to learn. And even harder to convert. But, given enough
time, I think you can make it. Supposedly, Edit & Continue will return in
the next version (or if we are real lucky, in a Service Pack) .
As for the serial port thing, I have only just begun working with that.
And there is a lack of information regarding serial communications.
Or at least I have yet to find anything that directs me to a namespace that
supports it.
For now, about the only thing I've heard that works is doing what you have
been doing (using a wrapper class for the VB6 ocx) or
using API calls to work with it.
Still not a good answer.
james

Good luck.
"Tln1" <tnygaard@lcra.org> wrote in message news:3ca36517$1@10.1.10.29...
>
> At the risk of getting flamed to a crisp.... I have been playing around
with
> VB.NET for a little over a month now. For the most part I really like
..NET,
> but there are some major concerns for me:
>
> 1) Why is there no native serial port support in the CLR? Relying on a
wrapped
> VB6 ocx - very inelegant. This is a huge issue for me, many of you could
> probably give a rip about this but when millions of serial devices still
> need to be accessed and programmed? The omission of this functionally by
> MS floors me - am I missing something here?
>
> 2) Using the familiar VB6 type methods to read/write large files is a joke
> - the performance is terrible. The only way to do efficient file IO in
VB.NET
> is using the new stream classes. I was hoping I could utilize much of my
> file IO code base for a while - that will not be possible.
>
> 3) Converting VB6 projects to VB.NET using the wizard? Well, unless you
already
> have a well conditioned VB6 project (thinking port to VB.NET) and not more
> than several forms, you can forget that as well. Any complexity at all
will
> basically require you to start from scratch in VB.NET.
>
> 4) Debugging - makes me long for VB6, edit and continue was one of the
best
> features on earth, please oh God (BG) bring it back.
>
> 5) Form loading - give me more speed Scotty!
>
> There are many other smaller issues but I should not be too picky - there
> is for the most part more good than bad. I love the math class, my old 'C'
> code converts to VB.NET easily. The reality has finally sunk in however,
> it will be a year before I am anywhere near proficient with VB.NET. I will
> have to rewrite virtually all my code to work well in .NET. Many late
nights,
> classes and fat books await me. I just hope my brain does not explode from
> the workout its gonna get. This VB.NET stuff is paradigm shift in VB
programming
> - make no mistake about it.
>
> Go easy on me now you guys,
> Regards,
> Terry
>

[Rob Teixeira]

"Tln1" <tnygaard@lcra.org> wrote:
>
>At the risk of getting flamed to a crisp.... I have been playing around
with
>VB.NET for a little over a month now. For the most part I really like .NET,
>but there are some major concerns for me:

You *usually* don't get flamed if you're not an extremist

>1) Why is there no native serial port support in the CLR? Relying on a wrapped
>VB6 ocx - very inelegant. This is a huge issue for me, many of you could
>probably give a rip about this but when millions of serial devices still
>need to be accessed and programmed? The omission of this functionally by
>MS floors me - am I missing something here?

Considering the hundreds of things that are in the runtime, I'm thinking
this one was just lower in priority. There are already some managed classes,
but all IO reverts to unmanaged code at the very bottom level. There was
a free class/code on GetDotNet.com (i think it was that site?) as well as
a few others that wrapped not the OCX, but the file IO stream calls to the
serial port. There's also a few books coming up that deal with .NET and the
serial port, so you're very likely to get some components from that too.
Of course, MS could very well post something in the near future too. However,
considering that there are a few free samples out there already, they might
just rather stick to fixing some other core issues.

>2) Using the familiar VB6 type methods to read/write large files is a joke
>- the performance is terrible. The only way to do efficient file IO in VB.NET
>is using the new stream classes. I was hoping I could utilize much of my
>file IO code base for a while - that will not be possible.

Yeah, I happen to like the versatility of the stream-based classes myself,
particularly because you can interface with all the other streams in the
framework so easily. But, that doesn't help the old code. I bit the bullet
and just changed the code.

>3) Converting VB6 projects to VB.NET using the wizard? Well, unless you
already
>have a well conditioned VB6 project (thinking port to VB.NET) and not more
>than several forms, you can forget that as well. Any complexity at all will
>basically require you to start from scratch in VB.NET.

Yeah. I've been saying that for months now
However, I did manage to convert two very large programs manually (with the
help of some tools I built in .NET too). Of course, the results there are
much better than with the wizard, and it gave me time to restructure some
of the odd bits of hacky VB6 object code, which was another plus. The result
has a lot less code and is much easier to maintain, but it does take effort.

>4) Debugging - makes me long for VB6, edit and continue was one of the best
>features on earth, please oh God (BG) bring it back.

That was a sticking point for me too when I started. I'm surprised I don't
really miss it that much anymore. Some of the other debugging/IDE tools really
make up for it. Just yesterday, I ran into an issue where I really did want
it back for about five seconds so i could make a change though
Luckily, bringing edit & continue back seems to be one of the top priorities
for version 2.
It was actually already in the product during the beta at one point. If you
read some of the tools docs in the SDK, you can see that they actually did
put a LOT of thought into Edit & Continue for .NET. Unfortunately, there
was an implementation problem with the runtime that prevented it from working
properly and they stripped it out by Beta 2. So the intention was never to
drop it, but it did fall victim to some problems.

>5) Form loading - give me more speed Scotty!

I've found that forms loading in and of itself is actually pretty quick.
The problem you're going to face is that WinForms consumes a lot of assemblies,
and the assembly loader (particularly in debug mode projects) takes a while
to do its job.
Once you get rid of the debug environment, build release code, and optionally
NGEN the IL, the load times are very comparable to anything else. Of course,
that doesn't help while you're in the IDE. But even with the slower load
times on WinForms project, I'm still more productive in the new IDE. Hopefully,
they can optimize this area a bit more. WinForms was a big undertaking, and
if i had to choose between it working right vs. a little speed loss, i'd
take the former - they can always optimize later. That seems to be the direction
they were looking at.

>There are many other smaller issues but I should not be too picky - there
>is for the most part more good than bad. I love the math class, my old ‘C’
>code converts to VB.NET easily.

LOL

>The reality has finally sunk in however,
>it will be a year before I am anywhere near proficient with VB.NET. I will
>have to rewrite virtually all my code to work well in .NET. Many late nights,
>classes and fat books await me. I just hope my brain does not explode from
>the workout its gonna get. This VB.NET stuff is paradigm shift in VB programming
>- make no mistake about it.

It does take some effort. In the end, i've found that effort to be worth
my time though.

-Rob

[Phil Weber]

> Why is there no native serial port support in the CLR?
> Relying on a wrapped VB6 OCX - very inelegant. This is
> a huge issue for me...

Terry/James: The latest edition of Richard Grier's book includes native .NET
examples: http://www.mabry.com/vbpgser/
---
Phil Weber

[Patrick Steele [MVP]]

In article <3ca36517$1@10.1.10.29> (from Tln1 <tnygaard@lcra.org>),
> 1) Why is there no native serial port support in the CLR? Relying on a wrapped
> VB6 ocx - very inelegant. This is a huge issue for me, many of you could
> probably give a rip about this but when millions of serial devices still
> need to be accessed and programmed?

Others have commented on possible solutions. I'll throw in a few too:

http://csharpindex.com/code/justinIO.asp

X10 Firecracker (Beta 2)
http://msdn.microsoft.com/code/defau...de/sample.asp?
url=/msdn-files/026/002/414/msdncompositedoc.xml

http://www.corrado.f2s.com/VBNetRs232.htm

--
Patrick Steele
Microsoft .NET MVP

[Mike Mitchell]

On 28 Mar 2002 10:46:47 -0800, "Tln1" <tnygaard@lcra.org> wrote:

>4) Debugging - makes me long for VB6, edit and continue was one of the best
>features on earth, please oh God (BG) bring it back.

I hope you cleared it with BG before referring to His deputy! <g>

MM

[james]

Phil, thanks for the link. I have Richard's first book and it is a good
one. But, after looking at Mabry's listing for the book and the Table of
Contents, he only devotes one chapter to VB.NET serial communications. And
I don't think that is anywhere near enough to
get someone going on doing serial communications in VB.NET.
I will give him the benifit of the doubt though and see if I can find his
book at my local bookstore and go through it and see for myself before I
pass judgement on it.
james
"Phil Weber" <pweber@nospam.fawcette.com> wrote in message
news:3ca36f66$1@10.1.10.29...
> > Why is there no native serial port support in the CLR?
> > Relying on a wrapped VB6 OCX - very inelegant. This is
> > a huge issue for me...
>
> Terry/James: The latest edition of Richard Grier's book includes native
..NET
> examples: http://www.mabry.com/vbpgser/
> ---
> Phil Weber
>
>

[james]

Patrick, thanks for the links, unfortuantely, none of them work !
The first and last one say "Page Not Available" and the Microsoft link
brings up the MSDN site and a blank page for the actual article.
Microsoft must have removed it for some reason.
Thanks anyway.
james

(I copied and pasted the MS link as it had a prob. with word wrap)

"Patrick Steele [MVP]" <patrick@mvps.org> wrote in message
news:MPG.170d5227cb5f784e98990c@news.devx.com...
> In article <3ca36517$1@10.1.10.29> (from Tln1 <tnygaard@lcra.org>),
> > 1) Why is there no native serial port support in the CLR? Relying on a
wrapped
> > VB6 ocx - very inelegant. This is a huge issue for me, many of you could
> > probably give a rip about this but when millions of serial devices still
> > need to be accessed and programmed?
>
> Others have commented on possible solutions. I'll throw in a few too:
>
> http://csharpindex.com/code/justinIO.asp
>
> X10 Firecracker (Beta 2)
> http://msdn.microsoft.com/code/defau...de/sample.asp?
> url=/msdn-files/026/002/414/msdncompositedoc.xml
>
> http://www.corrado.f2s.com/VBNetRs232.htm
>
> --
> Patrick Steele
> Microsoft .NET MVP

[Dick Grier]

Hi,

>>
1) Why is there no native serial port support in the CLR? Relying on a
wrapped
VB6 ocx - very inelegant. This is a huge issue for me, many of you could
probably give a rip about this but when millions of serial devices still
need to be accessed and programmed? The omission of this functionally by
MS floors me - am I missing something here?
<<

Yes, I think this is a problem (I would, wouldn't I?). I have native .NET
code in my book for this. See below. However, my code simply wraps
unmanaged Windows communications APIs in .NET to allow the use of the
FileStream object, etc. While it is "nice enough", I am not completely
satisfied with the results.

>>
3) Converting VB6 projects to VB.NET using the wizard? Well, unless you
already
have a well conditioned VB6 project (thinking port to VB.NET) and not more
than several forms, you can forget that as well. Any complexity at all will
basically require you to start from scratch in VB.NET.
<<

Just, IMO, but most of use do not suggest that code be ported. If its
working... Why not leave it where it is and use .NET for new stuff, or stuff
that demands .NET features.

>>
4) Debugging - makes me long for VB6, edit and continue was one of the best
features on earth, please oh God (BG) bring it back.
<<

I am sure that this is "Number 1, with a bullet" on Microsoft's GO DO list.

Many of us feel your pain. It is not universal, but most of us agree that
things need to be much better.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[Dick Grier]

Hi,

>>
he only devotes one chapter to VB.NET serial communications. And
I don't think that is anywhere near enough to
get someone going on doing serial communications in VB.NET
<<

Why? There isn't anything special about serial comms in .NET. There are
differences, but these are details, not design issues.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[Kunle Odutola]

"Tln1" <tnygaard@lcra.org> wrote in message news:3ca36517$1@10.1.10.29...
>
> At the risk of getting flamed to a crisp.... I have been playing around
with
> VB.NET for a little over a month now. For the most part I really like
..NET,
> but there are some major concerns for me:
>
> 1) Why is there no native serial port support in the CLR?

MS perhaps should have supplied a basic wrapper but most users would have
needed more in any case.

> 5) Form loading - give me more speed Scotty!

Can't say I've had an issue with this except during development.

Kunle

[james]

****, I was just going by the table of contents listings on Maybry's Website
listing your book. I just felt that alot of things would be different in
VB.NET serial communications as opposed to previous
versions of VB's way of handling (or not handling) it.
But, from Microsoft's MSDN Help file that comes with Visual Studio.NET there
is very little there that is directed at the .NET user
and Nothing for the VB.NET user who wants to dirrectlyaccess the serial
ports.
As I said, I will try to get a copy of your book and see for myself.
It appeared to me from looking at the table of contents of your new book,
that the majority of it was a re-hash of your previous books contents. And
I already have your first one.
james
"**** Grier" <****_grier@msn.com> wrote in message
news:3ca39ceb@10.1.10.29...
> Hi,
>
> >>
> he only devotes one chapter to VB.NET serial communications. And
> I don't think that is anywhere near enough to
> get someone going on doing serial communications in VB.NET
> <<
>
> Why? There isn't anything special about serial comms in .NET. There are
> differences, but these are details, not design issues.
>
> --
> Richard Grier (Microsoft Visual Basic MVP)
>
> See www.hardandsoftware.net for contact information.
>
> Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
> Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
>
>
>

[james]

****, I have a question concerning TAPI and VB.NET, have you been able to
wrap the TAPI api to work in VB.NET ? I had assumed from Chris Sells book,
Windows Telephony Programming, that by this version of TAPI (the one with XP
& Win2K) that TAPI programming would be much easier from VB.NET.
Any luck in getting that to work ?
james
"**** Grier" <****_grier@msn.com> wrote in message
news:3ca39c6c@10.1.10.29...
> Hi,
>
> >>
>
> Yes, I think this is a problem (I would, wouldn't I?). I have native .NET
> code in my book for this. See below. However, my code simply wraps
> unmanaged Windows communications APIs in .NET to allow the use of the
> FileStream object, etc. While it is "nice enough", I am not completely
> satisfied with the results.
>
> >>
> 3) Converting VB6 projects to VB.NET using the wizard? Well, unless you
> already
> have a well conditioned VB6 project (thinking port to VB.NET) and not more
> than several forms, you can forget that as well. Any complexity at all
will
> basically require you to start from scratch in VB.NET.
> <<
>
> Just, IMO, but most of use do not suggest that code be ported. If its
> working... Why not leave it where it is and use .NET for new stuff, or
stuff
> that demands .NET features.
>
> >>
> 4) Debugging - makes me long for VB6, edit and continue was one of the
best
> features on earth, please oh God (BG) bring it back.
> <<
>
> I am sure that this is "Number 1, with a bullet" on Microsoft's GO DO
list.
>
> Many of us feel your pain. It is not universal, but most of us agree that
> things need to be much better.
>
> --
> Richard Grier (Microsoft Visual Basic MVP)
>
> See www.hardandsoftware.net for contact information.
>
> Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
> Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
>
>
>

[Dick Grier]

Hi,

>>
I had assumed from Chris Sells book,
Windows Telephony Programming, that by this version of TAPI (the one with XP
& Win2K) that TAPI programming would be much easier from VB.NET.
<<

There is absolutely no support in .NET for TAPI. So... It is not any
easier. In fact, it is a little harder, simply because all unmanaged API
functions are more difficult.

So, TAPI still is best done by dedicated add-ons. Allen-Martin, Sax Comm
Objects, and others (depending on what you want to do) are the best ways to
tackle this tricky area.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[Dick Grier]

Hi,

>>
It appeared to me from looking at the table of contents of your new book,
that the majority of it was a re-hash of your previous books contents. And
I already have your first one.
<<

About 150 of the now 400 pages are new material. The remaining has been
re-written, or in some cases simply edited and clarified. There are lots of
new examples. The accompanying CD-ROM has lots of 3rd party products, too
(including ones that tackle TAPI).

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.