|
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++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
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
|
|
|
|
|
FindWindow() internally sends each top-level window a WM_GETTEXT message. But if the thread that owns that window is blocked (e.g., a Semaphore, a Mutex, an Event, an I/O operation), SendMessage() will block until that thread frees up and runs. Since this could potentially never happen, FindWindow() will block forever.
"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
|
|
|
|
|
Hello
I have a program using waveIn API.
This is part of my code.
Originally, my program has a deadlock while running waveInReset.
I google it and it is said putting the wavein function in the callback function is forbidden.
So I delete the code which I put waveinstop in the callback function.
It can run waveInReset and waveInunprepareheader successfully.
But it halt at waveInClose.
I can't find information about waveInClose halt.
Can anybody solve this problem?Thx,
Jane.
<br />
while(1){ if(isopen==1){<br />
if(waveInOpen(&hWavin,WAVE_MAPPER, &wfx,(DWORD_PTR)WaveInProc ,0, CALLBACK_FUNCTION) == <br />
MMSYSERR_NOERROR)<br />
{<br />
<br />
isopen=1;<br />
for(int i=0;i<4;i++)<br />
{ <br />
mmrr = waveInPrepareHeader(hWavin, headersend + i, sizeof(WAVEHDR));<br />
mmrr = waveInAddBuffer(hWavin, headersend + i, sizeof(WAVEHDR));<br />
}<br />
mmrr = waveInStart(hWavin); <br />
}<br />
}<br />
if(isclose==1)<br />
{ <br />
if(hWavin)<br />
{ <br />
mmrr=waveInReset(hWavin);<br />
<br />
for(int i=0;i<4;i++)<br />
{<br />
<br />
mmrr=waveInUnprepareHeader(hWavin,headersend+i, sizeof(WAVEHDR));<br />
} <br />
for(int i=0;i<4;i++)<br />
{<br />
mmrr=waveInReset(hWavin);<br />
} <br />
mmrr=waveInClose(hWavin);<br />
sclose=0;<br />
<br />
}<br />
}<br />
}<br />
static void CALLBACK WaveInProc(HWAVEIN hw, UINT uMsg,DWORD_PTR dwInstance, DWORD_PTR dwParam1, DWORD dwParam2)<br />
{<br />
WAVEHDR* curhdrin = (WAVEHDR*)dwParam1;<br />
if(uMsg != WIM_DATA)<br />
return;<br />
if(isclose==1){<br />
<br />
Sleep(1000);<br />
return;<br />
}<br />
waveInAddBuffer(hw, curhdrin, sizeof(WAVEHDR));<br />
<br />
}
|
|
|
|
|
How does isclose ever get set to 1?
Why is there no waveInStop() call anywhere?
Why do you use the Sleep() call in the waveInProc?
That's really going to mess things up if isclose==1.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I have a button that would let user click to stop recording.
That would make isclose = 1;
Originally, I use waveInStop but I waveInStop only stop recording.
waveInReset would stop recording and set the position to 0.
I see some information in the Internet that says use waveInUnPrepareHeader before using waveInReset.
Originally, I don't use Sleep() function,but it has same problem.
I write it in a new small program as follow.
It halts at waveInReset.
If I delete waveInReset, waveInUnPrepareHeader and waveInClose falses and returns 33.
#include "stdafx.h"<br />
#include <winsock2.h><br />
#include <windows.h><br />
#include <iostream><br />
#include <mmsystem.h><br />
#pragma comment(lib, "ws2_32.lib")<br />
#pragma comment(lib, "Winmm.lib")<br />
using namespace System;<br />
using namespace std;<br />
static void CALLBACK WaveInProc(HWAVEIN, UINT, DWORD , DWORD , DWORD );<br />
<br />
static const int SNDNBUF = 2;<br />
static const int SNDSIZEBUF = 320;<br />
HWAVEOUT hWavout;<br />
MMRESULT mmrr;<br />
WAVEHDR headersend[SNDNBUF];<br />
char hdrDatasend[SNDSIZEBUF*SNDNBUF];<br />
HWAVEIN hWavin;<br />
<br />
int _tmain(int argc, _TCHAR* argv[])<br />
{<br />
WAVEFORMATEX wfx; <br />
wfx.nSamplesPerSec = 8000;<br />
wfx.nChannels = 1;<br />
wfx.wFormatTag = WAVE_FORMAT_PCM;<br />
wfx.wBitsPerSample = 16;<br />
wfx.nBlockAlign = wfx.nChannels * (wfx.wBitsPerSample / 8);<br />
wfx.nAvgBytesPerSec = wfx.nSamplesPerSec * wfx.nBlockAlign;<br />
<br />
memset(headersend, 0,sizeof(WAVEHDR)*SNDNBUF);<br />
for(int i=0;i<sndnbuf;i++){<br />
headersend[i].lpData = hdrDatasend + i*SNDSIZEBUF;<br />
headersend[i].dwBufferLength = SNDSIZEBUF;}<br />
<br />
memset(hdrDatasend,0,SNDSIZEBUF*SNDNBUF);<br />
<br />
if(waveInOpen(&hWavin,WAVE_MAPPER, &wfx,(DWORD_PTR)WaveInProc ,0, CALLBACK_FUNCTION) == MMSYSERR_NOERROR){<br />
for(int i=0;i<sndnbuf;i++)>{ <br />
mmrr = waveInPrepareHeader(hWavin, headersend + i, sizeof(WAVEHDR));<br />
mmrr = waveInAddBuffer(hWavin, headersend + i, sizeof(WAVEHDR));}<br />
mmrr = waveInStart(hWavin); }<br />
int i;<br />
cin >> i;<br />
mmrr=waveInStop(hWavin);<br />
mmrr=waveInReset(hWavin);<br />
Sleep(500);<br />
for(int i=0;i<sndnbuf;i++){<br />
if ((headersend+i)->dwFlags & WHDR_PREPARED){<br />
mmrr=waveInUnprepareHeader(hWavin,headersend+i, sizeof(WAVEHDR));}<br />
Sleep(500);<br />
mmrr=waveInClose(hWavin);<br />
cin >> i;<br />
return 0;<br />
}<br />
<br />
static void CALLBACK WaveInProc(HWAVEIN hw, UINT uMsg,DWORD_PTR dwInstance, DWORD_PTR dwParam1, DWORD dwParam2)<br />
{<br />
WAVEHDR* curhdrin = (WAVEHDR*)dwParam1;<br />
if(uMsg != WIM_DATA)return;<br />
waveInAddBuffer(hw, curhdrin, sizeof(WAVEHDR));<br />
return;<br />
}</sndnbuf;i++)></mmsystem.h></iostream></windows.h></winsock2.h>
Jane
modified on Friday, January 11, 2008 4:23:59 AM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
