Ok... I've been tracing down and trying to understand this problem, and after an hour or so, i final see the problem:

Im passing a memory pointer via. sendmessage to another window, where it then takes it and stores it for later.

When the pointer is recieved by the message handler, its VALID over its range.

L8r on, when the stored pointer is to be used, it is then deemed INVALID, even if i do nothing to the memory it points to.

So as far as i can tell, the OS opens, or allows access of the memory only when being Provided via the SendMessage api.

This makes sense, in a way, as the memory is then critically protected untill the handler finishes, and the SendMessage api returns.

However, i was *hoping* to use the data pointer anyways, and "take my chances" if the other window changes its contents... but i guess there is no way of doing this.. or is there...?

The alternate solution is buffering the data it points to, but i dont really like this option, as it requires multiple "update" messages every time the data is changed.

I would have figured only critical protection of memory area would be for WRITE access... as read access doesnt affect its contents...

Your thoughts?
:NaN:
Posted on 2002-05-29 23:50:51 by NaN
What about VirtualProtect() ??
Posted on 2002-05-30 10:37:32 by Rama
Thanx Rama, but this fails as well....

:NaN:
Posted on 2002-05-30 16:46:28 by NaN
This is rather circular, but say you have two windows.

Window1 and Window2. If you are allocating the memory from Window2 and Window1 needs access rights (for lack of a better term). Have Window1 send a message to Window2 asking for the pointer. Window2 will then send the message your talking about and the pointer should be valid at that time. Or if the memory was freed, dont send the message at all. Justa thought.
Posted on 2002-05-30 17:05:46 by Graebel
Thanx as well Graebel,

I had a simular thought as well, but the overhead is too much to ask for... (ya i want my cake and eat it too ;) )

To be honest, im developing another idea for VKim's debugger.. the mysterious "window 1" is you program to debug, and "window 2" is the debug display window.

I had an idea to track memory dynamically, without a text like listing, but more like a scope window with a slider bar. I have the control practically build, but im getting hung up on the fact windows closes permision to the pointer once the SendMessage api finishes the initial send of the pointer (kinda looses its purpose at this point). The alternate is buffering the date to be viewed at this point, when sent. But this wont be dynamic anymore, and would require the user to continue to set "Probing" debug messages at different stages of the code. It would be *sweet* to have a "Probe ON" and a "Probe OFF" type message, where it would allow the memory contents to be viewed at any moment as the program is in operation. Since im only viewing, and not writing i didnt forsee any of these hang-ups. But apparently windows is more "protective" of its processes than I first thought.

Since its almost finished, i will just have to use a buffer instead.

Thanx again!
:NaN:
Posted on 2002-05-30 22:04:12 by NaN