I'm developing for Windows Mobile in C++, and I'm running into a problem - I added my window
class, and in it I the keyboard input with my WndProc implementation. The problem is
that I'm getting the wrong codes, and identifying keys such as the func key incorrectly, and to make it worse, the values I'm getting (the wParam of the WM_KEYDOWN message) as different values between the two phones I have here for testing - who knows what will happen on other phones.
After playing around with it for ages, I found out that if I only create a window from the
predefined "EDIT" class, I actually do get the input correctly (in terms of letters/keys).
So the problem must not be in the phone, but rather the modes of getting messages (a bit of a newbie in win32, excuse me for lack of knowledge). I tried playing around with input modes, but sending a message to my window using EM_NUMBERS and the such, always failed.
So what I would want to do (though I'm open for suggestions), is somehow just get the characters from some hidden EDIT window, and forward them to my window. (Though I still need my window to have the focus so it would react correctly to messages different from WM_KEYDOWN and the like)
Is there any way to do this?
This is the 3'rd time I'm asking regarding this issue, i am eternally grateful to everyone who tried to help so far (though would be even more grateful if i had managed to solve my problem)
Here are the relevant code excerpts:
Class registration :
WNDCLASS wc; wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_ROADMAP));
wc.hCursor = 0;
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = 0;
wc.lpszClassName = szWindowClass;
window creation
if (width == -1) width = CW_USEDEFAULT;
if (height == -1) height = CW_USEDEFAULT;
RoadMapMainWindow = CreateWindow(g_szWindowClass, szTitle, OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, width, height,
NULL, NULL, g_hInst, NULL);
MessageLoop
// Main message loop:
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
WNDPROC excerpt :
case WM_KEYDOWN:
{
WORD Code = (WORD)wParam;
int iRepeatTimes = (lParam & 0x0000FFFF);
int iScanCode = (lParam & 0x00FF0000) >> 16;
BOOL bALT_IsDown = (lParam & 0x20000000)? TRUE: FALSE;
BOOL bAlreadyPressed= (lParam & 0x40000000)? TRUE: FALSE;
BOOL bNowReleased = (lParam & 0x80000000)? TRUE: FALSE;
return DefWindowProc(hWnd, message, wParam, lParam);
}
The wParam of WM_KEYDOWN is a virtual key code that is not really constrained to be an ascii (or unicode) character - its simply a code that uniquely identifies the key on the platform.
If you want the 'text' - you want to wait for the WM_CHAR message - the wParam of WM_CHAR will be the actual character value that the user entered.
More Info - in your application loop - where you call TranslateMessage - it is actually the job of TranslateMessage to spot WM_KEYDOWN messages and synthesize and post the corresponding WM_CHAR messages.
TranslateAccelerator seems to be the only thing that can interfere with posted messages.
Of course, sometimes very unusual behaviour can manifest if the windows message proc is (or is not) handing messages to DefWindowProc at the wrong time. Why for example do you have an explicit call to DefWindowProc in your WM_KEYDOWN handler? The easiest way to handle that correctly is to have DefWindowProc as the last thing your window proc does so that all messages, handled and unhandled, go there by default. the exceptional case would be messages where you want to prevent DefWindowProc getting the message (WM_PAINT if you handle it for example).
You also keep mentioning trying to use Edit_SetInputMode - Edit_SetInputMode sends a message to the window: EM_SETINPUTMODE - which is a message only understood by EDIT controls. As you have registered your own window class, 'EM_SETINPUTMODE` is going to do nothing.
I've not had any problems like you describe, so I'd really like to see a bare-bones set of code that repros this. It is known that some phones get spurrious user-range messages but these shouldn't be affecting you at the level you're at. The fact that you're getting wrong codes for something so basic indicates to me that you must have something wrong in your window creation or message handling code.
I am just guessing, but maybe your app is an Ansi app? That could maybe explain that different codepages give you different keycodes. So have you tried to make it all Unicode in the project settings, and define the string constants accordingly? And did you try ctacke's suggestion to make a really basic app?
Related
I'm working in Windows 10 and I am trying to write a C++ program that intercepts all touch screen input, however some input is still getting through.
My code calls RegisterPointerInputTarget with PT_TOUCH to intercept touch input. This mostly seems to work, however the results are inconsistent. As a test I have added code that uses SendInput to move the mouse slowly to the right whenever touch input is detected. With my program running I can, for example, open up MS Paint and touch the screen. So long as I hold my finger still on the cursor moves slowly to the right as expected. The moment I move my finger however, the cursor snaps to the position under my finger, just as it would if my program were not running at all.
To give another example, if I try the same thing in visual studio, again the cursor moves slowly to the right until I move my finger at which point the cursor follows my fingers' movement but slowly, lagging be behind it with a significant delay.
The code to set up my window looks like this;
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
hInst = hInstance; // Store instance handle in our global variable
static const char* class_name = "DUMMY_CLASS";
WNDCLASSEX wx = {};
wx.cbSize = sizeof(WNDCLASSEX);
wx.lpfnWndProc = WndProc; // function which will handle messages
wx.hInstance = hInst;
wx.lpszClassName = class_name;
HWND hWnd = 0;
if (RegisterClassEx(&wx)) {
hWnd = CreateWindowEx(0, class_name, "dummy_name", 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, NULL, NULL);
}
if (!hWnd)
{
return FALSE;
}
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);
if (RegisterTouchWindow(hWnd, 0) &&
RegisterPointerInputTarget(hWnd, PT_TOUCH))
{
...
and my message handling code looks like this;
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_TOUCH:
{
INPUT Inputs[1] = { 0 };
Inputs[0].type = INPUT_MOUSE;
Inputs[0].mi.dx = 1;
Inputs[0].mi.dy = 0;
Inputs[0].mi.dwFlags = MOUSEEVENTF_MOVE;
SendInput(1, Inputs, sizeof(INPUT));
Ideally this test code would simply move the cursor for any touch input. Any help in fixing or just understanding this would be greatly appreciated!
I have made some progress with this but have hit other, related, problems I will ask about in a separate question. I will add a comment here when that question is live. The key to sorting out this initial issue however was to make sure I am returning 0, without calling DefWindowProc from all WM_POINTERENTER, WM_POINTERLEAVE, WM_POINTERUP, WM_POINTERDOWN, WM_POINTERUPDATE and WM_TOUCH messages, and to put my SendInput call into the code processing the WM_UPDATE message.
I have an application that already deals with the generating of tooltips. I am modifying a CWnd derived class that has a parent frame. It doesn't implement tooltips.
From this, I can get tooltips to show up by adding the following code:
BEGIN_MESSAGE_MAP(CMyWindow, CWnd)
ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTW, 0, 0xFFFF, OnToolTipNotify)
ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTA, 0, 0xFFFF, OnToolTipNotify)
END_MESSAGE_MAP()
BOOL CMyWindow::OnToolTipNotify(UINT id, NMHDR* pNMHDR, LRESULT* pResult)
{
UNREFERENCED_PARAMETER(id);
UNREFERENCED_PARAMETER(pResult);
// need to handle both ANSI and UNICODE versions of the message
TOOLTIPTEXTA* pTTTA = (TOOLTIPTEXTA*)pNMHDR;
TOOLTIPTEXTW* pTTTW = (TOOLTIPTEXTW*)pNMHDR;
CStringA strTipText;
UINT_PTR nID = pNMHDR->idFrom;
if (pNMHDR->code == TTN_NEEDTEXTA && (pTTTA->uFlags & TTF_IDISHWND) ||
pNMHDR->code == TTN_NEEDTEXTW && (pTTTW->uFlags & TTF_IDISHWND))
{
// idFrom is actually the HWND of the tool
nID = ::GetDlgCtrlID((HWND)nID);
}
if (nID != 0) // will be zero on a separator
strTipText.Format("Control ID = %d", nID);
if (pNMHDR->code == TTN_NEEDTEXTA)
{
strncpy_s(pTTTA->szText, sizeof(pTTTA->szText), strTipText,
strTipText.GetLength() + 1);
}
else
{
::MultiByteToWideChar(CP_ACP, 0, strTipText, strTipText.GetLength() + 1,
pTTTW->szText, sizeof(pTTTW->szText) / (sizeof pTTTW->szText[0]));
}
return TRUE; // message was handled
}
I can use GetParentFrame() to get the frame window, so I'd like to leverage the tooltip code that is already in place so that I get a consistent look. Is there some way that I can forward the TTN_NEEDTEXT message so that it gets handled by the frame window?
In your message map, you use ON_NOTIFY_whatever, which should hint that the message that TTN_NEEDTEXT uses is WM_NOTIFY — and indeed this is the case. So you can just produce the WM_NOTIFY yourself and send it to the parent.
The documentation for WM_NOTIFY says wParam is the control's identifier and lParam is the NMHDR pointer. There's an example on the bottom of the page that shows wParam is just the idFrom member of the NMHDR, so you have everything you need to reconstruct the message:
LRESULT lr = this->GetParentFrame()->SendMessage(WM_NOTIFY, pNMHDR->idFrom, (LPARAM) pNMHDR);
When you should issue this call is up to what you need to do. In this case, you would probably want to make it the first call, override your string, and return TRUE. I'm not fully sure, though.
Note: if MFC provides a function to do this, I don't know it; I personally don't use MFC, but the concepts are the same.
So what about the return value from that SendMessage()? Well, you can return it via pResult (for instance, if you're just tweaking the parent's alterations slightly), or you can ignore it and return a custom value. But for TTN_NEEDTEXT, it won't matter; TTN_NEEDTEXT doesn't care what the LRESULT is.
I have a textbox that is not set to "read-only", so theoretically I should be able to write to it. It is activated with Edit_Enable(hwnd, true), Edit_SetReadOnly(hwnd, false) and SetFocus(hwnd). I can give the textbox focus by clicking on it and I can even see the caret blinking, but however, when I press any key the textbox receives no input. I can set its text with Edit_SetText(), but I cannot write anything manually to it.
I create this textbox with following code:
DWORD dwStyle = WS_CHILD | WS_VISIBLE | WS_VSCROLL | ES_AUTOVSCROLL /*| ES_OEMCONVERT*/ | ES_LEFT /*| ES_WANTRETURN */| WS_TABSTOP;
HWND h = CreateWindowEx(WS_EX_CLIENTEDGE, L"EDIT", (LPCWSTR)NULL, dwStyle, posX, posY, width, height, hParent, NULL, (HINSTANCE)GetModuleHandle(NULL), NULL);
Messages are handled in this function. It is called every frame.
bool PumpMessages()
{
MSG msg;
ZeroMemory( &msg, sizeof(MSG) );
bool bQuit = false;
// Use PeekMessage() so we can use idle time to update the system.
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Translate and dispatch the message
TranslateMessage(&msg);
// message bug workaround
if (msg.message == WM_QUIT)
{
bQuit = true;
}
DispatchMessage(&msg);
}
return bQuit;
}
And the message procedure looks like following:
LRESULT CALLBACK Window::WndProcThunk(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
if (msg == WM_CHAR)
Log("WM_CHAR");
...
// Finally, if the message isn't consumed by the window or any registered listeners, let Windows do its thing.
return msgConsumed ? 0 : DefWindowProc(hWnd, msg, wParam, lParam);
}
The second strange thing happens here in the WndProcThunk message procedure. No WM_CHAR messages are logged. I think this is the reason that my TextBox doesn't do anything, because it needs WM_CHAR messages to react on user key presses. I have to find the reason why no WM_CHAR messages are sent, even though I use TranslateMessage() in my PumpMessages function. Any ideas?
PeekMessage returns FALSE if no messages are in the message queue, so your message loop will exit almost immediately. You need to either switch to using GetMessage or refactor the loop so that you are using your bQuit flag as a test rather than the return value of PeekMessage.
I solved the problem by disabling the DirectInput API. DirectInput 8 was actually eating all WM_KEYDOWM messages, which resulted in no WM_CHAR messages being sent. But the textbox needs WM_CHAR messages to react to user input. This is a strange behaviour of the API. If anyone has ideas to fix this problem without disabling DirectInput, feel free to post it. But I will use GetAsyncKeyState() for keyboard input from now on.
is there any documentation which messages are processed by DefWindowProc, and how?
I recently stumbled over WM_SETFONT/WM_GETFONT not being handled, I'm not sure if there's a mistake in my code, or if that's expected behavior, so I tried the following WinMain:
WNDCLASSEX wcx =
{
sizeof(WNDCLASSEX),
CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS,
DefWindowProc,
0, 0, // class/wnd extra bytes
hInstance,
0,
LoadCursor(0, IDC_ARROW),
0,
0,
_T("some class"),
0
};
ATOM a = RegisterClassEx(&wcx);
_ASSERTE(a != 0);
HWND wnd = CreateWindowEx(0, wcx.lpszClassName, NULL,
WS_POPUP, 0,0,0,0, GetDesktopWindow(), 0, hInstance, 0);
_ASSERTE(wnd != 0);
HFONT font = (HFONT) GetStockObject(ANSI_VAR_FONT);
_ASSERTE(font != 0);
SendMessage(wnd, WM_SETFONT, (WPARAM) font, 0);
HFONT font2 = (HFONT) SendMessage(wnd, WM_GETFONT, 0, 0);
_ASSERTE(font2 == font); // **FAILS**, font2 is 0
As far as I am aware - no.
Each window message is a rare and unique thing that can differ in one of MANY ways. Some messages are expected to be posted, other's sent.
Some messages are notifications to the users window proc, others are commands to the DefXXXWindowProc handler(s) - DefWindowProc, DefDlgProc, DefMDIChildProc etc.
Some are handled the same in dialog and window procs, some must be handled differently.
WM_SETTEXT and WM_SETREDRAW are actually commands that DefWindowProc uses to modify internal data structures in the WND struct.
WM_SIZE is just a notification - sent BY DefWindowProc to its own window - in response to WM_WINDOWPOSCHANGED.
WM_MOUSExxx messages NEED to be posted, never sent, as windows frequently enter modal states where messages are read with GetMessage/PeekMessage and handled directly and NOT posted.
A lot of messages look like notifications, but MUST always be passed on to DefWindowProc because they're "secretly" used to implement the window manager. (WM_ACTIVATE and friends).
Most messages can be handled in a dialog proc by returning FALSE (or TRUE), some, with meaningful results need to use SetDlgResult, others are automatically handled (WM_CTLCOLOR*) as the dialog proc knows that a non zero result from the DialogProc corresponds to the LRESULT to return.
Some (WM_SYSCOMMAND) are not really messages to the window at all, and are just handled by DefWindowProc to do window manager type things (tile the desktop etc.)
There is no real attempt in the official documentation to categorize these differences.
To specifically address the WM_SET/GETFONT issue, WM_SETFONT, while a defined message, is not handled by DefwindowProc, and hence not handled by window classes that do not explicitly support it. Controls (EDIT, STATIC, etc) and Dialogs support WM_SETFONT and WM_GETFONT. To support it in a application registered class would require supplying an actual custom WindowProc and handling the message there.
Am i allowed to use a DC outside of a paint cycle?
Is my window's DC guaranteed to be valid forever?
i'm trying to figure out how long my control's Device Context (DC) is valid.
i know that i can call:
GetDC(hWnd);
to get the device context of my control's window, but is that allowed?
When Windows sends me a WM_PAINT message, i am supposed to call BeginPaint/EndPaint to properly acknowledge that i've painted it, and to internally clear the invalid region:
BeginPaint(hWnd, {out}paintStruct);
try
//Do my painting
finally
EndPaint(hWnd, paintStruct);
end;
But calling BeginPaint also returns me a DC inside the PAINTSTRUCT structure. This is the DC that i should be painting on.
i cannot find anything in the documentation that says that the DC returned by BeginPaint() is the same DC that i would get from GetDC().
Especially now, in the days of Desktop Composition, is it valid to paint on a DC that i obtain outside of BeginPaint?
There seem to be 2 ways i can get a DC to paint on during a paint cycle:
dc = GetDC(hWnd);
BeginPaint(&paintStruct);
There is a 3rd way, but it seems to be a bug with the Borland Delphi that i develop with.
During WM_PAINT processing, Delphi believes that the wParam is a DC, and proceeds to paint on it. Whereas the MSDN says that the wParam of a WM_PAINT message is unused.
The Why
My real goal is to try to keep a persistent GDI+ Graphics object against an HDC, so that i can use some better performing features of GDI+ that depend on having a persistent DC.
During the WM_PAINT message handling i want to draw a GDI+ image to the canvas. The following nieve version is very slow:
WM_PAINT:
{
PAINTSTRUCT ps;
BeginPaint(m_hwnd, ps);
Graphics g = new Graphics(ps.hdc);
g.DrawImage(m_someBitmap, 0, 0);
g.Destroy();
EndPaint(h_hwnd, ps);
}
GDI contains a faster performing bitmap, a CachedBitmap. But using it without thinking gives no performance benefit:
WM_PAINT:
{
PAINTSTRUCT ps;
BeginPaint(m_hwnd, ps);
Graphics g = new Graphics(ps.hdc);
CachedBitmap bm = new CachedBitmap(m_someBitmap, g);
g.DrawCachedBitmap(m_bm, 0, 0);
bm.Destroy();
g.Destroy();
EndPaint(h_hwnd, ps);
}
The performance gain comes from creating the CachedBitmap once, so on program initialization:
m_graphics = new Graphics(GetDC(m_hwnd));
m_cachedBitmap = new CachedBitmap(b_someBitmap, m_graphcis);
And now on the paint cycle:
WM_PAINT:
{
PAINTSTRUCT ps;
BeginPaint(m_hwnd, ps);
m_graphics.DrawCachedBitmap(m_cachedBitmap, 0, 0);
EndPaint(h_hwnd, ps);
}
Except now i'm trusting that the DC i obtained after program initializtion will be the same DC for my window as long as the application is running. This means that it survives through:
fast user switches
composition enabled/disabled
theme switching
theme disabling
i find nothing in MSDN that guarantees that the same DC will be used for a particular window for as long as the window exists.
Note: i am not using double-buffering, because i want to be a good developer, and do the right thing. *
Sometimes that means you double-buffering is bad.
There are exceptions, but in general, you may get a different DC each time you call GetDC or BeginPaint. Thus you shouldn't try to save state in the DC. (If you must do this for performance, there are special DCs you can create for a class of windows or a particular window instance, but it doesn't sound like that's what you really need or want.)
Most of the time, however, those DCs will be compatible. They will represent the same graphics mode, so your compatible bitmap should work, even if you get a different DC.
There are Windows messages that tell you when the graphics mode changes, like WM_DISPLAYCHANGE and WM_PALETTECHANGED. You can listen for these, and recreate your cached bitmap. Since those are rare events, you won't have to worry about the performance impact of recreating your cached bitmap at that point.
You can also get notifications for things like theme changes. Those don't change the graphics mode--they're a higher level concept--so your cached bitmap should still be compatible with any DC you get. But if you want to change bitmap when the theme changes, you can listen for WM_THEMECHANGED as well.
The only way I know of that may (or may not) do what you are looking for is to create the window with the CS_OWNDC class style.
What that does is allocates a unique device context for each window in the class.
Edit
From the linked MSDN article:
A device context is a special set of
values that applications use for
drawing in the client area of their
windows. The system requires a device
context for each window on the display
but allows some flexibility in how the
system stores and treats that device
context.
If no device-context style is
explicitly given, the system assumes
each window uses a device context
retrieved from a pool of contexts
maintained by the system. In such
cases, each window must retrieve and
initialize the device context before
painting and free it after painting.
To avoid retrieving a device context
each time it needs to paint inside a
window, an application can specify the
CS_OWNDC style for the window class.
This class style directs the system to
create a private device context — that
is, to allocate a unique device
context for each window in the class.
The application need only retrieve the
context once and then use it for all
subsequent painting.
Windows 95/98/Me: Although the
CS_OWNDC style is convenient, use it
carefully, because each device context
uses a significant portion of 64K GDI
heap.
Perhaps this example will illustrate the use of CS_OWNDC better:
#include <windows.h>
static TCHAR ClassName[] = TEXT("BitmapWindow");
static TCHAR WindowTitle[] = TEXT("Bitmap Window");
HDC m_hDC;
HWND m_hWnd;
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
static PAINTSTRUCT ps;
switch (msg)
{
case WM_PAINT:
{
BeginPaint(hWnd, &ps);
if (ps.hdc == m_hDC)
MessageBox(NULL, L"ps.hdc == m_hDC", WindowTitle, MB_OK);
else
MessageBox(NULL, L"ps.hdc != m_hDC", WindowTitle, MB_OK);
if (ps.hdc == GetDC(hWnd))
MessageBox(NULL, L"ps.hdc == GetDC(hWnd)", WindowTitle, MB_OK);
else
MessageBox(NULL, L"ps.hdc != GetDC(hWnd)", WindowTitle, MB_OK);
RECT r;
SetRect(&r, 10, 10, 50, 50);
FillRect(m_hDC, &r, (HBRUSH) GetStockObject( BLACK_BRUSH ));
EndPaint(hWnd, &ps);
return 0;
}
case WM_DESTROY:
{
PostQuitMessage(0);
return 0;
}
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
WNDCLASSEX wcex;
wcex.cbClsExtra = 0;
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.cbWndExtra = 0;
wcex.hbrBackground = (HBRUSH) GetStockObject( WHITE_BRUSH );
wcex.hCursor = LoadCursor( NULL, IDC_ARROW );
wcex.hIcon = LoadIcon( NULL, IDI_APPLICATION );
wcex.hIconSm = NULL;
wcex.hInstance = hInstance;
wcex.lpfnWndProc = WndProc;
wcex.lpszClassName = ClassName;
wcex.lpszMenuName = NULL;
wcex.style = CS_OWNDC;
if (!RegisterClassEx(&wcex))
return 0;
DWORD dwExStyle = 0;
DWORD dwStyle = WS_OVERLAPPEDWINDOW | WS_VISIBLE;
m_hWnd = CreateWindowEx(dwExStyle, ClassName, WindowTitle, dwStyle, 0, 0, 300, 300, NULL, NULL, hInstance, NULL);
if (!m_hWnd)
return 0;
m_hDC = GetDC(m_hWnd);
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
The CS_OWNDC flag is not to be confused with the CS_CLASSDC flag which:
Allocates one device context to be shared by all windows in the class. Because window classes are process specific, it is possible for multiple threads of an application to create a window of the same class. It is also possible for the threads to attempt to use the device context simultaneously. When this happens, the system allows only one thread to successfully finish its drawing operation.
If all else fails just reconstruct the CachedBitmap.
When you construct a CachedBitmap object, you must pass the address of a Graphics object to the constructor. If the screen associated with that Graphics object has its bit depth changed after the cached bitmap is constructed, then the DrawCachedBitmap method will fail, and you should reconstruct the cached bitmap. Alternatively, you can hook the display change notification message and reconstruct the cached bitmap at that time.
I'm not saying that CS_OWNDC is the perfect solution, but it is one step towards a better solution.
Edit
The sample program seemed to retain the same DC during screen resolution / bit depth change testing with the CS_OWNDC flag, however, when that flag was removed, the DC's were different (Window 7 64-bit Ultimate)(should work the same over differn OS versions... although it wouldn't hurt to test).
Edit2
This example doesn't call GetUpdateRect to check if the window needs to be painted during the WM_PAINT. That is an error.
You can draw onto whichever window dc pleases you. They're both valid. A window does not have just one dc that can represent it at a time. So each time you call GetDC - and BeginPaint internally does so, you will get a new, unique dc, that nonetheless represents the same display area.
Just ReleaseDC (or EndPaint) when you're done with them. In the days of Windows 3.1 device contexts were a limited, or very expensive system resource, so applications were encouraged to never hold onto them, but to retrieve them from the GetDC cache. nowadays its perfectly acceptable to create a dc at window creation, and cache it for the life of the window.
The only "problem" is, when handling WM_PAINT, the dc returned by BeginPaint will be clipped to the invalid rect, and the saved one will not.
I don't however understand what you are attempting to achieve with gdiplus. Usually, if an object is ... selected into a dc for a long period of time, that dc is a memory dc, not a window dc.
Each time GetDC is called you WILL get a new HDC representing a distinct device context with its own state. So, objects, background colors, text modes etc. set on one DC will NOT effect that state of another DC retrieved by a different call to GetDC or BeginPaint.
The system cannot randomly invalidate HDCs retrieved by the client, and actually does a lot of work in the background to ensure that HDCs retrieved before a display mode switch, continue to function. Even changing the bit depth, that technically makes the dc's incompatible, will not, in any way, prevent an application from continuing to use an hdc to blit.
That said, it is wise to watch at LEAST for WM_DISPLAYCHANGE, release any cached DCs and device bitmaps, and recreate them.