|
|
Sure - I'll send an email.
You may want to remove your email from your post to avoid
extra spam 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi everybody,
In MFC the new frames,views and controls appears in there own way.
So it seems ugly for the user if the new window opens under blitting...
I used the technique of LockWindowUpdate, which works great ... Under XP
Under Windows Vista this don't seem to work, the new frame opens in 2-4 steps
which seems very ugly 
Does anyone knows this effect? Maybe also the correct technique to work around the problem?
Big thanks in advance
|
|
|
|
|
Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process.
Thanks
|
|
|
|
|
A handle is actually a memory address. The handle (AKA: memory address) which you get from another process may be invalid to current process, because each process has its own view to memory (memory paging issue).
Maxwell Chen
|
|
|
|
|
I disagree. A window handle is unique on the system. You can post messages to the window whose that handle is assigned. At the end PostMessage is an IPC mechanism.
BTW handles technically are not memory addresses.
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.
[my articles]
|
|
|
|
|
CPallini wrote: I disagree. A window handle is unique on the system. You can post messages to the window whose that handle is assigned. At the end PostMessage is an IPC mechanism.
There is a translation mechanism.
CPallini wrote: BTW handles technically are not memory addresses.
 The type void* is memory address.
typedef void* HANDLE;
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: There is a translation mechanism.
Maxwell Chen wrote: The type void* is memory address.
The type void* is a number that may contain a memory address. Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO  ).
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.
[my articles]
|
|
|
|
|
CPallini wrote: The type void* is a number that may contain a memory address.
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
CPallini wrote: Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap. Maybe it would be similar (not 100%) to this kind of thing below (I do not have VC++ now, not sure).
struct MyBlock
{
int a;
};
void main()
{
MyBlock* p = new MyBlock;
p->a = 3;
}
struct MyBlock
{
int a;
};
void main()
{
void* p = reinterpret_cast<void*>(0x00A30210);
cout << reinterpret_cast<myblock*>(p)->a;
}
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. An window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying a window.
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.
[my articles]
|
|
|
|
|
I mean why it is not defined as below?
typedef ULONG HANDLE;
Maxwell Chen
|
|
|
|
|
I don't know, but I can guess that 64-bit version of Windows use 64-bit HANDLEs.
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.
[my articles]
|
|
|
|
|
Maxwell Chen wrote: I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. A window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying one particular window. Even supposing it is a memory address it cannot be a memory address in the context of any process in the user space, i.e. deferencing it in such processes is meaningless.
Maxwell Chen wrote: I guess that creating handle and free handle are something related with global allocating memory blocks in the heap
There's no hope to obtain shared memory the way you depicted. the reinterpret_cast has nothing to do with it (BTW it acts always in the context of the running process and it doesn't changes the pointer address). If you want shared memory you've to ask Windows a HANDLE, i.e. a number: the OS itself will never return to you a direct pointer to.
MSDN [^] states:
Memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is not actually shared globally as it is in 16-bit Windows. This value has no effect and is available only for compatibility. Applications requiring shared memory for other purposes must use file-mapping objects. Multiple processes can map a view of the same file-mapping object to provide named shared memory. For more information, see File Mapping.
[added]
See also http://en.wikibooks.org/wiki/Windows_Programming/Handles_and_Data_Types[^]
[/added]
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.
[my articles]
modified on Thursday, January 10, 2008 10:29:24 AM
|
|
|
|
|
Maxwell Chen
|
|
|
|
|
That really is wrong.
Handles in Windows are opaque - they can be anything the system
implements them as. Whether they are pointers, indexes, integers, floats,
or anything else is irrelevant to the programmer.
All Windows handles are documented as to whether they are local to a
process or system-wide.
Window handles (HWND) are system-wide, so they are the same regardless of
the process using them.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You can use of EnumWindows instead FindWindow,do you want to send data to other window?
|
|
|
|
|
Hamid. wrote: You can use of EnumWindows instead FindWindow
Correct: EnumWindows is usually a better choice than FindWindow, but, Hamid, you're digressing...
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.
[my articles]
|
|
|
|
|
If ashtwin said what does he want to do was better than ask a general question.
|
|
|
|
|
Just kidding ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif) . Anyway his question is clear, he missed only the question mark:
ashtwin. wrote: Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process.
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.
[my articles]
|
|
|
|
|
Yes you can use it. But when using it, take care about the operations. You cant use all APIs, or messages directly.
|
|
|
|
|
Hi,
thanks u all for replying. Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine.
Thanks
|
|
|
|
|
welcome...
I remember your post before... this[^]
|
|
|
|
|
ashtwin wrote: Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine.
It should work fine.
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.
[my articles]
|
|
|
|
|
ashtwin wrote: Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem...
Technically it will work, but you risk a deadlock situation if the target window is in a blocked state.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi,
in ur view which API can cause the deadlock(FindWindow() or PostMessage()).
I don't think that PostMessage() can cause a deadlock.
Thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
