If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: [win32] Send bitmap over socket

Originally Posted by DaigonoYouso

the way you reply,

And what is "the way"? You asked a question, I answered it. What are you expecting as a reply?

Where in any of my responses do you see violence even suggested against you? I even took the time to show you where your memory leak was and how to fix it. Do you still want to "punch in the face with a chair"?

I didnt threat you nor harassed you in any way

Punching in face with a chair -- ok, that is not harassment or threatening.

And you expect others to help you with the likelihood of being given a response like that?

Re: [win32] Send bitmap over socket

Originally Posted by Paul McKenzie

And what is "the way"? You asked a question, I answered it. What are you expecting as a reply?

Where in any of my responses do you see violence even suggested against you? I even took the time to show you where your memory leak was and how to fix it. Do you still want to "punch in the face with a chair"?
Punching in face with a chair -- ok, that is not harassment or threatening.

And you expect others to help you with the likelihood of being given a response like that?

Regards,

Paul McKenzie

I fixed the leak before I saw it here, but that doesnt matter, thank you, this was like the first time ever you were useful to me

also, did I punch you, or did I said that I feel like that? punching and feeling like that are 2 totally different things, just as trying to help and helping, u know?

when I recreate the bitmap in the client, it works (using "pbi" and buff I created before), however, I don't know how to recreate LPBITMAPINFO on the server, after I send it from the client, code to recreate bitmap with pbi and buff:

1. set DATA buffer size to size of struct
2. receive data
3. copy bitmapinfo properties from buff and set them to pbi
4. set bInfo to false, since Im not gonna get bInfo next, but that second thing
5. delete buff

if bInfo is false, I'm getting the second thing, so:

1. set DATA imageBuff size to size of image, since we got that one before
2. receive data and store them in buffer
3. copy buffer to imagebuff, so we can recreate the bitmap
4. set bInfo to true, since im gonna get bitmapinfo next
5. delete buff

I'm getting std::bad_alloc here (after I get the second thing, bitmapinfo is fine if I remember right)

edit: I'm sending both, bitmapinfo and the second thing, however with debug points I discovered that it goes to memcpy 3 times (it is supposed to do only once, since I'm sending only 1 bitmap so far), and I get bad_alloc on the third time (it's getting bitmapinfo second time)

Re: [win32] Send bitmap over socket

I still somehow can't manage to retrieve the bitmap properties, sending code:

Maybe it would be better to send

1) BITMAPINFO struct data
2) The number of bytes that the image data in step 3) consists of
3) The actual image data.

Then on the receiving side, receive the information exactly in this way. Since BITMAPINFO is the same size, you don't need to specify the size on the send, but the bitmap data can vary, so it is easier to first send how much data is being sent, and then the actual data (to me, this would be easier, others may differ).

Also, I suggest you use std::vector<BYTE> instead of new[]/delete[]. Doing so will remove most, if not all of the std::bad_alloc() errors you're receiving. If you forget to deallocate somewhere using new[], you get a memory leak. Using vector will alleviate that problem so that you can get along with your work (later on, you can see if you're not releasing the vector at a "good" time, but regardless, the memory will be released automatically thus not stopping you dead in your tracks).

Note that we are creating a vector, setting its size in terms of capacity. Then reading the data into the vector and lastly, copying the data from the vector to the BITMAPINFO variable. Note also that the variable type is BITMAPINFO and not LPBITMAPINFO.

But note that we don't call delete[]. The vector will automatically delete the memory it uses when the vector goes out of scope.

BUT I'm STILL going thru all of this 2 times, and on the second time, I'm getting bad_alloc on imageBuff.resize(size)... also since I never worked with vectors, am I using them right in memcpy and in this function?

Re: [win32] Send bitmap over socket

Code:

int size = bi.bmiHeader.biSizeImage;
imageBuff.resize(size);

Make sure that "size" is valid. It more than likely is a weird number, as vectors don't "crash" on resize() unless size is invalid (or you've really messed up the heap manager in some way, which is highly unlikely to affect vector in this way).

Code:

also since I never worked with vectors, am I using them right in memcpy and in this function?

The usage of vector is correct (&imageBuff[0]). The way it works is that a vector is a wrapper around a (dynamic), contiguous array, not really different than the naked "new[]" call. The difference is that vector is safer and will "delete []" memory when vector goes out of scope.

To get to the vector's internal array is to point to the first element, and that is what "&imageBuffer[0]" does. Since the vector stores BYTE data, a pointer to the first element is a BYTE*, exactly the same if you used new[]. However you must make sure that

1) The imageBuff vector is not empty. If it is empty, then imageBuff[0] doesn't exist, causing an error.
2) The other parameters to SetDIBits are actually correct in terms of the bitmap you're handling.

to the first step (when receiving bitmap), and IT IS receiving the right size (5760000), so bitmapinfo is transfered and retrieved fine, I guess, however the bitmap data (or however itis called) is not, since Its drawing a blackscreen (this can also becaused because of the other messages that are getting processed)

edit2: nope, I made it to not set iStep to 0 after receiving data, so it will process it only once, however it draws just a black screen, so there are 2 errors now:

1. data are not sent/retrieved as they should be
2. it processes one bitmap 157 times

edit3: so I spent whole night trying to do ANYTHING, well, I made new codes for sending and receiving, HOWEVER when I leave first if scope in receiving code, I get "breakpoint occured" visual studio error, or something like that, and it just crashes

What if "res" is 64? You have a buffer overwrite since the largest index that buf can safely address is buf[63]. This is a memory overwrite by 1 byte.

Code:

ps.GetSocket(-1)

Why not store this value in a variable, so that you aren't repeatedly calling this function?

Also, I see a potential for many of these "off-by-1" errors. These errors can cause C++ programs to crash or overwrite other variables. It would also help if you posted the entire program, as memory overwrites anywhere can cause issues in other places later on in the running of the program.

What if "res" is 64? You have a buffer overwrite since the largest index that buf can safely address is buf[63]. This is a memory overwrite by 1 byte.

Code:

ps.GetSocket(-1)

Why not store this value in a variable, so that you aren't repeatedly calling this function?

Also, I see a potential for many of these "off-by-1" errors. These errors can cause C++ programs to crash or overwrite other variables. It would also help if you posted the entire program, as memory overwrites anywhere can cause issues in other places later on in the running of the program.

Regards,

Paul McKenzie

I'm storing socket as "mySocket" now, anyway when I send a bitmap, it will again process the message several times and spam my log, and the bitmap is black

Re: [win32] Send bitmap over socket

Originally Posted by DaigonoYouso

I'm totally lost now

Yes, you are. And your problem is that you're trying to squeeze everything into a single huge function instead of splitting the whole process to several elementary functions responsible for a single particular action each.

This is what I'd do to split it to phases:

Getting HBITMAP - when you get it, you always may test bitmap correctness by just rendering it to some GUI canvas

Saving HBITMAP bits to file/stream/buffer - when you get it to file, you always may test its correctness by just opening it with some image viewer

Sending bits over socket - when you do that, you always know the size you are to send, and you do that in a single action

Reading bits from socket - when you do that, and save the bytes to a file, you always can test it by just file comparison

Restoring HBITMAP from bits - see above about getting bitmap

You see that? With this you are able to control every elementary step of the whole process.

Please note that download links to other resources are not welcomed here.

and IT IS receiving the right size (5760000), so bitmapinfo is transfered and retrieved fine, I guess, however the bitmap data (or however itis called) is not, since Its drawing a blackscreen (this can also becaused because of the other messages that are getting processed)

How do you know that? I would say that black screen is an indication of a problem on the most early phase, I'm 99% sure of that. But you are able neither to confirm nor disprove that, because you never followed Paul's advice to save your bitmap to a file. And now you're lost.

As for the 99% I mentioned. You select your bitmap and never unselect it. You create your compatible DC with NULL. MSDN says:

hdc [in]

A handle to an existing DC. If this handle is NULL, the function creates a memory DC compatible with the application's current screen.

Are you sure this is what you really need?

You create your compatible bitmap with GetDC(NULL). MSDN says:

hWnd [in]

A handle to the window whose DC is to be retrieved. If this value is NULL, GetDC retrieves the DC for the entire screen.

Are you sure this is what you really need? Are you sure those compatible things are really compatible ones? Typically the DC got for desktop window becomes a source for creating both, compatible DC and compatible bitmap.

Bottom line. If I were you, I would immediately stop messing with sending bytes, and get to testing my bitmap generation first of all.

PS. Saving bitmap to a file or stream can be easily done with ATL::CImage. Is it that you're not able to use it?

Re: [win32] Send bitmap over socket

This is what I'd do to split it to phases:
Getting HBITMAP - when you get it, you always may test bitmap correctness by just rendering it to some GUI canvas
Saving HBITMAP bits to file/stream/buffer - when you get it to file, you always may test its correctness by just opening it with some image viewer
Sending bits over socket - when you do that, you always know the size you are to send, and you do that in a single action
Reading bits from socket - when you do that, and save the bytes to a file, you always can test it by just file comparison
Restoring HBITMAP from bits - see above about getting bitmap

Im doing that, and I can even draw bitmap created with SetDIBits from that buffer on the client, but not on the server

Please note that link to other resources are not welcomed here.

so I had to post 600+ lines here? also everybody knows pastebin...

How do you know that?

uhm, because I tested it?

But you are able neither to confirm nor disprove that, because you never followed Paul's advice to save your bitmap to a file. And now you're lost.

I did draw it from BITMAPINFO struct and the array of data using SetDIBits on the client side, so no, I confirmed that this is valid, also the struct on the server side was recreated successfully, since header contained the same size as client sent

Are you sure this is what you really need?

I did draw it from BITMAPINFO struct and the array of data using SetDIBits on the client side, so no, I confirmed that this is valid

Bottom line. If I were you, I would immediately stop messing with sending bytes, and get to testing my bitmap generation first of all.

I did draw it from BITMAPINFO struct and the array of data using SetDIBits on the client side, so no, I confirmed that this is valid

only if u'd read whole thread...

PS. Saving bitmap to a file or stream can be easily done with ATL::CImage. Is it that you're not able to use it?

if I'd want to use MFC or ATL, I'd do it from the start

As for the 99% I mentioned. You select your bitmap and never unselect it.

the closest function to release a bitmap is ReleaseDC, which I'm using in case u didn't notice

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.