VB6 MSCOMM wroks on one PC and not another

[T.Jackson]

What do you have the attribute InputLen set to?

[cooksydesign]

Thanks for the responce. Input Length is set 0.

I have since sent the input string to a label, visable property set to false, and so far every test I have done, not extensive mind you but progress, has been successful. I don't why the program operates better this way, timing I'm guessing.

If InputLen should be something other than 0 please let me know. The input length is variable, no telling how many characters.

Thanks again for the interest.

B

[T.Jackson]

Thanks for the responce. Input Length is set 0.
If InputLen should be something other than 0 please let me know. The input length is variable, no telling how many characters.

For Win XP & 2K2 you definitely want InputLen set to anything other than 0. I lost some hair a few years back when I wrote a piece of software for a serial io controller, worked fine on 9x with InputLen set to 0, but refused to work on XP until I changed it to equal 1.

[cooksydesign]

Again, thanks for the interest in my post. Changing the receive length property to 1 did not do any good. I think that tells MSCOM buffer what to expect. If the incoming string was a fixed length it may have helped. I seem to have sorted it out by sending the string to a label first, then work with the data. It has not failed since I started doing it that way. I realize this is a work around, and the true cause is not identified. If there are other suggestions, I will most certainly try them.

Regards.

B

[mister_e]

I no longer use MsComm and VB6, i use VBExpress or .Net. From there you can also use the LF interrupt events (comport.ReadLine) which is probably the way to go. Never ever failed for me 'till now. VB6 EOF event is one method... if you can make it work.

LF event... way easy to code on the PIC side... hserout [whatever, 10]

There's a lot of different way to have success with VB, i have some applications dealing with MBs and GBs of data transfer... problem-free since years now. Even in VB6.

I prefer the handshaking method... hardware or software.... and a preamble string never bite anyone yet.

[tenaja]

The new Visual Basic.NET 2008 is so much better than 6 that you shouldn't waste your time trying to get it to work.

[T.Jackson]

Incidentally, I just discovered that Microsoft has continued support for VB6 until the 31st of march this year. They initially terminated support back in 2005, there is obvioulsy still a considerable amount of programmers developing in it. Also, all of the latest operating systems come shipped with VB6 run times! (bet ya didn't know that) This includes Vista.

Expect to be able to run all of your VB.com applications on operating systems well into the next decade! VB6 is far from finished.

[T.Jackson]

The new Visual Basic.NET 2008 is so much better than 6 that you shouldn't waste your time trying to get it to work.

It's a very painful transition from VB.com to VB.net, particularly for programmers with 10+ years background with .com (like learning to walk all over again) and a lot of people are refusing to exchange their expertise for a "start from scratch experience", because that's pretty much what it is.