Exist any Windows api function to retrieve the WNDPROC for a Windows Handle?
Thanks in advance.
Use GetWindowLongPtr(hwnd, GWLP_WNDPROC).
Caution: GetWindowLongPtr is actually #defined to GetWindowLong for 32-bit systems, so in order to import it in Delphi you might need to use GetWindowLong instead. As well, GetWindowLongPtr itself is #defined to either GetWindowLongPtrA or GetWindowLongPtrW (for non-unicode and unicode targets), so again you might need to choose the right name manually for Delphi if the import system there is not really smart.
Remember that if you are going to call the obtained window proc, you should do it using CallWindowProc. Thanks to #In silico for the hint.
Please note that the value which is returned is not always the real pointer to the window procedure. Sometimes it's just a kind of handle which is recognized and correctly processed by CallWindowProc. For example, you'll not get the real function pointer if your application is ANSI, but the window belongs to a Unicode component (or vice versa). See this posting in The Old New Thing for more details.
Related
right so I'm new to creating windows applications as I have mostly used console up until this point.
I'm confident with the ideas and understand OOP and have been using MSDN to create a simple window.
As you can see the characters used are not the same. Using MSDN I've found that the character set for LPCSTR is ANSI and I'm fairly sure VS uses Unicode so I'm not sure if that is the issue or not
If anyone can tell me why that would be great!
You are explicitly using the A version of functions when registering and creating your window (RegisterClassExA() and CreateWindowExA(), respectively), but you are using the TCHAR-based DefWindowProc() macro when specifying your window procedure. You are likely compiling your project with UNICODE defined, thus the DefWindowProc() macro would map to the DefWindowProcW() function instead of DefWindowProcA().
This mismatch will cause the behavior you are seeing, as explained in Raymond Chen's blog article:
Why am I getting mojibake when I try to create a window?
The solution is to use DefWindowProcA() explicitly instead, to match with the rest of your code logic:
//wc.lpfnWindowProc = DefWindowProc;
wc.lpfnWindowProc = DefWindowProcA;
I'm writing C++ code, targeting WinCE 6.0 device and I'm having hard time finalizing GUI for my app. VS 2005 window builder which I have to be using does not seem to simplify this task and I cant find documentation which will throw some light on API, hopefully somebody here can.
I need to be dynamically writing on widget page user is on / total number of pages. I expect CTEXT is correct widget to use
CTEXT IDC_PG, 168,183,63,63
However I dont seem to find correct way how to print on CTEXT (or any other suitable widget) Thanks in advance for any good advices.
If I'm understanding the question correctly, you want to display a bit of text on your UI of the form "Page x of n". A static text control (like CTEXT) is appropriate for this.
To set the text programmatically, you can call SetWindowText, but since this is on a dialog, it's probably easier to call SetDlgItemText.
From your example, the identifier is IDC_PG, and it should correspond to a numeric constant that is unique among all the controls on the dialog. Assuming you have an MFC object for the dialog (which I'll assume is myDialog) and a pointer to the zero-terminated text you want it to display (which I'll assume is szPageText), your call would look like:
myDialog.SetDlgItemText(IDC_PG, szPageText);
If you just have a handle to the dialog, your call would look like this:
SetDlgItemText(hDlg, IDC_PG, szPageText);
Since this is older code, it might be compiled for MBCS (often called ANSI in Windows documentation) or UTF-16 (often called Unicode or "wide" strings in MSDN), so you probably want to use the TCHAR and related macros to make sure it works either way.
TCHAR szPageText[64] = TEXT("");
wsprintf(szPageText, TEXT("Page %d of %d"), currentPage, totalPages);
myDialog.SetDlgItemText(IDC_PG, szPageText);
In more modern code, you'd probably explicitly use the wide versions of the APIs:
WCHAR szPageText[64] = L"";
::wsprintfW(szPageText, L"Page %d of %d", currentPage, totalPages);
myDialog.SetDlgItemTextW(IDC_PG, szPageText);
In WinAPI you can call global function SetFocus(HWND) to set focus to NULL window (keystrokes are ignored):
::SetFocus(NULL);
wxWidgets have wxWindow::SetFocus(void) virtual member function so you cannot pass NULL. How to do portable equivalent of ::SetFocus(NULL) in wxWidgets?
There is no way to do it in wxWidgets API (but then it's not clear why would anybody want to do it).
You can ignore all keys by checking for the corresponding events in wxApp::FilterEvent() if you need to do it globally.
I have a process in c++ in which I am using window API. I want to get the HWND of own process. Kindly guide me how can I make it possible.
If you're talking about getting a process handle, then it's not an HWND (which is a window handle), but a HANDLE (i.e., a kernel object handle); to retrieve a pseudo-handle relative to the current process, you can use GetCurrentProcess as the others explained.
On the other hand, if you want to obtain an HWND (a window handle) to the main window of your application, then you have to walk the existing windows with EnumWindows and to check their ownership with GetWindowThreadProcessId, comparing the returned process ID with the one returned by GetCurrentProcessId. Still, in this case you'd better to save your main window handle in a variable when you create it instead of doing all this mess.
Anyhow, keep always in mind that not all handles are the same: HANDLEs and HWNDs, in particular, are completely different beasts: the first ones are kernel handles (=handles to kernel-managed objects) and are manipulated with generic kernel-handles manipulation functions (DuplicateHandle, CloseHandle, ...), while the second ones are handles relative to the window manager, which is a completely different piece of the OS, and are manipulated with a different set of functions.
Actually, in theory an HWND may have the same "numeric" value of a HANDLE, but they would refer to completely different objects.
Get your console window
GetConsoleWindow();
"The return value is a handle to the window used by the console associated with the calling process or NULL if there is no such associated console."
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683175(v=vs.85).aspx
Get other windows
GetActiveWindow() might NOT be the answer, but it could be useful
"The return value is the handle to the active window attached to the calling thread's message queue. Otherwise, the return value is NULL." > msdn GetActiveWindow() docs
However, the graphical windows are not just popping up - so you should retrieve the handle from the place you/your app've created the window... e.g. CreateWindow() returns HWND handle so all you need is to save&retrieve it...
You are (incorrectly) assuming that a process has only a single HWND. This is not generally true, and therefore Windows can't offer an API to get it. A program could create two windows, and have two HWNDs as a result. OTOH, if your program creates only a single window, it can store that HWND in a global variable.
The GetCurrentProcess() function returns a pseudo-handle which refers to the current process. This handle can be used in most Win32 API functions that take a process handle parameter.
The documentation contains more information about this pseudo-handle, including how to convert it to a real handle if you need to.
You can use HANDLE WINAPI GetCurrentProcess(void); from Kernel32.dll.
See MSDN entry here.
My example is not to deal with process, but maybe you need this:
HWND hwndList = GetDlgItem(hwnd, IDCL_COMBOBOX);
This returns HWND of the control specified by its IDCL_COMBOBOX.
Here is another answer:
this->GetSafeHwnd();
From the native Win32 API using C++ is there a way to determine whether the window associated with an HWND is still valid?
You could use the Win32 API IsWindow.
It is not recommended to use it though for 2 reasons:
Windows handles can be re-used once the window is destroyed, so you don't know if you have a handle to an entirely different window or not.
The state could change directly after this call and you will think it is valid, but it may really not be valid.
From MSDN (same link as above):
A thread should not use IsWindow for a
window that it did not create because
the window could be destroyed after
this function was called. Further,
because window handles are recycled
the handle could even point to a
different window.
What can be done?
Perhaps your problem can be re-architected so that you do not have the need to check for a valid handle. Maybe for example you can establish a pipe from the client to the server.
You could also create a windows hook to detect when certain messages occur, but this is probably overkill for most needs.
This question is old, but I needed this functionality myself and was a bit disappointed after reading about the caveats. However, after doing a bit more digging it seems that all is well. Unless you're dealing with 16bit programs, IsWindow appears to be the way to go. The problem of handle re-use appears to have been sufficiently addressed according to this:
http://blogs.msdn.com/b/oldnewthing/archive/2007/07/17/3903614.aspx
So, because of the upper 16bit reuse counter, it is highly unlikely that you'll run into a window reuse problem.
You can use IsWindow() or also try to send the window a WM_NULL message with SendMessage(hWnd, WM_NULL) and see if it is successful.
Also, it is true that the window could be destroyed at any time if it isn't under your control. As others have stated the handle could potentially belong to another window as the handles are reused. In reality I don't know how likely that is.
The only solution that I know of the to create a system wide hook that looks for messages indicating a window is destroyed (WM_CLOSE, WM_DESTROY). Then you would compare the message window handle to ones you are holding to see if any of the windows you care about are affected. See here for more information on system wide hooks.
Maybe a combination of IsWindow, FindWindow and GetWindowThreadProcessId will be more accurate
HWND windowHandle = FindWindow(NULL, TEXT("window_title"));
LPDWORD oldpid = 0;
GetWindowThreadProcessId(windowHandle, &oldpid);
//after some time
if (IsWindow(windowHandle))
{
LPDWORD newpid = 0;
GetWindowThreadProcessId(windowHandle, &newpid);
if (newpid == oldpid)
{
//the window is still running
}else
{
//the window exists but has changed
}
}
If the window procedure for the window in question is under your control (or if you can subclass it), then I would suggest registering a custom message that the window responds to with a non-zero result. Sending that message to any other window (or an invalid HWND) will result in 0.
Of course, that only tells you if the HWND refers to one of the windows that you control -- but perhaps given other answers above that might even be advantageous.
Use RegisterWindowMessage to register the message, using a sufficiently unique name.
if(IsWindow(FindWindow(NULL , TEXT("Example Window Name")))){
// do stuff
}
will check if the window exists and has the appropriate name