|
while(byteCount > 0){
byteCount = server->Receive( bytes, bytes->Length, SocketFlags::None);
}
ambot->Write( bytes, 0, bytes->Length );
In the above lines you may be overwriting part of your image in the while loop, which means that you only write the last part of the file. You are also using the buffer length rather than the actual bytecount to write to the destination file.
|
|
|
|
|
There are two major flaws AFAICT:
1. you have a receiving loop that overwrites the receiving buffer, whereas your file writing is outside the loop; the correct way would have both receive and write in one loop, there is no need to first hold the entire image in memory.
2. you write a fixed length, independent of what you received. That is so wrong; your write statement needs to be based on the byte count you obtain from the receive statement.
And there is another weakness, if not a bug: you assume the header will hold 224 bytes. What if it doesn't? It is not up to the client to guess how big a header the server will use. Check the standards, or use an official implementation (if this is managed C++, why not use HttpWebRequest/HttpWebResponse classes?).
PS: please learn how to apply proper formatting, using PRE tags[^].
modified 11-Oct-11 12:27pm.
|
|
|
|
|
|
Please edit the above message and use PRE tags, so I can look at it tomorrow.
|
|
|
|
|
int SendReceiveTest2( Socket^ server )
{
FileStream^ ambot = File::Open("pastilan.jpg", FileMode::Create, FileAccess::ReadWrite);
array<Byte>^ msg = Encoding::ASCII->GetBytes("GET /snapshot.cgi HTTP/1.1\r\n");
array<Byte>^ msg1 = Encoding::ASCII->GetBytes("Authorization: Basic YWRtaW46\r\n\r\n");
array<Byte>^ header = gcnew array<Byte>(224);
array<Byte>^ bites = gcnew array<Byte>(1);
try
{
int byteCount = server->Send( msg );
Console::WriteLine( "Sent {0} bytes.", byteCount.ToString() );
int byteCount1 = server->Send( msg1 );
Console::WriteLine( "Sent {0} bytes.", byteCount1.ToString() );
byteCount = server->Receive( header, header->Length, SocketFlags::None );
if ( byteCount > 0 )
{
Console::WriteLine( Encoding::UTF8->GetString( header ) );
}
int count = 0;
while(1){
byteCount = server->Receive( bites );
ambot->Write(bites,0,1);
if (byteCount == 0)
break;
}
if( ambot )
delete (IDisposable^)ambot;
}
catch ( SocketException^ e )
{
Console::WriteLine( "{0} Error code: {1}.", e->Message, e->ErrorCode.ToString() );
return ( e->ErrorCode );
}
return 0;
}
|
|
|
|
|
oh my.
1.
you could have edited the existing message to adapt its formatting, rather than create yet another one, there is an edit widget below each of your posts for you to do so.
2.
when I said you needed to receive and store in a loop, and use the right amount of bytes, I did not imply to deal with one byte at a time; rather something like:
for(;;) {
byteCount = server->Receive( bytes, bytes->Length, SocketFlags::None);
if (byteCount<=0) break;
ambot->Write( bytes, 0, byteCount );
}
The performance difference should be quite noticeable.
3.
I'm still not sure about your header, which you are basically swallowing (i.e. showing as if it were text?????, then forgetting). Is it part of the communication, or is it the header part of the image (which you would need to include in the file)?
And is the camera emitting a JPEG format? Most camera's do, if so the very first bytes are likely to be FF D8 FF (these are three bytes represented in hex, not as text characters!), and most likely the bytes 6 through 9 contain 4A 46 49 46.
So check the incoming data (including your "header") for these values: either use a hex editor to see your resulting JPEG file, or adapt your code so you can see the first 10 bytes (in hex) for both the header and the first (or every) data packet you receive. Alternatively, try your code without the receive-and-show-header statements.
OTOH, if the camera does not generate JPEG, storing some other format into a file and give that a JPEG extension is not the way to convert image formats!
|
|
|
|
|
Oh, by the way, i just displayed the two sets of (jibberish) characters to demonstrate the difference in encoded data that results. The proper set of characters is the second one. I don't know where the first one comes from.
|
|
|
|
|
Member 8250612 wrote: Proper jpeg files have characters that look like this:
*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³
no, they don't.
well, let me rephrase that: nothing in the JPEG spec requires such a sequence of bytes. you might get an image which encodes to that, but that's entirely coincidental.
the most you can say about a JPEG is that it probably starts with these three bytes: FFD8FF. beyond that, the only constant is the structure defined by the file format; and that works with little four-byte headers which precede the various blocks of data and none of those blocks is required to look like that.
modified 11-Oct-11 15:58pm.
|
|
|
|
|
Have you tried asking this question in the Managed C++ forum?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I've been trying to make my Window pretty or appealing, by setting a bitmap in the background of the window. The information I have found is mostly just do this, and it works, I came up with this, and placed it in my WM_PAINT. At first I got a little TT logo at the upper left, then it went away, I thought it was going to work.
I have triple checked my IDB_BG_INSTALL_PANE_BMP, and I know I got that right.
HDC mem_DCInstallation;
HBITMAP bmp_BGInstallation;
hdc = BeginPaint(cWnd, &ps);
bmp_BGInstallation = LoadBitmap(hIIS_Instance, MAKEINTRESOURCE( IDB_BG_INSTALL_PANE_BMP ));
mem_DCInstallation = CreateCompatibleDC(hdc);
SelectObject(mem_DCInstallation, bmp_BGInstallation);
BOOL bbResult;
bbResult = BitBlt(hdc, 0, 0, 500, 311, mem_DCInstallation, 0, 0, SRCCOPY);
DeleteDC(mem_DCInstallation);
DeleteObject(bmp_BGInstallation);
|
|
|
|
|
Do your background bitmap painting by handling the WM_ERASEBACKGROUND[^] message
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
So I want to paint in that message event?, or just add it and put the return TRUE or FALSE?
|
|
|
|
|
OK, I get it,I mad the WM_ERASEBKGND return 1, doesn't seem to matter yet what I set it to, and fixed the code I posted. I messed it up from trial and error, and left off at error.
This is the correct code
bmp_BGInstallation = LoadBitmap(hIIS_Instance, MAKEINTRESOURCE(IDB_BG_INSTALL_PANE_BMP));
mem_DCInstallation = CreateCompatibleDC(hdc);
SelectObject(mem_DCInstallation, bmp_BGInstallation);
BitBlt(hdc, 0, 0, 504, 331, mem_DCInstallation, 0, 0, SRCCOPY);
DeleteDC(mem_DCInstallation);
DeleteObject(bmp_BGInstallation);
Thanks for pointing out the WM event, I remember reading it somewhere earlier, but forgot about it.
Say, 1 more question, if I create a larger bitmap of the same image, would windows automatically size it down, so I can resize the window larger, without losing image quality?
|
|
|
|
|
jkirkerx wrote: if I create a larger bitmap
In that case you would probably need to use StretchBlt()[^].
|
|
|
|
|
It took me awhile to understand the process, but as a by product, I learned how to create regions in the window, and paint them, and they work in the resize event as well.
I'll try the above suggestion first, before trying the below dll integration.
Thanks for the help, the information is out there, but I'm not using the right words to find it.
|
|
|
|
|
jkirkerx wrote: the information is out there, but I'm not using the right words to find it.
Sure, this is a fairly obscure part of Windows programming, most people just use the default background. But, it sounds like you are getting there.
|
|
|
|
|
I got it!, just finished. I doubled the size of the artwork, and just used a PNG file, and it loaded. Messed around with the numbers, and mode, came out great!.
I also made my Textout dynamic as well, but I ran into an math warning, I tried (double).38, but still got the error.
Anyways, Thanks for the pointers, I get this feeling that what I'm doing is old school, and that folks moved on to MFC or something.
warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
TextOut(hdc, clientRect.right * .38, clientRect.bottom * .03,
L"IIS Webserver Installation",
_tcslen(L"IIS Webserver Installation")
);
// My new Code
GetClientRect(cWnd, &clientRect);
hRegion1 = CreateRectRgn(clientRect.left, clientRect.top, clientRect.right, clientRect.bottom - 57);
hBGBrush1 = CreateSolidBrush(RGB( 255, 255, 255 ));
FillRgn(hdc, hRegion1, hBGBrush1);
hRegion2 = CreateRectRgn(clientRect.left, clientRect.bottom - 57, clientRect.right, clientRect.bottom);
hBGBrush2 = CreateSolidBrush(RGB( 25, 25, 25 ));
FillRgn(hdc, hRegion2, hBGBrush2);
bmp_BGInstallation = LoadBitmap(hIIS_Instance, MAKEINTRESOURCE(IDB_BG_INSTALL_PANE_PNG));
mem_DCInstallation = CreateCompatibleDC(hdc);
SelectObject(mem_DCInstallation, bmp_BGInstallation);
SetStretchBltMode(hdc, COLORONCOLOR);
StretchBlt(hdc, 0, 0, clientRect.right, clientRect.bottom - 57, mem_DCInstallation, 0, 0, 1008, 612, SRCCOPY);
DeleteDC(mem_DCInstallation);
DeleteObject(bmp_BGInstallation);
|
|
|
|
|
TextOut(hdc, clientRect.right * .38, clientRect.bottom * .03,
The warning(s) come because you are calculating a double (i.e. floating point) value (.right * .38) and then using it in a place where an integer is required, so the automatic conversion to integer may lose some precision. You may wish to modify your code to use integer values only; see the documentation for TextOut()[^].
|
|
|
|
|
You may have a look at my DLL[^] if you need to resize the image without loosing too much quality.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
That DLL will come in handy in phase 2 of my project, I'm bookmarking so I can find it at the end of the month.
Thanks for looking at my post!
jkirkerx
|
|
|
|
|
Hey folks!
I am trying to find out if a DC supports AlphaBlend or not. I used GetDeviceCaps[^] with SHADEBLENDCAPS and checked for the SB_CONST_ALPHA flag, however, it seems like it happens that the DC doesn't return this flag BUT AlphaBlend[^] still succeeds on it (and produces the expected result). Am i using GetDeviceCaps the wrong way? Is this not the way to check for the support? Is GetDeviceCaps simply not reliable?
Thanks for any answers in advance.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
How did you test for this - as a value or bit mask?
|
|
|
|
|
Bit mask:
bool DCCanBlend = ((dc.GetDeviceCaps(SHADEBLENDCAPS) & SB_CONST_ALPHA)?true:false);
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Check the remarks section here[^].
|
|
|
|
|
Thanks for your reply. As i also said to Randor, my DCs are for printers, but to avoid vasting ink and paper i am -at least initially- working with virtual printers which print to a file like PDF. Can be that these work as screen DCs and not printer DCs, i will check into that (using GetDeviceCaps and TECHNOLOGY) and "report back".
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
