Searching \ for '[EE] Serial port control under VB.NET 2002/2003' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/io/serials.htm?key=serial
Search entire site for: 'Serial port control under VB.NET 2002/2003'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Serial port control under VB.NET 2002/2003'
2004\09\28@230027 by Ken Pergola

flavicon
face

I apologize for posting in 'EE', but I'm only doing it since I *think* more
people will see this here (and hopefully be helped) as opposed to posted it
in OT. I'll try to be brief and keep this message small.

For those that may not know of it, I just tried out the *FREE* Sax.net
Communications Community Edition serial port ActiveX control. I was getting
a little frustrated (see postscipt below) migrating a VB6 project using the
MSCOMM control to Microsoft Visual Basic .NET 2003.

So until Microsoft Visual Studio .NET 2005 arrives with its *intrinsic*
SerialPort class (System.IO.Ports.SerialPort), you have the option of using
the Sax.net Communications Community Edition ActiveX control for controlling
serial ports. It is free and therefore it is not as feature-rich as Sax's
ActiveX serial port communication controls they are charging real money for,
but hey, it's a lot of fun to use this one. You can get up and running
rather quickly with it. In some respects, it might be easier for people to
use the Community Edition serial port communication control than the MSCOMM
control which Sax wrote for Microsoft many years ago.

You can get the free Sax Community Edition serial port communications
ActiveX control with the Visual Basic .NET Resource Kit:

http://msdn.microsoft.com/vbasic/vbrkit/default.aspx

Hope this helps anyone trying to get your serial port projects working under
Microsoft Visual Studio .NET. I think a lot of PICListers picked up a free
version of VB.NET for watching those Microsoft movies, so give it a try if
you have not already. My hopes is that the control will work with that free
version of VB.NET too.

Best regards, good luck, and have fun,

Ken Pergola


P.S. This is the line of code from VB6 that I just can't seem to coerce into
VB.NET thus far:

bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))

The 'vbUnicode' is not accepted.



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@001813 by James Caska

flavicon
face
Ken,

Thanks for your update on the Serial COMM ports in .NET -- I think many of
us access the serial ports in this way and so I was interested in the
problems with MSComm you are having as I will soon be porting some apps from
VB6 to VB.NET which have MSComm serial control

>bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))

>The 'vbUnicode' is not accepted.

The question is.. Is this the only problem you are experiencing with MSComm?
and how do your recommended package resolve the problem because as far as I
can see the problem is actually with the StrConv routine being incompatible
with vbUnicode Strings not the MSComm1.Input.

Thanks,


James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\09\29@011008 by Ken Pergola

flavicon
face

Regarding converting the following from VB6 to VB.NET:

bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))


James Caska wrote:

> The question is.. Is this the only problem you are experiencing
> with MSComm?



Hi James,

To answer your question, so far, yes. But that does not mean that I won't
run into other problems with porting MSCOMM porting to VB.NET. I actually am
looking forward to Visual Studio .NET 2005 because of the built-in
SerialPort class. I don't know too much about the details at this point, but
I'm hoping it will work fine.

If I'm not mistaken, using the MSCOMM control in VB.NET violates the
philosophy of .NET "managed code". It also appears to create a potential
distribution problem since you should have a legal license for it. For me, I
have a legal version of VB6. But the managed/unmanaged code issue is more
important to me. I'm not sure if using the Sax control qualifies as
unmanaged code too? I could be totally wrong about these two points, so
hopefully someone who is well-versed with the .NET framework can shed some
more light on the situation.


James also asked:

> and how do your recommended package resolve the problem because
> as far as I can see the problem is actually with the StrConv routine being
> incompatible with vbUnicode Strings not the MSComm1.Input.


Well, I just don't know enough about the VB.NET and the .NET framework to
solve this problem at this point. I let VB.NET "upgrade" the VB6 application
with the conversion wizard. I've spent hours reading on-line documentation
and fiddling with things by trial and error to try to get things to work. I
just decided to switch gears and try out that free Sax serial communications
control because it came free with the VB.NET resource kit.

That Sax serial communications control is pretty slick for what I've used it
for so far. This is what prompted me to post the quick results I had with
that Sax serial communications control. I simply got it working in VB.NET,
and was up and running rather quickly . I can't say that with the MSCOMM
control, but I would imagine others have used the MSCOMM control in VB.NET.
I'm sure it's pilot error on my part: miles of .NET before I sleep, and
miles of .NET before I sleep. I have a long journey with .NET, but I'm
looking forward to it.

Best regards,

Ken Pergola






_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@023421 by James Caska

flavicon
face
Hi Ken,

Thanks for the response. I am not sure you have answered my question though,
while I agree there are other issues with managed code and legal licensed
situation -- although I am pretty sure MSComm is a runtime distributable
component for owners of VB6.

However, the problem is not with MSCOMM but the StrConv routine which ( from
the .NET Docs) has not equivalent
so even when you replace the MSCOMM component your code will have the same
problem.

Visual Basic 6.0 Visual Basic .NET Equivalent
vbUpperCase        VbStrConv.UpperCase
vbLowerCase        VbStrConv.LowerCase
vbProperCase        VbStrConv.ProperCase
vbWide                VbStrConv.Wide
vbNarrow                VbStrConv.Narrow
vbKatakana                VbStrConv.Katakana
vbHiragana                VbStrConv.Hiragana
vbUnicode                No equivalent                <<< NO EQUIVALENT
vbFromUnicode        No equivalent                <<< NO EQUIVALENT

Apparently, you can achieve the same result with the
System.Text.Encoding.Convert though.

msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemTextEncodingClassConvertTopic1.asp

Here is the .NET code example they give.. You will have to figure out how to
use it though with the MSComm.input string you have though.. But at least it
might be a starting point..

=============

                Dim unicodeString As String = "This string contains the
unicode character Pi(" & ChrW(&H03A0) & ")"

           ' Create two different encodings.
           Dim ascii As Encoding = Encoding.ASCII
           Dim [unicode] As Encoding = Encoding.Unicode

           ' Convert the string into a byte[].
           Dim unicodeBytes As Byte() = [unicode].GetBytes(unicodeString)

           ' Perform the conversion from one encoding to the other.
           Dim asciiBytes As Byte() = Encoding.Convert([unicode], ascii,
unicodeBytes)

           ' Convert the new byte[] into a char[] and then into a string.
           ' This is a slightly different approach to converting to
illustrate
           ' the use of GetCharCount/GetChars.
           Dim asciiChars(ascii.GetCharCount(asciiBytes, 0,
asciiBytes.Length)) As Char
           ascii.GetChars(asciiBytes, 0, asciiBytes.Length, asciiChars, 0)
           Dim asciiString As New String(asciiChars)

           ' Display the strings created before and after the conversion.
           Console.WriteLine("Original string: {0}", unicodeString)
           Console.WriteLine("Ascii converted string: {0}", asciiString)

=============

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\09\29@115006 by Ken Pergola

flavicon
face

James Caska wrote:


> I am not sure you have answered my question though...

Hi James,

I'm sorry, it was not on purpose. Maybe I misunderstood your question.
Please repost your question so that I may better answer it.


> However, the problem is not with MSCOMM but the StrConv routine
> which ( from the .NET Docs) has not equivalent

Oh, yes, I realize it's not an MSCOMM problem -- that's why I said that the
vbUnicode constant was at fault. I just want to be able to read a byte from
the MSCOMM control under VB.NET just as the VB6 code I posted is doing. This
is where I'm stuck. I have not been able to massage that line of VB6 code
into its proper VB.NET equivalent. I did not mean to imply that the MSCOMM
does not work under VB.NET. Sorry for the confusion if I caused any. I just
have been unable to successfully use the MSCOMM.input method to read a byte
from the MSCOMM control and assign it to a byte variable. If this still does
not answer your question, forgive me, but please re-post your question so
that I may better answer it.


> Apparently, you can achieve the same result with the
> System.Text.Encoding.Convert though.
>
> msdn.microsoft.com/library/default.asp?url=/library/en-us/c
> pref/html/
> frlrfSystemTextEncodingClassConvertTopic1.asp

James, thank you very much for your information as well. I appreciate your
help and your time. I currently am responding to your post, so I have not
checked out the link you posted yet, but I am planning to at some time. Even
though the Sax control is working for me in this current project, I have a
hard time leaving loose ends, so I'd like to settle the MSCOMM problem I am
having. If and when I get a solution, I'll do my best to remember to post in
this thread in the future to benefit others.

Thanks again and best regards James,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@124709 by Bob J

picon face
> bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))
>
> The 'vbUnicode' is not accepted.

Its not being accepted because the constant isn't defined.  Define the
constant as public or just try replacing the constant with the value
the constant represents, whatever that number or string really is...
for example:

bytUART_Byte = Asc((StrConv(MSComm1.Input, 1)))

Regards,
Bob
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@153305 by Ken Pergola

flavicon
face

I wrote:

> bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))
> The 'vbUnicode' is not accepted.


Bob J wrote:

> It's not being accepted because the constant isn't defined.  Define the
> constant as public or just try replacing the constant with the value
> the constant represents, whatever that number or string really is...
> for example:
>
> bytUART_Byte = Asc((StrConv(MSComm1.Input, 1)))


Hi Bob,

Thank you for your reply. I realize what you say above because the VB6
intrinsic constant 'vbUnicode' does not appear to have an equivalent in
VB.NET's constant enumeration list for StrConv. It's not that simple in
VB.NET, but I appreciate you trying to help though. Look at VB.NET's StrConv
enumeration constants and you'll see what I mean.

Once again, the goal was to read a byte from the MSCOMM control and assign
it to a byte variable.

In VB6 you can do this to meet the goal:
----------------------------------------

bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))

In VB.NET, I'm not sure how to convert the above to accomplish the same
goal.
I thought the following might work:

bytUART_Byte = Asc(StrConv(frmForm1.DefInstance.MSComm1.Input,
VbStrConv.Narrow))

or

bytUART_Byte = Asc(StrConv(frmForm1.DefInstance.MSComm1.Input,
VbStrConv.None))


The project won't build: Option Strict On disallows implicit conversions
from 'System.Object' to 'String'.


The VB.NET upgrade wizard could not do it. I have not looked at James' link
in his recent post yet...I'll look at his link and keep hammering at this
now and then, or I'll go to a VB.NET newsgroup and will post a message here
if I get a solution to this.

Best regards and thanks Bob,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@171103 by Bob J

picon face
ahhh, I see what the problem is.  The input property is a variant type
in vb6.  So when you call it from vb.net the property is cast as an
object.  There is no such thing as a variant type in .net.  So, you
would do something like this (I havent't tried it but I think it will
work):

Dim temp As String
Dim objInput As Object
objInput = MSCOMM1.Input
temp = CType(objInput, Byte).ToString() (convert the object into a
byte array, then into a string)
bytUART_Byte = Asc(temp)

Regards,
Bob

bytUART_Byte = Asc(MSComm1.Input, vbUnicode)))

On Wed, 29 Sep 2004 15:33:09 -0400, Ken Pergola <spam_OUTno_spamTakeThisOuTspamlocalnet.com> wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@171359 by Bob J

picon face
Actually, this might work too:

bytUART_Byte = Asc(CType(MSComm1.Input,Byte).ToString())

Regards,
Bob

On Wed, 29 Sep 2004 15:33:09 -0400, Ken Pergola <.....no_spamKILLspamspam@spam@localnet.com> wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@193309 by Ken Pergola

flavicon
face

To: Bob J

Thanks for your suggestions Bob -- I'll give them a try. With Option Strict
off, what I tried compiled ok, but did not work. Obviously I want Option
Strict On, so I'll try your suggestions as well as James'. Thanks again for
your help and for your time. Now, time to experiment...

Much obliged,

Ken Pergola



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@203828 by Ken Pergola

flavicon
face

James Caska, Bob J, and others:
-------------------------------

>From the scouting around I'm doing on the web, it doesn't seem (to me at
least) that using the VB6 MSCOMM control in VB.NET is an elegant solution in
terms of licensing issues and xcopy deployment.

Richard Grier has a free control for .NET (NETCommOCX) that wraps the
functionality of the MSCOMM control, so this would be more seamless in
transitioning your old VB6 MSCOMM projects to the .NET platform than the
nice and free Sax control that I previously mentioned. I have not tried
Richard's control yet, but here is his web site link to it:

http://www.hardandsoftware.net/

Perhaps this will be of use to you both and others as well.

Best regards,

Ken Pergola




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@223403 by James Caska

flavicon
face
Hi Ken,

I still don't understand what the MSCOMM control has to do with the
vbUnicode conversion problem. Unless this new control has a vbUnicode
options built into it it won't help with the conversion problem. It might*
help with the licensing one.


James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\09\30@142956 by Mike Singer

picon face
Old Google gives yet another option:

Download details: Visual Basic .NET Code Samples: Master Set of ...
... language. Quick Info. File Name: 101vbnetsamples.exe. Download
Size: 6175 KB.
Date Published: 1/6/2003. Version: 1.0. Overview. This download ...
http://www.microsoft.com/downloads/
details.aspx?FamilyID=87951cb9-5aeb-4f46-9bf0-2b3e3664be77&displaylang=en
-

-----------------------------------------------------

One of these 101 samples:

"VB.NET - Framework - Using the COM Port in VB.NET"


-------

Regards,
Mike.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@144256 by Ken Pergola

flavicon
face

James Caska wrote:

> I still don't understand what the MSCOMM control has to do with the
> vbUnicode conversion problem. Unless this new control has a vbUnicode
> options built into it won't help with the conversion problem.


Hi James,

I'm sure it's just pilot error on my part. It just seems to be a matter of
coercion -- properly casting the MSCOMM's Input method under VB.NET -- I'm
still playing with this. I just downloaded Richard Grier's control. Have not
played with it yet. I'm sure your second sentence above is correct, but at
least the licensing issues are put at bay.

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@171431 by Paul Hutchinson

picon face
> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]On Behalf
> Of Ken Pergola
> Sent: Wednesday, September 29, 2004 3:33 PM
>
> bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))
>

I'm puzzled as to why you expand all received bytes to two byte Unicode
characters and then strip them back to one byte with Asc()?

>From my testing in VB6 simply using, bytUART_Byte = Asc(MSComm1.Input)
yields the same result.

Paul

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@195848 by James Caska

flavicon
face
Hi Ken,

Ok, so you've inspired me to have a look at this. If you look more closely
at the link I sent you earlier you will see that .NET has this system of
Encoding to translate between all the different formats

Looking at what you want to do..

bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))

So you are expecting some data coming in on the MSComm but you expect it in
unicode format. So you convert the whole buffer or least the read length on
the MSComm ( which I assume is 2 or you are happy to throw away data ) so
this takes the first 2 bytes of an N byte stream and converts it to a VB
Unicode internal string. The ASC takes the first character of this string
and produces a number in the unicode range, 0..65535

Ok.. So to achieve the same result in .NET

1) Make sure your MSComm control is set to comInputModeBinary, this makes
sure MSComm1.Input returns a Byte Array

MSComm1.InputMode = comInputModeBinrary

2) Make sure the Encoding object is referenced

Imports System.Text

3) declare bytUART_Byte as a char or cast to the appropriate range you are
after

dim charUART_Char as char
dim bytUART_Byte as byte

' bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))
charUART_Char = Encoding.Unicode.GetChars(AxMSComm1.Input())(0)
' OR
bytUART_Byte=(byte) Encoding.Unicode.GetChars(AxMSComm1.Input())(0)


You might need to fiddle a little pending what you are actually trying to do
but I tried it and it seemed to work.

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\09\30@202912 by Ken Pergola
flavicon
face

Paul Hutchinson wrote:

> I'm puzzled as to why you expand all received bytes to two byte Unicode
> characters and then strip them back to one byte with Asc()?

Hi Paul,

I did not want to regress to VB6 in this thread, but I'll answer your
question:

Well, the code I posted works fine under VB6 for years with InputMode =
comInputModeBinary.


> From my testing in VB6 simply using, bytUART_Byte = Asc(MSComm1.Input)
> yields the same result.

Well, it does not for me. The code line you posted produces on error:

"Invalid procedure call or argument (Error 5)"

Paul, how are you avoiding this same error in VB6? I don't see how you
cannot get the same error as I did using that line of code.

(bytUART is defined as: 'Dim bytUART as byte')

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@203110 by Ken Pergola

flavicon
face

Mike Singer wrote:

> One of these 101 samples:
>
> "VB.NET - Framework - Using the COM Port in VB.NET"

Hi Mike,

Thank you, but I saw that and downloaded that a while back.

Best regards,

Ken Pergola

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@205300 by Ken Pergola

flavicon
face

James Caska wrote:

> Ok, so you've inspired me to have a look at this. If you look more closely
> at the link I sent you earlier you will see that .NET has this system of
> Encoding to translate between all the different formats

Hi James,

Thanks very much for your time and effort. I need to break away at the
moment to watch the Kerry vs Bush debate, but as soon as I come back I'll
give your suggestions a try. I just wanted to respond right away to your
message to say "thank you". Once again, I really appreciate you taking the
time to reply in such detail. I'll let you know how things work out trying
this out with the VB6 MSCOMM control and Richard Grier's wrapped MSCOMM
control for .NET.

I'm sure a lot of other people are using the serial ports with PICs and
other microcontrollers. Hopefully this will help everyone out when they use
VB.NET (if they are having the same trouble porting existing VB6 code using
the MSCOMM control).

I feel pretty comfortable in VB6, but the .NET Framework is huge. It will
take a long time for me to get comfortable in .NET, but I'm very excited
about it though. VB.NET for example has some nice features that I'm looking
forward to. Interface inheritance and implementation inheritance looks
*much* simpler in VB.NET. I also like the strong type checking, and so many
other features.

Thanks again James for you help.

Best regards,

Ken Pergola





_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@224523 by Ken Pergola

flavicon
face

I wrote:

> Paul, how are you avoiding this same error in VB6? I don't see how you
> cannot get the same error as I did using that line of code.

Hi Paul,

I see the difference: your code only works if the input mode is set to
'comInputmodeText' -- it will render the error I mentioned in a previous
post if the input mode is set to 'comInputmodeBinary'.

My projects require 'comInputmodeBinary' -- that's why I use the code that
you found puzzling. I hope this clears things up for you.

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

'[EE] Serial port control under VB.NET 2002/2003'
2004\10\01@021121 by Ken Pergola
flavicon
face

James Caska wrote:

> Looking at what you want to do..
>
> bytUART_Byte = Asc((StrConv(MSComm1.Input, vbUnicode)))
>
> So you are expecting some data coming in on the MSComm but you
> expect it in unicode format. So you convert the whole buffer or
> least the read length on the MSComm ( which I assume is 2 or
> you are happy to throw away data ) so this takes the first 2 bytes
> of an N byte stream and converts it to a VB Unicode internal
> string. The ASC takes the first character of this string and
> produces a number in the unicode range, 0..65535

Hi James,

Actually, let me clarify because I see I caused some confusion (sorry about
that):

No, I'm just expecting single-byte raw binary data. I did not mention it
before, but the MSCOMM 'InputLen' property is set to 1, so I'm only reading
one byte from the UART each time I invoke the MSCOMM's Input method.
Technically, I probably should have done a byte cast in front of 'Asc', but
VB6 does an implicit conversion, and the code both compiles without error
and works.

So, the line above from the VB6 code just reads one byte from the UART and
assigns it to a byte variable (not a byte array).
No bytes in the UART are either lost or discarded -- everything works just
fine. I'm sorry I was not clear and explicit about this in my previous
posts.

It was just a simple polling program (no OnComm event was used in this
particular project although I have used it in others) because the
'RThreshold' and 'SThreshold' properties are set to 0:

  MSComm1.SThreshold = 0
  MSComm1.RThreshold = 0

In addition the MSCOMM mode was binary:

  MSComm1.InputMode = comInputModeBinary



Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@030255 by Ken Pergola

flavicon
face
part 1 740 bytes content-type:text/plain; (decoded 7bit)


I'm not sure if I have convinced anyone, so attached to this message is a
ZIP file of 'toy' VB6 code that proves that that the following 'vbUnicode'
conversion does not trash any bytes in the UART's buffer:

    bytUART_byte = Asc(StrConv(MSComm1.Input, vbUnicode))

After unzipping, just open the attached project in Visual Basic 6 and follow
the directions in the source code. Don't forget to loopback your serial port
(connect the Tx pin to the Rx pin). You'll see that 16 bytes were sent, and
the same bytes that were sent are received and display to you in
hexadecimal. The Unicode string conversion did not "eat" any bytes --
nothing is trashed or missing.

Best regards,

Ken Pergola



part 2 6852 bytes content-type:application/x-zip-compressed; (decode)

part 3 194 bytes content-type:text/plain; charset="us-ascii"
 (decoded 7bit)

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


part 4 2 bytes


2004\10\01@034518 by James Caska

flavicon
face
Ken,

What you probably want then is simply this..

.NET  ==================================

       Dim bytUART_Byte As Byte

       bytUART_Byte = MSComm1.Input()(0)

==================================

This is the same as

VB6 ==================================

Dim byteArray() As Byte
Dim bytUART_Byte As Byte

   byteArray = MSComm1.Input
   bytUART = b1(0)

==================================

I imagine the original version did it the other way to put it all on the one
line.

Hope this helps.

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\10\01@035022 by James Caska

flavicon
face
#Code Correction Resend

Ken,

What you probably want then is simply this..

.NET  ==================================

       Dim bytUART_Byte As Byte

       bytUART_Byte = MSComm1.Input()(0)

==================================

This is the same as

VB6 ==================================

Dim byteArray() As Byte
Dim bytUART_Byte As Byte

   byteArray = MSComm1.Input
   bytUART = byteArray(0)                '# << codecorrection here

==================================

I imagine the original version did it the other way to put it all on the one
line.

Hope this helps.

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@105422 by Paul Hutchinson

picon face
Hi Ken,

Ah I see now, your using the binary mode.

In the test program you sent to the list, if you change to text mode, the
test code works with the Asc() alone. This includes properly receiving and
decoding all possible byte values (0x00 to 0xFF).

I never use the binary mode of the MsComm control because I have never found
a circumstance where it did anything useful. The M$ help file implies that
you must use binary mode to receive control code characters however, I have
never found this to be true. The only practical effect I've ever found with
the binary mode is that it causes at lot of VB Err 5's when used with
classic DOS Basic derived code :). As a wild guess, maybe in early versions
of the Comm control, text mode was ASCII not ANSI. Then you would need
binary mode because ASCII is only 7bit. Since at least VB3 text mode has
been ANSI not ASCII.


If you really need binary mode, you can use this line.

bytUART_byte = Asc(MSComm1.Input & Chr(0))

When MSComm has a length of 1, "StrConv(MSComm1.Input, vbUnicode)" is equal
to "MSComm1.Input & Chr(0)". At least in VB6, running on a US english
version of Windows, it is.

Hope this helps,
Paul

> {Original Message removed}

2004\10\01@225756 by Ken Pergola

flavicon
face

Hi Paul Hutchinson and James Caska,

I did not want you to think I was an ingrate -- sorry for the long delay in
responding, but I owe you a 'thank you' for your replies. All I can really
report now is a sincere thank you to both of you -- both of you had some
very good ideas and code that was more elegant than mine.

Trying to help myself and possibly others in this thread, I'm still hung up
in VB.NET. I just wanted to compile that *simple* VB6 'toy' project that I
posted here a few messages back as a ZIP file. I'm still stuck, and need to
spend more time on it. It's one of those typical engineering things where
"it should be simple". I guess I have zero brain cells today. :)

I'm not really asking anyone to help or spend time on this, since it is my
problem, but I thought I should post some details out of courtesy to your
replies:


{Quote hidden}

As far as that VB.NET line you suggested does not compile:

  bytUART_byte = MSComm1.Input()(0)


Build error: Option Strict On disallows late binding.


Just as a quick experiment, I used the VB.NET upgrade wizard to convert that
'toy' VB6 code project I posted earlier as a ZIP file. I figured it would be
an easy program for the upgrade wizard to convert, but no luck so far.

VB.NET compiles the 'MSComm1.Output = Chr(lngCount And 255)' line without
error (using Option Strict On, Option Explicit On), but when I run the
program, I get the following error:

  Error 380 - Property value is not valid

So, I'll have to go back to drawing board to see why the MSCOMM output
method is not working for me. Like you mentioned earlier, it looks like I'll
have to dig into the encoding/decoding conversions you mentioned previously
(and other suggestions in this thread). Everything in that 'toy' VB6 project
seems to work ok except for the MSCOMM's 'Input' and 'Output' methods, so
it's *very* close. Like I said, I do have a solution with the Sax control,
but I would like to resolve this and place the information in this thread
for the benefit of others.

Thanks again for your time and for your help James and Paul -- I definitely
appreciate it.

Best regards,

Ken Pergola








_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@234605 by James Caska

flavicon
face
Ken,

If you have Strict Mode on then you will need to explicity cast the Input to
a Byte Array. I think someone said something like this earlier also.


 Dim bytUART_Byte As Byte

 bytUART_Byte = CType(AxMSComm1.Input(), Byte())(0)



Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\10\02@003954 by Ken Pergola

flavicon
face

James Caska wrote:

> If you have Strict Mode on then you will need to explicitly cast
> the Input to a Byte Array. I think someone said something like this
earlier also.
>
>
>   Dim bytUART_Byte As Byte
>
>   bytUART_Byte = CType(AxMSComm1.Input(), Byte())(0)


Hi James,

Thanks kindly James -- yes that's it. I don't quite understand it yet, but
I'll have to research the CType and read up on it. The '(0)' suffix gives me
a buzz cut -- not sure what that is doing. Any chance you can point me to a
link that describes that?

In any event, the simple project showing how to use the MSCOMM control in
BINARY mode under VB.NET works. Thanks to all who helped me out to convert
the simple demo MSCOMM project to VB.NET. We have thread closure.

I wanted to post the zip file of the VB.NET project in this post for the
benefit of anyone who is interested, but the file size is 54 kilobytes --
rather large for the PICList -- I don't want to upset anyone, but if the
PICList administrators say it's ok, I'll post it as an e-mail attachment.

Thanks for everyone's help and time. You all are very kind -- and patient!

Much obliged,

Ken Pergola




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@021416 by Ken Pergola

flavicon
face

Important to keep in mind during debugging:

"You may lose data unexpectedly when you debug the Input property of the
MSComm control in Visual Studio .NET"

http://support.microsoft.com/default.aspx?scid=kb;en-us;327362

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@145701 by James Caska

flavicon
face
Hi Ken,

>   Dim bytUART_Byte As Byte
>
>   bytUART_Byte = CType(AxMSComm1.Input(), Byte())(0)

VB.NET is now a 'true' object orientated language like java or C#.

Lets break it down..

AxMSComm1.Input() returns an Object which is actually a System.Array object
which is actually an array of Bytes.. If you think of it in terms of say
pointers Object -> System.Array -> Byte() -- this is conceptual not literal
but it should help think 'object's

So if we think about what the underlying .NET Virtual Machine is doing by
replacing the AxMSComm1.Input() we can see

Eval 1:  bytUART_Byte = CType( Object -> System.Array -> Byte() , Byte())(0)

Ok. So now what Ctype( object, Type) does it to convert or cast, or really
in this case traverse the pointer heirachy looking for the matching Byte()
array that we are interested in so it basically trims off the
Object->System.Array   and just returns the Byte Array Byte()

Eval 2: bytUART_Byte = Byte()(0)

So now you can more easily see what the (0) is.. It is the zeroth index into
the Byte Array


This is equivalent to this code

  Dim InputObject as Object
  Dim InputByteArray() As Byte
  Dim bytUART_Byte as Byte

       InputObject    = AxMSComm1.Input()
       InputByteArray = CType(AxMSComm1.Input(), Byte())
       bytUART           = InputByteArray(0)

So to understand physically what is happening..

Say you send 'HI' on the serial connection you can imagine the Serial
InputBuffer having

MSComm.InputBuffer = {'H','I'}

Now because you are settings are to read only a single byte at a time,
executing AxMSComm1.Input() returns only a single element array, and leaves
the other byte in the InputBuffer for next time

--
InputObject    = AxMSComm1.Input()

MSComm.InputBuffer = {'I'}
InputObject        = Object->System.Array->ByteArray->{'H'}

--

So now you only have an Object reference but you want to get access to the
ByteArray so this is where you you CType

InputByteArray = CType(AxMSComm1.Input(), Byte())
Which gives
InputByteArray = Byte(){'H'}

--

So Finally you want to get the first ( and only ) element from this array
and keep it as bytUART_Byte

byteUART           = InputByteArray(0)

Which gives

byteUART = 72 ' 'H' = 72


Hope this helps :-)

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\10\02@153453 by Ken Pergola

flavicon
face

James Caska wrote:

> VB.NET is now a 'true' object orientated language like java or C#.

Hi James,

Yes, I know -- truly exciting times for Visual Basic developers. I currently
have Franceso Balena's "Programming Microsoft Visual Basic .NET" tome and
have been fascinated by the improvements over Visual Basic 6. I think that
one thing that Visual Basic .NET does not have is mutiple class inheritance,
but unless I'm mistaken, I think that that is due to the current
implementation of the .NET Framework, so all .NET languages are subject to
this restriction.

> Lets break it down..
> Hope this helps :-)

Yes, it definitely does James. Thanks for taking the time to write that
explanation by breaking things down to concise details -- it was very
helpful. I appreciate your help and the time taken to write your response.

Thank you,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...