transmit bmp via MSComm control
William Mounts
Does anyone know how to transmit a bmp file via MSComm.Output, or similar?
I have tried doing it by opening a file (binary mode), and sending it one
byte at a time, and building a file at the other end, but I always end up
with a file exactly 4 bytes larger that the on with which I started, and I
cannot open the transmitted file as a bmp.
HELP!!!
Bill Mounts
Vin D'Agostino
is the receiving mscomm control in text or binary mode?
and do you use an array for the receive?
are you processing incoming bytes with the _oncomm event, the input
_threshold event?
is the offset the same for all file sizes? even a 10 byte file?
William Mounts <wmo...@erols.com> wrote in message
news:u0gQCu0G$GA....@cppssbbsa02.microsoft.com...
William Mounts
I have tried the receiving control in both text and binary....same result.
At the moment, I am using a string for the receive (it's a 182 byte bmp, or
a 194 byte bmp). The offset is the same for both.
The offset is not in the string when it is received, i.e., the string length
is the same as the one sent. (I discovered this right after posting this
message last night). The offset is at the beginning of the file.
In effect, what happens is that I open a file in binary at the sending comm,
and open a second file in binary at the receive comm, and then send a byte
at a time. When I close the receive file, it "pre" appends 4 bytes.
As to the last question, I have been using the threshhold event.
Thanks,
Bill
Vin D'Agostino wrote in message <7uma7j$6mt$1...@nntp2.atl.mindspring.net>...
Vin D'Agostino
This sounds a bit odd. Can you send me a small section of code or a small
project I can run on two machines here in my lab? I'll check it out.
B4 u do that, though, just to be sure, implement it with 0 threshhold and
poll the input. Then you will get a byte at a time. It would make more sense
if the received file was SMALLER, because that would indicate that the last
block from the transmitted machine was smaller than the thresh value.
William Mounts <wmo...@erols.com> wrote in message
news:#p5ew#7G$GA.257@cppssbbsa04...
Richard Grier
It sounds like you may be using Variant data types at some point (do not do
this). Set the InputMode property to comInputModeBinary, and use arrays to
type Byte to buffer transmit and receive data. There should be no
difference between sending and receiving files.
One thing that you can do (that is equivalent) that may be easier is to use
XMComm that you can download from my homepage. It implements XMODEM file
transfers. The only problem is that XMODEM packs data to 128 byte
boundaries. That means that the receive file will (usually) have extra data
(Chr$(26) by default) appended to the end, to pad the file to the 128 byte
boundary. You can easily truncate the file to the actual length by simply
communicating that length as part of the protocol that you implement to do
the send.
I have lots of working examples of serial code in my book that may be of
help, including the source code for the XMComm ActiveX control. See below
for information.
--
Richard Grier
Hard & Software
12962 West Louisiana Avenue
Lakewood, CO 80228
303-986-2179 (voice)
303-986-3143 (fax)
Author of Visual Basic Programmer's Guide to Serial Communications, 2nd
Edition (355 pages).
For information look on my homepage at http://www.hardandsoftware.net.
Use the Books link to order. For faster service contact the publisher at
http://www.mabry.com.
Richard Grier
>>
When I close the receive file, it "pre" appends 4 bytes
<<
This still sounds like there is a Variant data type somewhere in the mix.
Without seeing your code, it is hard to do more analysis.