|
Are you specifying the FILE_FLAG_OVERLAPPED flag in CreateFile()..?
|
|
|
|
|
Ummm, I guess you replied to the wrong guy... 
However, specifying the flag for overlapped mode doesn't make a difference regarding "flushing" the receive buffer in the serial driver.
On the other hand, overlapped mode should be used in any case.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
To be more specific :
The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.
Thanks !
|
|
|
|
|
kapardhi wrote: The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
You actually mean that you have no idea, and cannot predict, what settings the device uses on start up? I find that very hard to believe, because it means that the device is uninitialized and hence should not be able to communicate at all.
Usually a device that supports multiple communication settings starts off with a known configuration; e.g 300 baud, 1 stop bit, no parity. Then the host negotiates with the device about a new configuration through a known protocol.
If you don't know anything about this device, you would be better off using an oscilloscope to find out what configuration is used.
But even if you find out what configuration is being used, you still have to know the protocol, which I suspect can be found at the same place as where the communication settings are documented.
The alternative is to set a timeout using ::SetCommTimeouts() to let the timeout of the read operation expire when the hardware hasn't received a new byte within e.g. ten byte times. Then it's reasonable to assume that you've received all data the device wants to send and you can continue and try another configuration.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Sorry u are misunderstanding me !
Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.
now lets assume one of the user have changed the device baud rate to 115200, with even parity, 6 databits 2 stopbits.
now i donot know the configuration of the connected device, so i have to change my COM port settings and send command for all combinations of baudrate, parity etc in order to communicate with the device.
when i get the correct/expected response i can conclude that this is the combination of the device!
i am also using CommTimeOuts !
Thanks !
|
|
|
|
|
kapardhi wrote: Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.
Why is this option offered to the user?
Is it because the application communicates with different kind of devices with different communication settings?
IF the application connects to different devices, doesn't one particular device start up with the same settings as the last time, i.e. is it not predictable?
If it is predictable, why not let the user choose from a list of device types that corresponds to the communication settings instead of giving him the possibility to change all settings and thus create this problem for you, the application, the device and himself?
My point is that the settings in the device should be the same every time it starts. If the user knows what kind of device it is, the application should know what configuration to use in order to communicate with that kind of device. It's your responsability as developer to make this mapping and if you don't think it is, then the user could use HyperTerminal, PuTTY or similar.
kapardhi wrote: i am also using CommTimeOuts !
But probably the wrong way, or with the read timeout too short, since you clearly have not received the complete answer. Otherwise you would not have posted this thread in the first place.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I can see this being very fragile [*]
What if you see the first part of the response, act on that, clear the buffer, but the rest of the response is still coming in?
You could clear the buffer too early. What do you do with the junk data?
If you wait for it to be quiet, you will add long delays.
If you wait till the right amount of data has come in, you don't need to flush.
I really struggle to see you needing to do this, unless your protocol is broken. If it's designed by someone else, then it's probably fine and you need to change your code. If it's designed by you, then you may need to go back and change the protocol *then* your code.
I've had similar issues with Pipes and sockets with varying data-lump-sizes, and solved it by having a header value specifying how many further bytes are in this lump of data. Simple but works well. Whether you pay attention to the whole data-lump or not, it's wise to read it all in. Feel free to throw it away.
Good luck,
Iain.
[*] A euphemism meaning it will fail within 2 minutes of someone else using it.
|
|
|
|
|
To be more specific :
The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.
Thanks !
|
|
|
|
|
Are you perchance in search of PurgeComm[^]?
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
PurgeComm clears the buffer of the device's driver, i want to clear the buffer of the Serial COM port of my computer !!
|
|
|
|
|
kapardhi wrote: PurgeComm clears the buffer of the device's driver, i want to clear the buffer of the Serial COM port of my computer !!
Which part of (the first sentence in the link)
Discards all characters from the output or input buffer of a specified communications resource
is unclear? A COM port is a communications resource. The buffers for a comm resource are maintained by the device driver for that resource.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
hi all
i want to create a .DBX file having some mails.
can anybody tell me how to create a .DBX file(MS-OUTLOOK EXPRESS)
using vc++ 6.0
Thanks in advance.
|
|
|
|
|
I have a handle to bitmap. I need to store this bitmap to a xml file. The xml file will be read on a mac system.
So how do I create a DIB from a HBITMAP?
Thanks..
|
|
|
|
|
|
That is not what I require. Not from a file. I already have a HBITMAP from the file. I need a logic that converts a HBITMAP to a DIB, which will be readable on a mac system.
|
|
|
|
|
2. Use CreateDIBSection to create an image of the correct size
3. Create a couple of memory DCs
4. Select the images into their own DCs
5. BitBlt from the DC holding the HBITMAP to the one containing the DIBSection
6. Save the DIBSection to disk (you can use the supplied function)
7. Deselect the images from their DCs
8. DeleteObject both images (HBITMAP & DIBSection)
BOOL SaveBitmapFile(HDC p_hDC, LPCTSTR p_pchFileName)
{
HBITMAP hBmp = (HBITMAP)GetCurrentObject( p_hDC, OBJ_BITMAP );
BITMAPINFO stBmpInfo;
stBmpInfo.bmiHeader.biSize = sizeof( stBmpInfo.bmiHeader );
stBmpInfo.bmiHeader.biBitCount = 0;
GetDIBits( p_hDC, hBmp, 0, 0, NULL, &stBmpInfo, DIB_RGB_COLORS );
ULONG iBmpInfoSize;
switch( stBmpInfo.bmiHeader.biBitCount )
{
case 24:
iBmpInfoSize = sizeof(BITMAPINFOHEADER);
break;
case 16:
case 32:
iBmpInfoSize = sizeof(BITMAPINFOHEADER)+sizeof(DWORD)*3;
break;
default:
iBmpInfoSize = sizeof(BITMAPINFOHEADER) +
sizeof(RGBQUAD) * ( 1 << stBmpInfo.bmiHeader.biBitCount );
break;
}
PBITMAPINFO pstBmpInfo;
if( iBmpInfoSize != sizeof(BITMAPINFOHEADER) )
{
pstBmpInfo = (PBITMAPINFO)GlobalAlloc( GMEM_FIXED | GMEM_ZEROINIT, iBmpInfoSize );
PBYTE pbtBmpInfoDest = (PBYTE)pstBmpInfo;
PBYTE pbtBmpInfoSrc = (PBYTE)&stBmpInfo;
ULONG iSizeTmp = sizeof( BITMAPINFOHEADER );
while( iSizeTmp-- )
{
*( ( pbtBmpInfoDest )++ ) = *( ( pbtBmpInfoSrc )++ );
}
}
HANDLE hFile = CreateFile( p_pchFileName, GENERIC_WRITE, 0,
NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_ARCHIVE,
NULL );
BITMAPFILEHEADER stBmpFileHder;
stBmpFileHder.bfType = 0x4D42;
stBmpFileHder.bfSize = sizeof(BITMAPFILEHEADER)
+ sizeof(BITMAPINFOHEADER)
+ iBmpInfoSize
+ pstBmpInfo->bmiHeader.biSizeImage;
stBmpFileHder.bfReserved1 = 0;
stBmpFileHder.bfReserved2 = 0;
stBmpFileHder.bfOffBits = sizeof(BITMAPFILEHEADER) + iBmpInfoSize;
DWORD dRet;
WriteFile( hFile, (LPCVOID)&stBmpFileHder , sizeof(BITMAPFILEHEADER), &dRet, NULL );
PBYTE pBits = (PBYTE)GlobalAlloc( GMEM_FIXED | GMEM_ZEROINIT, stBmpInfo.bmiHeader.biSizeImage );
HBITMAP hBmpOld;
HBITMAP hTmpBmp = CreateCompatibleBitmap( p_hDC,
pstBmpInfo->bmiHeader.biWidth,
pstBmpInfo->bmiHeader.biHeight );
hBmpOld = (HBITMAP)SelectObject( p_hDC, hTmpBmp );
GetDIBits( p_hDC, hBmp, 0, pstBmpInfo->bmiHeader.biHeight,
(LPSTR)pBits, pstBmpInfo, DIB_RGB_COLORS );
WriteFile( hFile, (LPCVOID)pstBmpInfo, iBmpInfoSize, &dRet, NULL );
WriteFile( hFile, (LPCVOID)pBits, pstBmpInfo->bmiHeader.biSizeImage, &dRet, NULL );
SelectObject( p_hDC, hBmpOld );
DeleteObject( hTmpBmp );
CloseHandle( hFile );
GlobalFree( pstBmpInfo );
GlobalFree( pBits );
return TRUE;
}
|
|
|
|
|
Thanks for your reply.
Do you think writing the DIB to a xml file and reading back and displaying it will actually display it?
|
|
|
|
|
Do you think writing the DIB to a xml file and reading back and displaying it will actually display it?
Well that is the tricky part - it is important to choose what kind of DIB you want, so you can read it latter on Mac:
- choose how many colors
- by default DIB is bottom-up. If Mac can't read it put negative height in DIB
- if Mac can read .bmp, consider writing the file in .bmp rather .xml (this will greatly reduce file size and writing routines to read .xml)
Good luck.
|
|
|
|
|
My pleasure.
Sure, writing a bitmap to an XML file will work, it'd just be more work than saving the DIBSection to a BMP file (the code supplied will create a BMP file)
You'll be able to open the created file with photoshop or any other image program that supports BMP. I wrote the code from scratch, the BMP format is really fairly simple. Just use your preferred method, either would work.
|
|
|
|
|
I cant use a bmp file, because bmp is not the only info I need to send to the mac. I want to club whole info into a single xml file, transfer it, and then disintegrate it on the mac. 
|
|
|
|
|
What image format does the bitmap need to be in for the Mac to read it?
It seems to me there's three steps here:
1) Write the DDB to an image stream in some Mac-recognizable format
2) Send the stream bytes via XML
3) Extract the byte stream into an image
Which part is giving you trouble?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
The first part.
1) Write the DDB to an image stream in some Mac-recognizable format
I thought of writing the BITMAP structure field by field to the xml, including the color bits(pBmBits field). I convert this bmbits field to string before writing. Somehow the size of the xml file after writing the image data increases to 6MB, while the image is only 66KB.
Is it OK to convert it to string before writing?
How can I convert it to a stream?
|
|
|
|
|
ThisIsMeRon wrote: Write the DDB to an image stream in some Mac-recognizable format
What would that format be?
Do you need to break apart the bitmap and just send basic info like
height, width, bits-per-pixel, and the pixel bits?
Or can you send a stream of a "universal" image format like TIFF, JPEG, etc.
(the Mac probably reads BMPs fine as well I would think).
66K to 6MB .... definitely something wrong there 
Even if you send a base64 representation of the binary data, you should
only see an increase of 33%.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Use the CopyImage function.
HBITMAP DIBBitmap = CopyImage(DDBBitmap, IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION)
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Hi,
I will like to know which C++ compiler implements the most complete C++ and STL Specification/Standards as of today?
Also what is the state of latest C++0.x specification (as of today) and conformance of the current compilers?
Thanks and Regards
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
