Change height of COMBOBOX - c

How can I change the height of a COMBOBOX control created with a resource-definition at runtime, so that I can insert new strings in the combobox? The string insertion code is working but only if I set a fixed height for the combobox in the resource-definition (e.g. 28 units). But this is not convenient, because the number of strings is dynamic.
I know that I can create the dialog at runtime, but then I can't use dialog units, and resources are much more efficient...
Here are simplified versions of my code.
Resource file:
IDD_SETTINGS DIALOG 0, 0, 100, 100
BEGIN
COMBOBOX IDC_COMBO, 0, 0, 100, 14, CBS_DROPDOWNLIST
END
Window procedure for main window and dialog:
BOOL CALLBACK WndProcSettings(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
switch (message) {
case WM_INITDIALOG:
//...
break;
default:
return FALSE;
}
return TRUE;
}
LRESULT CALLBACK WndProcMain(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
switch (message) {
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDC_SETTINGS:
DialogBox(hInstance, MAKEINTRESOURCE(IDD_SETTINGS), hWnd, WndProcSettings);
break;
}
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return(0L);
}

I assume you are referring to the height of the dropdown portion of the combobox.
You can still work with Dialog Units, take a look at GetDialogBaseUnits which will return the number of pixels per dialog unit. If you are working with a non-system font the following KB article details the calculations - How To Calculate Dialog Base Units with Non-System-Based Font.
You can programatically change the size of the combobox by using SetWindowPos.

In the meantime, I found a solution. Here is what I'm using now. I set the height for the combobox in the resource file to 14 DLU's (height of one item), so that the new height is calculated correctly. Using GetClientRect I get this height, and convert it to pixels with MapDialogRect.
HWND hCtl;
RECT rect;
hCtl = GetDlgItem(hWnd, IDC_COMBO);
GetClientRect(hCtl, &rect);
MapDialogRect(hCtl, &rect);
SetWindowPos(hCtl, 0, 0, 0, rect.right, (n_choices + 1) * rect.bottom, SWP_NOMOVE);

Related

Load an png image file onto a dialog box in "C" at design time

I have a call to a dialog box that comes up ok. But now I want to load an .png image onto the dialog box screen at design time.
I cannot seem to get it all together, and I do not have a solid understanding of how to do all this. Any help, sure be helpful.
Somewhere I read that I could move a copy of the png file onto the dialog box screen, all that appeared, when I did, was a large box with a little flower in the middle appeared.
Below is a copy of my dialog box function and function call. All I want to do is just add a png image file onto the dialog screen and have it be shown; at design time and also have it during run time. Nothing fancy, but right to the point.
INT_PTR CALLBACK DialogXProcedure(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
switch (uMsg) {
case WM_COMMAND: {
switch (LOWORD(wParam)) {
case IDOK:
//// just falls thru...
case IDCANCEL:
EndDialog(hwnd, LOWORD(wParam));
}
return 1;
}
case WM_INITDIALOG: {
SendMessage(hwnd, WM_SETICON, ICON_SMALL,
reinterpret_cast<LPARAM>(LoadImage(0, IDI_APPLICATION, IMAGE_ICON, 0, 0, LR_SHARED)));
///ensure focus rectangle is properly draw around control with focus
PostMessage(hwnd, WM_KEYDOWN, 0, 0);
return TRUE;
}
case WM_CLOSE:
break;
default:
return FALSE;
}
}
INT_PTR returnval = DialogBox(hInstance, MAKEINTRESOURCE(IDD_DIALOGKEPT), 0,
(DLGPROC)DialogXProcedure);

creating a window with createwindow() when clicking a menu command

I want to create a window with CreateWindow() when clicking on a menu item that will be a child of the main window. I know I can use DialogBox() or CreateDialog() but I want to use CreateWindow(). I'm using this code
resource.rc file
#include "resource.h"
IDM_MENU MENU
{
POPUP "&Help"
{
MENUITEM "&About", IDM_HELP
}
}
About window procedure
LRESULT CALLBACK AboutProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
Main window procedure
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDM_HELP:
{
WNDCLASSEX wc;
HWND hDlg;
MSG msg;
SecureZeroMemory(&wc, sizeof(WNDCLASSEX));
wc.cbSize = sizeof(WNDCLASSEX);
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE+1);
wc.hCursor = LoadCursor(0, IDC_ARROW);
wc.hIcon = (HICON)GetClassLong(hwnd, GCL_HICON);
wc.hIconSm = (HICON)GetClassLong(hwnd, GCL_HICONSM);
wc.hInstance = GetModuleHandle(0);
wc.lpfnWndProc = AboutProc;
wc.lpszClassName = TEXT("AboutClass");
if(!RegisterClassEx(&wc))
break;
hDlg = CreateWindowEx(0, wc.lpszClassName, TEXT("About"), WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, hwnd, 0, wc.hInstance, 0);
ShowWindow(hDlg, SW_SHOWNORMAL);
while(GetMessage(&msg, 0, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
UnregisterClass(wc.lpszClassName, wc.hInstance);
}
break;
}
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
Is this a good idea? Can you register more than one class to the same instance? Also, is it a good idea to assign the main window icons to this child window or should I load them each time? Will those icons be deleted when I call UnregisterClass() in IDM_HELP? I have tried this program and everything works and the icons still show in the main window after I close this child window. But I still wonder if it's ok to assign the main window icons to this window since I call UnregisterClass() after the child window closes
There is nothing wrong with using CreateWindow/Ex() instead of CreateDialog()/DialogBox(). And there is nothing wrong with running your own modal message loop, as long as you implement it correctly. For instance, take heed of this warning:
Modality, part 3: The WM_QUIT message
The other important thing about modality is that a WM_QUIT message always breaks the modal loop. Remember this in your own modal loops! If ever you call the PeekMessage function or the GetMessage function and get a WM_QUIT message, you must not only exit your modal loop, but you must also re-generate the WM_QUIT message (via the PostQuitMessage message) so the next outer layer will see the WM_QUIT message and do its cleanup as well. If you fail to propagate the message, the next outer layer will not know that it needs to quit, and the program will seem to "get stuck" in its shutdown code, forcing the user to terminate the process the hard way.
The example you showed is not doing that, so you would need to add it:
ShowWindow(hDlg, SW_SHOWNORMAL);
do
{
BOOL bRet = GetMessage(&msg, 0, 0, 0);
if (bRet > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
if (bRet == 0)
PostQuitMessage(msg.wParam); // <-- add this!
break;
}
}
while (1);
UnregisterClass(wc.lpszClassName, wc.hInstance);
However, your modal window should NOT be using WM_QUIT just to break its modal loop, as doing so would exit you entire application! Use a different signal to make your modal loop break when the window is closed. For example:
ShowWindow(hDlg, SW_SHOWNORMAL);
while (IsWindow(hDlg) && (GetMessage(&msg, 0, 0, 0) > 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
LRESULT CALLBACK AboutProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CLOSE:
DestroyWindow(hwnd);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
Also, a modal window is supposed to disable its owner window, and then re-enable it when closed. Your example is not doing that either, so that needs to be added as well:
ShowWindow(hDlg, SW_SHOWNORMAL);
EnableWindow(hwnd, FALSE); // <-- add this
...
LRESULT CALLBACK AboutProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CLOSE:
EnableWindow(GetWindow(hwnd, GW_OWNER), TRUE); // <-- add this
DestroyWindow(hwnd);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
The Old New Thing blog has a whole series of posts on how to work with modal windows.
Modality, part 1: UI-modality vs code-modality
Modality, part 2: Code-modality vs UI-modality
Modality, part 3: The WM_QUIT message
Modality, part 4: The importance of setting the correct owner for modal UI
Modality, part 5: Setting the correct owner for modal UI
Modality, part 6: Interacting with a program that has gone modal
Modality, part 7: A timed MessageBox, the cheap version
Modality, part 8: A timed MessageBox, the better version
Modality, part 9: Setting the correct owner for modal UI, practical exam
The correct order for disabling and enabling windows
Make sure you disable the correct window for modal UI
Update: based on your comment that "No I don't want a modal window", you can ignore everything said above. All of that applies to modal windows only. Since you do not want a modal window, simply remove the secondary loop altogether and let the main message loop handle everything. Also, you do not need to call UnregisterClass(). It will unregister automatically when the process ends. Call RegisterClass() one time, either at program startup, or at least the first time you display the About window. You can use GetClassInfo/Ex() to know whether the class is already registered, or keep track of it yourself. Think of what happens if the user wants to display the About window more than one time during the process's lifetime. So let it re-use an existing class registration each time.
Try this:
LRESULT CALLBACK AboutProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CLOSE:
DestroyWindow(hwnd);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDM_HELP:
{
WNDCLASSEX wc = {0};
wc.cbSize = sizeof(WNDCLASSEX);
wc.hInstance = GetModuleHandle(0);
wc.lpszClassName = TEXT("AboutClass");
if (!GetClassInfoEx(wc.hInstance, wc.lpszClassName, &wc))
{
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE+1);
wc.hCursor = LoadCursor(0, IDC_ARROW);
wc.hIcon = (HICON)GetClassLong(hwnd, GCL_HICON);
wc.hIconSm = (HICON)GetClassLong(hwnd, GCL_HICONSM);
wc.lpfnWndProc = AboutProc;
if (!RegisterClassEx(&wc))
break;
}
HWND hDlg = CreateWindowEx(0, wc.lpszClassName, TEXT("About"), WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, hwnd, 0, wc.hInstance, 0);
if (hDlg)
ShowWindow(hDlg, SW_SHOWNORMAL);
}
break;
}
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
Yes, you can use CreateWindow(). You can do anything in your event handler. Using DialogBox() just gives you a modal loop for free (so your main window cannot be interacted with until the dialog box is closed).
Yes, you can register multiple window classes. You are free to register all your window classes in advance; you do not need to call RegisterClass() and UnregisterClass() each time someone clicks your menu item.
I'm not sure if UnregisterClass() frees the various GDI resources allocated to your window class; anyone who knows the answer is free to comment.

Displaying String Output in a Window using C (in WIN32 API)

I want a proper way in which I can output a character string and display it on a Window created.
I had been using textout() function, but since it only paints the window, once the window is minimized and restored back, the data displayed on the window disappears.
Also when the data to be displayed is exceeds the size of Window, only the data equal to window size is displayed and other data is truncated.
Is there any other way to output data on a Window?
You can put a Static or an Edit control (Label and a text box) on your window to show the data.
Call one of these during WM_CREATE:
HWND hWndExample = CreateWindow("STATIC", "Text Goes Here", WS_VISIBLE | WS_CHILD | SS_LEFT, 10,10,100,100, hWnd, NULL, hInstance, NULL);
Or
HWND hWndExample = CreateWindow("EDIT", "Text Goes Here", WS_VISIBLE | WS_CHILD | ES_LEFT, 10,10,100,100, hWnd, NULL, hInstance, NULL);
If you use an Edit then the user will also be able to scroll, and copy and paste the text.
In both cases, the text can be updated using SetWindowText():
SetWindowText(hWndExample, TEXT("Control string"));
(Courtesy of Daboyzuk)
TextOut should work perfectly fine, If this is done in WM_PAINT it should be drawn every time. (including on minimizing and re-sizing)
LRESULT CALLBACK MyWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_PAINT:
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hWnd, &ps);
TextOut(hdc, 10, 10, TEXT("Text Out String"),strlen("Text Out String"));
EndPaint(hWnd, &ps);
ReleaseDC(hWnd, hdc);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
You might also be interested in DrawText
LRESULT CALLBACK MyWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_PAINT:
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hWnd, &ps);
RECT rec;
// SetRect(rect, x ,y ,width, height)
SetRect(&rec,10,10,100,100);
// DrawText(HDC, text, text length, drawing area, parameters "DT_XXX")
DrawText(hdc, TEXT("Text Out String"),strlen("Text Out String"), &rec, DT_TOP|DT_LEFT);
EndPaint(hWnd, &ps);
ReleaseDC(hWnd, hdc);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
Which will draw the text to your window in a given rectangle,
Draw Text will Word Wrap inside of the given rect.
If you want to have your whole window as the draw area you can use GetClientRect(hWnd, &rec); instead of SetRect(&rec,10,10,100,100);

How to draw a line in a static control?

I want to draw a line in a static control:
case WM_CREATE:
{
hgraph=CreateWindow(WC_STATIC,NULL,WS_CHILD|WS_VISIBLE|SS_CENTER,20,20,660,80,hWnd,NULL,NULL,NULL);
SendMessage(hgraph,WM_SETTEXT,NULL,(LPARAM) "My Static");
break;
}
case WM_PAINT:
{
hdc=GetDC(hgraph);
hp=CreatePen(0 ,5,RGB(0,100,0));
SelectObject(hdc,hp);
MoveToEx(hdc, 0, 0, 0);
LineTo(hdc, 100, 100);
ReleaseDC(hgraph, hdc);
}
break;
but it goes under the static control:
When drawing to any child window, you need to do your drawing within the WM_PAINT of the child window procedure, not within the WM_PAINT of the parent window as you are doing.
For system controls (e.g. statics), you need to subclass the window, which means that you need to replace the system-defined window procedure with your own. Once you have installed your own window procedure into the system control, you can catch the WM_PAINT event on the system control to do your painting.
The complete procedure is as follows:
Define your Replacement Window Procedure for the Static Control.
We also must define a variable that we can use to store the original system Window Procedure for the control, which we must call at some point to allow the control to be drawn as normal.
static WNDPROC pFnPrevFunc;
static LRESULT CALLBACK ProcessStaticMessages(HWND hWindow,
UINT uMessage,
WPARAM wParam,
LPARAM lParam)
{
/*
* call the original system handler so the control
* gets painted as normal.
*/
(*pFnPrevFunc)(hWindow, uMessage, wParam, lParam);
/*
* perform our custom operations on this control in
* addition to system operations.
*/
switch (uMessage)
{
...
case WM_PAINT:
/*
* static control has just been painted by system.
*/
hDC = GetDC(hWindow);
/* draw your lines on the static control */
ReleaseDC(hWindow, hDC);
return TRUE;
}
return TRUE;
}
Create your static control window.
hWndStatic = CreateWindow(WC_STATIC, (LPSTR) NULL, WS_CHILD|... );
Subclass your static control window (install your window procedure)
pFnPrevFunc = SetWindowLongPtr(hWndStatic,
GWLP_WNDPROC,
(LONG_PTR) ProcessStaticMessages);
If this works correctly, then you should receive WM_PAINT messages inside your private message processing function for the static, and your drawing should occur correctly.
Hei bro! Don't forget to add DefWindowProc in the Static Procedure. Sometime you cannot paint your controls without DefWindowProc function.
Example:
LRESULT CALLBACK StaticProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
case WM_PAINT:
// Do paint here.
break;
}
return DefWindowProc(hWnd, Msg, wParam, lParam); // Call Default Window Procedure.
}

How to eliminate flicker on a sizable dialog?

I've got a sizable dialog with one child window - a list control. When the dialog is re-sized, I re-size the list control appropriately; it is basically anchored to all 4 edges of the dialog. The problem is that during sizing there is noticeable flicker around the edges of the list control, especially when the scroll bars are present. I am a novice in Win32 GUI stuff, so I don't really know how to handle this. I've seen a lot of articles about flicker-free drawing, but they are all about individual custom-drawn controls and none of them deal with flicker-free drawing of a dialog as a whole. How can I get this to work without flickering so much?
My actual dialog has multiple controls obviously, but here is a minimal code example that reproduces the issue (IDC_LIST1 is a list control in Report view, IDD_DIALOG2 has WS_CLIPCHILDREN style set).
#define NUM_COLUMNS 8
#define NUM_ROWS 32
RECT rcDialog2WindowOriginal;
RECT rcDialog2ClientOriginal;
RECT rcList1ClientOriginal;
INT_PTR Dialog2_OnInitDialog(HWND hDlg, WPARAM wParam, LPARAM lParam)
{
GetWindowRect(hDlg, &rcDialog2WindowOriginal);
GetClientRect(hDlg, &rcDialog2ClientOriginal);
GetWindowRect(GetDlgItem(hDlg, IDC_LIST1), &rcList1ClientOriginal);
ScreenToClient(hDlg, ((LPPOINT)&rcList1ClientOriginal));
ScreenToClient(hDlg, ((LPPOINT)&rcList1ClientOriginal) + 1);
SendDlgItemMessage(hDlg, IDC_LIST1, LVM_SETEXTENDEDLISTVIEWSTYLE, LVS_EX_FULLROWSELECT, LVS_EX_FULLROWSELECT);
TCHAR szText[32];
// add some columns
LVCOLUMN col;
ZeroMemory(&col, sizeof(LVCOLUMN));
col.mask = LVCF_SUBITEM | LVCF_TEXT | LVCF_WIDTH;
col.cx = 60;
col.pszText = szText;
for(int i = 0; i < NUM_COLUMNS; i++)
{
col.iSubItem = i;
_stprintf_s(szText, 32, _T("Column %d"), col.iSubItem);
SendDlgItemMessage(hDlg, IDC_LIST1, LVM_INSERTCOLUMN, col.iSubItem, LPARAM)&col);
}
// add some items
LVITEM item;
ZeroMemory(&item, sizeof(LVITEM));
item.mask = LVIF_TEXT;
item.pszText = szText;
for(int i = 0; i < NUM_ROWS; i++)
{
item.iItem = i;
for(int j = 0; j < NUM_COLUMNS; j++)
{
item.iSubItem = j;
_stprintf_s(szText, 32, _T("Item %d, SubItem %d"), i, j);
if(j == 0)
{
SendDlgItemMessage(hDlg, IDC_LIST1, LVM_INSERTITEM, 0, (LPARAM)&item);
}
else
{
SendDlgItemMessage(hDlg, IDC_LIST1, LVM_SETITEM, 0, (LPARAM)&item);
}
}
}
// autosize the columns
for(int i = 0; i < NUM_COLUMNS; i++)
{
SendDlgItemMessage(hDlg, IDC_LIST1, LVM_SETCOLUMNWIDTH, i, LVSCW_AUTOSIZE);
}
return TRUE;
}
INT_PTR Dialog2_OnGetMinMaxInfo(HWND hDlg, WPARAM wParam, LPARAM lParam)
{
LPMINMAXINFO lpMinMaxInfo = (LPMINMAXINFO)lParam;
// don't allow dialog to be resized smaller than original size
lpMinMaxInfo->ptMinTrackSize.x = rcDialog2WindowOriginal.right - rcDialog2WindowOriginal.left;
lpMinMaxInfo->ptMinTrackSize.y = rcDialog2WindowOriginal.bottom - rcDialog2WindowOriginal.top;
return TRUE;
}
INT_PTR Dialog2_OnSize(HWND hDlg, WPARAM wParam, LPARAM lParam)
{
int cx = LOWORD(lParam);
int cy = HIWORD(lParam);
// anchor the list control to all edges of the dialog
int left_delta = rcList1ClientOriginal.left - rcDialog2ClientOriginal.left;
int right_delta = rcDialog2ClientOriginal.right - rcList1ClientOriginal.right;
int top_delta = rcList1ClientOriginal.top - rcDialog2ClientOriginal.top;
int bottom_delta = rcDialog2ClientOriginal.bottom - rcList1ClientOriginal.bottom;
int left = left_delta;
int top = top_delta;
int width = cx - left_delta - right_delta;
int height = cy - top_delta - bottom_delta;
HWND hWndList1 = GetDlgItem(hDlg, IDC_LIST1);
SetWindowPos(hWndList1, NULL, left, top, width, height, SWP_NOZORDER);
return TRUE;
}
INT_PTR Dialog2_OnClose(HWND hDlg, WPARAM wParam, LPARAM lParam)
{
EndDialog(hDlg, IDOK);
return TRUE;
}
INT_PTR CALLBACK Dialog2_DialogProc(HWND hDlg, UINT nMsg, WPARAM wParam, LPARAM lParam)
{
switch(nMsg)
{
case WM_INITDIALOG:
return Dialog2_OnInitDialog(hDlg, wParam, lParam);
case WM_GETMINMAXINFO:
return Dialog2_OnGetMinMaxInfo(hDlg, wParam, lParam);
case WM_SIZE:
return Dialog2_OnSize(hDlg, wParam, lParam);
case WM_CLOSE:
return Dialog2_OnClose(hDlg, wParam, lParam);
}
return FALSE;
}
Update
After taking a look at many other Windows applications (even ones written by Microsoft), every single one of them suffers the same flickering issues. It is particularly evident when resizing a window with both a status bar and scroll bar from the top left. I guess I will just have to live with it.
A lot of flicker comes from WM_ERASEBKGRD, handle this message and just return TRUE;
You can do several things.
Handle WM_ERASE yourself. You may still need to erase some of the background, but you can draw 4 rectangles around the edges of the window to fill the background area of the dialog without overdrawing the rectangle in the middle where your child control sits.
After calling SetWindowPos, try calling UpdateWindow() to immediately repaint the window (try it on both the list view control and your own window). This minimises the time between you making the size change and the redraw being completed.
Another approach is double buffering (you draw the entire window surface to an offscreen bitmap, and only draw it to the screen when it's all finished. This minimises the time between the start and end of the update proicess on screen, so reduces flicker. This is harder to achieve with a dialog and a windows control though, so not really applicable in your case).
In general, don't be afraid to experiment with things. Try doing things in different orders, etc and see what the results are. If something (like UpdateWindow()) doesn't give a noticeable improvement, then it's easy to remove the code again, and try something else until you get the best results.
edit - additional ideas
see also this SO question
When updating controls you can also suspend and resume repainting (BeginUpdate() and EndUpdate()) to stop them drawing more than once when you are adding many items, etc. THis is not likely to help with window resizing though.
After taking a look at many other Windows applications (even ones written by Microsoft), every single one of them suffers the same flickering issues. It is particularly evident when resizing a window with both a status bar and scroll bar from the top left. I guess I will just have to live with it.
If you try to replace any window's default windowsproc with the following code, the window will basically be updating zero pixels on the screen (besides the border and the title bar; see WM_NCPAINT and other NC-messages for that).
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_ERASEBKGND:
// Lie and tell Windows that this window has cleared its background.
return (-1);
case WM_PAINT:
// Lie and tell Windows that this window has completed all its painting.
ValidateRect(hwnd, nullptr);
return 0;
default:
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
}
This tells us that you are free to paint the pixels however you like. With or without flickering. It's up to you.
How?
Create a compatible bitmap (CreateCompatibleBitmap) and select it into the device context of the window within WM_PAINT. When you're done drawing, BitBlt() that bitmap to the actual window DC and voila; flicker free rendering.

Resources