Related
I'm not sure if it's the correct wording for my question but the issue revolves around it. I have 2 boxes that both validate on KillFocus. And another method which is called if the user presses the Next button, which calls a method that evaluates if they can continue, which validates these fields.
Due to how old this code base is, modifying this will cause issues elsewhere so I need to find a way around this without changing the way the can continue sequence is called. Here's some scenarios.
The user enters an invalid value in field 1, they press enter, the program fires the kill focus method and shows the error message, the enter key has pressed the next button which in turn validates the it again and shows the error again (different MsgBox same error). Meaning unless they unfocus manually then press enter they will always get two message boxes.
I believe this is due to the above reason as they have pressed enter which killed the focus instead of just calling can next.
Is there a way to stop the entire WM_KEYDOWN trail if it fails within the KillFocus method?
I'm sorry if this is a little bit vague and hazey, this is what I believe is happening.
#DavidHeffernan do you know of any other way to validate fields in the way that WM_KILLFOCUS does?
Allow me to make a suggestion. You can validate edit control's input in EN_CHANGE handler. From the docs:
Sent when the user has taken an action that may have altered text in an edit control.
Each time user types something, you will get this notification, which seems like a good place to validate data.
If data is invalid, you would then disable Next button using EnableWindow and indicate error somehow.
You could use EM_SHOWBALLOONTIP to pop tooltip with error message or simply change the background color of the edit control to red.
Below is the small example that illustrates my point. You should add better error checking of course, but the main idea is there:
#include <windows.h>
#include <CommCtrl.h>
#define IDC_BTN_NEXT 1000
#define IDC_BOX1 2000
#define IDC_BOX2 3000
// enable Visual Styles
#pragma comment( linker, "/manifestdependency:\"type='win32' \
name='Microsoft.Windows.Common-Controls' version='6.0.0.0' \
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' \
language='*'\"")
// link with Common Controls library
#pragma comment( lib, "comctl32.lib")
void onBtnNext()
{
MessageBeep(0);
}
void onKillFocus(HWND box)
{
//==================== these are needed to disable Next button
HWND hwnd = ::GetParent(box);
if (NULL == hwnd) // critical error
return; // TODO: add error handling
HWND btnNext = ::GetDlgItem(hwnd, IDC_BTN_NEXT);
if (NULL == btnNext) // critical error
return; // TODO: add error handling
//==============================================================
int len = ::GetWindowTextLength(box);
if (0 == len) // it is ok, empty text, just return
return;
// if possible, use std::wstring here, I assumed you can't...
wchar_t *txt = new wchar_t[len +1];
if (0 == ::GetWindowText(box, txt, len + 1)) // critical error, according to documentation
{
// TODO: add error handling
delete[] txt;
return;
}
//====== simple validation for illustration only, treat uppercase letter as error
int isTextValid = ::isupper(txt[0]);
for (int i = 1; 0 == isTextValid && i < (len + 1); isTextValid = ::isupper(txt[++i]));
delete[] txt;
//==============================================
if (isTextValid)
{
EDITBALLOONTIP ebt;
ebt.cbStruct = sizeof(EDITBALLOONTIP);
ebt.pszText = L" Tooltip text";
ebt.pszTitle = L" Tooltip title";
ebt.ttiIcon = TTI_ERROR_LARGE;
if (!::SendMessage(box, EM_SHOWBALLOONTIP, 0, (LPARAM)&ebt))
{
//TODO: tooltip won't show, handle error
}
EnableWindow(btnNext, FALSE); // disable Next button
return; // our work is successfully done
}
if (!::SendMessage(box, EM_HIDEBALLOONTIP, 0, 0))
{
//TODO: tooltip won't hide, handle error
}
EnableWindow(btnNext, TRUE); // enable Next button
}
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_CREATE:
{
HWND hwndBox1 = CreateWindowEx(0, WC_EDIT, L"",
WS_CHILD | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL,
20, 20, 250, 20, hwnd, (HMENU)IDC_BOX1,
((LPCREATESTRUCT)lParam)->hInstance, 0);
if (NULL == hwndBox1) // add better error handling, this is for illustration only
return -1;
HWND hwndBox2 = CreateWindowEx(0, WC_EDIT, L"",
WS_CHILD | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL,
20, 50, 250, 20, hwnd, (HMENU)IDC_BOX2,
((LPCREATESTRUCT)lParam)->hInstance, 0);
if (NULL == hwndBox2) // add better error handling, this is for illustration only
return -1;
HWND hwndBtnNext = CreateWindowEx(0, WC_BUTTON, L"Next",
WS_CHILD | WS_VISIBLE | BS_CENTER | BS_DEFPUSHBUTTON,
20, 80, 50, 25, hwnd, (HMENU)IDC_BTN_NEXT,
((LPCREATESTRUCT)lParam)->hInstance, 0);
if (NULL == hwndBtnNext) // add better error handling, this is for illustration only
return -1;
}
return 0L;
case WM_COMMAND:
{
switch (HIWORD(wParam))
{
case BN_CLICKED:
{
if (LOWORD(wParam) != IDC_BTN_NEXT)
break;
onBtnNext();
}
break;
case EN_CHANGE:
{
if (LOWORD(wParam) != IDC_BOX1 && (LOWORD(wParam) != IDC_BOX2))
break;
onKillFocus((HWND)lParam);
}
break;
default:
break;
}
}
break;
case WM_CLOSE:
::DestroyWindow(hwnd);
return 0L;
case WM_DESTROY:
{
::PostQuitMessage(0);
}
return 0L;
default:
return ::DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine,
int nCmdShow)
{
WNDCLASSEX wc;
HWND hwnd;
MSG Msg;
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = 0;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(hInstance, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = GetSysColorBrush(COLOR_WINDOW);
wc.lpszMenuName = NULL;
wc.lpszClassName = L"Main_Window";
wc.hIconSm = LoadIcon(hInstance, IDI_APPLICATION);
if (!RegisterClassEx(&wc))
return 0;
INITCOMMONCONTROLSEX iccex;
iccex.dwSize = sizeof(INITCOMMONCONTROLSEX);
iccex.dwICC = ICC_STANDARD_CLASSES;
InitCommonControlsEx(&iccex);
hwnd = CreateWindowEx(0, L"Main_Window", L"Test",
WS_OVERLAPPED | WS_SYSMENU | WS_CAPTION,
50, 50, 305, 160, NULL, NULL, hInstance, 0);
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);
while (GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
return Msg.wParam;
}
The issue was solved in a "unconventional" way, but it worked. I noticed through debugging that the program lost focus twice on the box, once when ENTER was pressed and once when the message box popped up.
I used a static bool to avoid my program doing the error checking twice. It looks something like this -
void onKillFocus()
{
static bool isValidated = false;
if(!isValidated)
{
isValidated = true;
if(/*ValidationCheck*/)
{
//messagebox for error
}
}
}
By using this, the validation is only ran once when focus is killed stopping the message box from appearing twice, as the static bool is only alive for as long as the method is ran, meaning it's reset every time killfocus is called.
I am using the WinAPI to create a GUI utility. I have two Tabs and each tab has some buttons. I am creating the buttons with this function:
CreateWindowEx(NULL,"button", "Clear", WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON,
150, 175, 100, 25, tab_window_2, (HMENU) CLEAR_DATA, instance_handle, NULL);
In the Windows proc function, I don't know how to detect when the above button is pressed. I also tried handling CLEAR_DATA in the WM_COMMAND switch construct, as follows.
switch ( message ) {
case WM_COMMAND:{
switch(LOWORD(wparam)) {
case CLEAR_DATA : break
}
}
How can I detect and handle those buttons being pressed?
I am creating the tab_window_2 tab as follows :
class frame_window {
private:
LPCSTR window_class_name;
HINSTANCE instance_handle;
HCURSOR cursor_arrow;
HWND window_handle;
HWND tab_handle;
HWND tab_window_1;
HWND tab_window_2;
HWND current_tab_window;
RECT client_rectangle;
public:
frame_window(LPCSTR window_class_identity) : window_class_name(window_class_identity) {
INITCOMMONCONTROLSEX common_controls;
common_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
common_controls.dwICC = ICC_BAR_CLASSES;
InitCommonControlsEx(&common_controls);
int screen_width = GetSystemMetrics(SM_CXFULLSCREEN);
int screen_height = GetSystemMetrics(SM_CYFULLSCREEN);
instance_handle = GetModuleHandle(NULL);
WNDCLASS window_class = { CS_OWNDC, main_window_proc, 0, 0,
instance_handle, NULL,
NULL, NULL, NULL,
window_class_name };
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Create a standard frame window
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RegisterClass(&window_class);
window_handle = CreateWindowEx(WS_EX_WINDOWEDGE | WS_EX_CLIENTEDGE,
window_class_name,
"IR Remote and Barcode Demo",
WS_OVERLAPPEDWINDOW |
WS_CLIPCHILDREN | WS_CLIPSIBLINGS,
100, 100, screen_width-1600,
screen_height-490, NULL, NULL,
instance_handle, NULL);
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Get the size of the client rectangle for the window we have just created
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RECT client_rect;
GetClientRect(window_handle, &client_rect);
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Create the tab control window.
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
tab_handle = CreateWindowEx(NULL, WC_TABCONTROL, NULL,
WS_CHILD | WS_VISIBLE,
10, 10, client_rect.right-client_rect.left-20,
client_rect.bottom-client_rect.top-10,
window_handle, NULL,
instance_handle, NULL);
// Create three tabs.
TCITEM tab_info;
memset(&tab_info, 0, sizeof(tab_info));
tab_info.mask = TCIF_TEXT;
tab_info.pszText = "tab#1";
tab_info.cchTextMax = 5;
SendMessage(tab_handle, TCM_INSERTITEM, 0, (LPARAM)&tab_info);
tab_info.pszText = "tab#2";
SendMessage(tab_handle, TCM_INSERTITEM, 1, (LPARAM)&tab_info);
RECT tab_rectangle;
GetClientRect(tab_handle, &tab_rectangle);
SendMessage(tab_handle, TCM_ADJUSTRECT, FALSE, (LPARAM)&tab_rectangle);
// Create the tab view windows
tab_window_1 = CreateWindowEx(NULL, "STATIC", " ",
WS_CHILD | WS_VISIBLE|SS_OWNERDRAW,
tab_rectangle.left+10, tab_rectangle.top+10,
tab_rectangle.right-tab_rectangle.left,
tab_rectangle.bottom -tab_rectangle.top,
tab_handle, (HMENU)1,
instance_handle, NULL);
SetParent(tab_window_1, window_handle);
current_tab_window = tab_window_1;
tab_window_2 = CreateWindowEx(NULL, "STATIC", " ",
WS_CHILD|SS_OWNERDRAW,
tab_rectangle.left+10, tab_rectangle.top+10,
tab_rectangle.right-tab_rectangle.left,
tab_rectangle.bottom -tab_rectangle.top,
tab_handle, (HMENU)2,
instance_handle, NULL);
CreateWindowEx(NULL,"button", "Clear", WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON,
150, 175, 100, 25, tab_window_2, (HMENU) CLEAR_DATA, instance_handle, NULL);
SetParent(tab_window_2, window_handle);
SetCursor(LoadCursor(NULL, IDC_ARROW));
SetWindowLongPtr(window_handle, GWL_USERDATA, (LONG)this);
ShowWindow(window_handle, SW_SHOW);
UpdateWindow(window_handle);
}
~frame_window() {
UnregisterClass(window_class_name, instance_handle);
}
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Windows main entry point
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
int WINAPI wWinMain(HINSTANCE instance_handle, HINSTANCE, LPWSTR, INT) {
frame_window main_window("my base window");
main_window.run();
return 0;
}
The WM_COMMAND for handling the events from a Push Button must be in the Window Procedure of it's parent. Your code show tab_window_2 as the parent for the CLEAR_DATA button.
Move the WM_COMMAND code in the right Window Proc (or Dialog Proc).
EDIT: I think you didn't understand how the Tab Control works.
If you want each Tab View to contain more than a dummy static control, you should use modeless and borderless DialogBox, children of the Tab Control, and show/hide them accordingly to the TCN_SELCHANGE notification.
If you don't realy need the Dialog Box functionalities, you could create regular child windows (with RegisterClass/CreateWindow) and then add your controls as child windows.
In either case, the show/hide code must react to TCN_SELCHANGE.
With regular child windows or with Dialog Box the net effect is the same: you will have a Window Procedure, or a Dialog Procadure, in which WM_COMMAND will deal with user actions.
Don't play with SetParent. But, if you absolutly want it, then use:
HWND hWndPushClear = CreateWindowEx(NULL,"button", "Clear", [...]
SetParent( hWndPushClear, window_handle );
You may have weird Paint/Focus problems, however.
EDIT: Unfortunately, it seems that there is no good Tab Control tutorial in line.
I recommend updating your actual source code. As a starting point, do the following:
Replace CreateWindowEx by CreateDialog for tab_window_1 end tab_window_2 (only one Dialog must be visible)
Suppress all SetParent calls
Your CreateWindowEx() and WM_COMMAND code are seems correct.
So,
Check return value of CreateWindowEx() whether is NULL. NULL means which is failed to create control.
Check HWND of parent is valid. In your code, it is tab_window_2.
Also, if you do not want to any WS_EX_XXX style, you can just use CreateWindow().
This code is just sample.
LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)
{
switch(iMessage) {
case WM_CREATE:
CreateWindow("button","Clear",WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON,
20,20,100,25,hWnd,(HMENU)0,g_hInst,NULL);
return 0;
case WM_COMMAND:
switch(LOWORD(wParam))
{
case 0:
MessageBox(hWnd,"Clear Button Clicked","Button",MB_OK);
break;
}
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return(DefWindowProc(hWnd,iMessage,wParam,lParam));
}
I am working on a open source project in VC++ and want to change the backcolor of a static control..
hwndRenderMessage = CreateWindow(TEXT("STATIC"), Str("MainWindow.BeginMessage"),
WS_CHILDWINDOW|WS_VISIBLE|WS_CLIPSIBLINGS|SS_CENTER,
0, 0, 0, 0, hwndRenderFrame, NULL, hinstMain, NULL);
SendMessage(hwndRenderMessage, WM_SETFONT, (WPARAM)GetStockObject(DEFAULT_GUI_FONT), TRUE);
and the parent control of this control is
hwndRenderFrame = CreateWindow(OBS_RENDERFRAME_CLASS, NULL,
WS_CHILDWINDOW | WS_VISIBLE | WS_CLIPCHILDREN,
0, 0, 0, 0,
hwndMain, NULL, hinstMain, NULL);
if(!hwndRenderFrame)
CrashError(TEXT("Could not create render frame"));
So how to change the Background color of Static Control..
I google it and getting tha same answer use
case WM_CTLCOLORSTATIC:
{
HDC hdcStatic = (HDC) wParam;
SetTextColor(hdcStatic, RGB(0,0,0));
SetBkColor(hdcStatic, RGB(230,230,230));
return (INT_PTR)CreateSolidBrush(RGB(230,230,230));
}
But there is no switch case in the file so what to do??
Acctually i worked on c# but this is the first time on vc++
I downloaded the OBS source code from sourceforge.
The Window Proc is OBS::RenderFrameProc located in WindowStuff.cpp
At the bottom of the proc (but before the "return"), add:
else if(message == WM_CTLCOLORSTATIC ) {
// HERE YOUR CODE
}
EDIT: Changing Button Background
First, an advice: "don't do that". Buttons are very important and common components of the windows GUI, and their look and feel should be consistent in all applications. Users have ways to customize things for their Desktop, as a whole, and this include "accessibility" issues and behavior. Applications that want do it in their "own special way"s only bring problems.
Second, try this code for changing the "Setting..." button background to an ugly green: Add a case in the WM_NOTIFY message processing in OBS::OBSProc, in the switch(wParam)
case ID_SETTINGS:
if(nmh.code == NM_CUSTOMDRAW)
{
LPNMCUSTOMDRAW lpcd = (LPNMCUSTOMDRAW)lParam;
if (lpcd->dwDrawStage == CDDS_PREPAINT )
{
SetDCBrushColor(lpcd->hdc, RGB(0, 255, 0));
SelectObject(lpcd->hdc, GetStockObject(DC_BRUSH));
LONG lBorders = 0;
LONG lElipse = 5;
RoundRect(lpcd->hdc, lpcd->rc.left + lBorders, lpcd- rc.top + lBorders,
lpcd->rc.right - lBorders, lpcd->rc.bottom - lBorders, lElipse, lElipse);
return CDRF_NOTIFYPOSTPAINT;
}
}
break;
An alternative, with more standard borders:
SetDCBrushColor(lpcd->hdc, RGB(0, 255, 0));
SetDCPenColor(lpcd->hdc, RGB(0, 255, 0));
SelectObject(lpcd->hdc, GetStockObject(DC_BRUSH));
SelectObject(lpcd->hdc, GetStockObject(DC_PEN));
LONG lBorders = 3;
To be complete, you may want to check the uItemState member of lpcd, for the CDIS_HOT flag, changing the color accordingly.
You need to put that code in a window procedure. The window procedure looks like this:
LRESULT CALLBACK RenderMessageWndProc(HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam)
{
switch (message)
{
case WM_CTLCOLORSTATIC:
// your code goes here
return ....
}
return DefWindowProc(hWnd, message, wParam, lParam);
}
And you need to sub-class your window so that it uses this WndProc. Like this:
SetWindowLongPtr(hwndRenderMessage, GWLP_WNDPROC, (LONG_PTR)RenderMessageWndProc);
If you don't know what a window procedure is, or what sub-classing is, then you really need to step back and learn some basics. For instance, Petzold's classic book Programming Windows is still an excellent starting point.
I have a window with 10 child edit controls in it. I would like to move from one edit control to other by pressing the tab key - how do I do this?
I mean, even if I could find out whether I pressed the tab-key, how do I find the next edit control to focus into? I hope I do not have to keep track of the edit controls myself as I already added them to the parent window.
PS: by "next" I mean the order I created the edit controls...
Edit: I'm on Win32 using plain C.
Edit 2: sample
#include
#define NAME "test"
LRESULT CALLBACK WinProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
HWND edit1, edit2;
switch (msg)
{
case WM_CREATE:
edit1 = CreateWindow("edit", "", WS_CHILD|WS_VISIBLE, 0, 0, 200, 50, hWnd, NULL, NULL, NULL);
edit2 = CreateWindow("edit", "", WS_CHILD|WS_VISIBLE, 250, 0, 200, 50, hWnd, NULL, NULL, NULL);
return 0;
case WM_CLOSE:
DestroyWindow(hWnd);
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 nCmdShow)
{
WNDCLASS wc;
wc.style = 0;
wc.lpfnWndProc = WinProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
wc.lpszMenuName = NAME;
wc.lpszClassName = NAME;
RegisterClass(&wc);
HWND win;
win = CreateWindow(NAME, "test", WS_OVERLAPPEDWINDOW, 0, 0, 500, 500, NULL, NULL, hInstance, NULL);
ShowWindow(win, nCmdShow);
UpdateWindow(win);
MSG msg;
while(GetMessage(&msg, NULL, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
The dialog manager does a lot of this for you, so if you don't have a good reason for creating your own window class, you might consider creating a dialog instead.
If you're still of a mind to roll your own, you'll have to intercept WM_CHAR and look for VK_TAB and VK_SHIFT | VK_TAB. The dialog manager uses something called "z-order" as the tab order (http://msdn.microsoft.com/en-us/library/ms632599%28VS.85%29.aspx#zorder).
FWIW, my advice would be to not underestimate the burden you're taking on when trying to re-create an existing facility in Windows like this. For every behavior that you know about, there are usually at least as many that you don't. For example, how will your application behave on a pen-based device? What about accessibility extensions? Will screen readers be able to handle it properly? All of that stuff is already baked into the dialog manager.
I'm not sure I followed... I thought
dialogs are just a floating windows
above the "regular" (?) one. Is it
possible that the application uses
just a dialog, instead of proper
CreateWindow()?
Dialogs can be modal or modeless children of the main application window, but they can also be the main application window. That's typically called a dialog-based app.
If you want a dialog-based application (that is, an application with a dialog as it's main window), you'd do something like this:
int WINAPI WinMain( HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmdLine, int nCmdShow )
{
MSG msg;
HWND hDlg = CreateDialog(hInst, MAKEINTRESOURCE(IDD_DIALOG1), NULL, DialogProc);
if (hDlg != NULL)
{
ShowWindow(hDlg, SW_SHOWNORMAL);
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return 0;
}
The full example is probably too long to list here, but if you Google for CreateDialog, you should find some examples of this.
...And is it possible to
add other windows inside a dialog?
Even with custom window procedures?
(In other words, in dialogs, am I not
restricted just to the default
controls, like edit and static?)
Yes, you can create custom controls within the dialog. Within the DIALOG portion of your .rc file, you can include something like:
CONTROL "",IDC_MYCUSTOM,"MyCtrlClassName",WS_TABSTOP,10,20,30,40
You can also create a new control and add it to the dialog dynamically (I'll let you Google for an example).
Also, if I wanted to roll my own, how
do I find out what's the next control?
I don't really think there will be
more use cases than a basic desktop
Use GetNextDlgTabItem() if you want to cycle through the controls within a dialog in tab-order: http://msdn.microsoft.com/en-us/library/ms645495%28VS.85%29.aspx
If you're rolling your own, then you probably want something like the EnumChildWindows() function: http://msdn.microsoft.com/en-us/library/ms633494%28VS.85%29.aspx
This may also be useful: http://msdn.microsoft.com/en-us/library/bb775501%28VS.85%29.aspx
This kind of processing can be easily added to an application :- Add a call to IsDialogMessage() in your message loop - all the controls have to have the WS_TABSTOP style.
The parent window might have to be of the dialog class as the dialog window class stores state allowing it to (for example) restore focus to the correct control when activation is lost and restored.
I'm writing a license agreement dialog box with Win32 and I'm stumped. As usual with these things I want the "accept/don't accept" buttons to become enabled when the slider of the scroll bar of the richedit control hits bottom, but I can't find a way to get notified of that event. The earliest I've been able to learn about it is when the user releases the left mouse button.
Is there a way to do this?
Here's what I tried so far:
WM_VSCROLL and WM_LBUTTONUP in richedit's wndproc
EN_MSGFILTER notification in dlgproc (yes the filter mask is getting set)
WM_VSCROLL and WM_LBUTTONUP in dlgproc.
EN_VSCROLL notification in dlgproc
I got so desperate I tried polling but that didn't work either because apparently timer messages stop arriving while the mouse button is down on the slider. I tried both:
timer callback (to poll) in dlgproc
timer callback (to poll) in richedit's wndproc
You need to sub-class the edit box and intercept the messages to the edit box itself. Here's an artical on MSDN about subclassing controls.
EDIT: Some code to demonstrate the scroll bar enabling a button:
#include <windows.h>
#include <richedit.h>
LRESULT __stdcall RichEditSubclass
(
HWND window,
UINT message,
WPARAM w_param,
LPARAM l_param
)
{
HWND
parent = reinterpret_cast <HWND> (GetWindowLong (window, GWL_HWNDPARENT));
WNDPROC
proc = reinterpret_cast <WNDPROC> (GetWindowLong (parent, GWL_USERDATA));
switch (message)
{
case WM_VSCROLL:
{
SCROLLINFO
scroll_info =
{
sizeof scroll_info,
SIF_ALL
};
GetScrollInfo (window, SB_VERT, &scroll_info);
if (scroll_info.nPos + static_cast <int> (scroll_info.nPage) >= scroll_info.nMax ||
scroll_info.nTrackPos + static_cast <int> (scroll_info.nPage) >= scroll_info.nMax)
{
HWND
button = reinterpret_cast <HWND> (GetWindowLong (parent, 0));
EnableWindow (button, TRUE);
}
}
break;
}
return CallWindowProc (proc, window, message, w_param, l_param);
}
LRESULT __stdcall ApplicationWindowProc
(
HWND window,
UINT message,
WPARAM w_param,
LPARAM l_param
)
{
bool
use_default_proc = false;
LRESULT
result = 0;
switch (message)
{
case WM_CREATE:
{
CREATESTRUCT
*creation_data = reinterpret_cast <CREATESTRUCT *> (l_param);
RECT
client;
GetClientRect (window, &client);
HWND
child = CreateWindow (RICHEDIT_CLASS,
TEXT ("The\nQuick\nBrown\nFox\nJumped\nOver\nThe\nLazy\nDog\nThe\nQuick\nBrown\nFox\nJumped\nOver\nThe\nLazy\nDog"),
WS_CHILD | WS_VISIBLE | ES_MULTILINE | ES_AUTOVSCROLL | WS_VSCROLL | ES_DISABLENOSCROLL,
0, 0, client.right, client.bottom - 30,
window,
0,
creation_data->hInstance,
0);
SetWindowLong (window, GWL_USERDATA, GetWindowLong (child, GWL_WNDPROC));
SetWindowLong (child, GWL_WNDPROC, reinterpret_cast <LONG> (RichEditSubclass));
SetWindowLong (child, GWL_ID, 0);
child = CreateWindow (TEXT ("BUTTON"), TEXT ("Go Ahead!"), WS_CHILD | WS_VISIBLE | WS_DISABLED, 0, client.bottom - 30, client.right, 30, window, 0, creation_data->hInstance, 0);
SetWindowLong (window, 0, reinterpret_cast <LONG> (child));
SetWindowLong (child, GWL_ID, 1);
}
break;
case WM_COMMAND:
if (HIWORD (w_param) == BN_CLICKED && LOWORD (w_param) == 1)
{
DestroyWindow (window);
}
break;
default:
use_default_proc = true;
break;
}
return use_default_proc ? DefWindowProc (window, message, w_param, l_param) : result;
}
int __stdcall WinMain
(
HINSTANCE instance,
HINSTANCE unused,
LPSTR command_line,
int show
)
{
LoadLibrary (TEXT ("riched20.dll"));
WNDCLASS
window_class =
{
0,
ApplicationWindowProc,
0,
4,
instance,
0,
LoadCursor (0, IDC_ARROW),
reinterpret_cast <HBRUSH> (COLOR_BACKGROUND + 1),
0,
TEXT ("ApplicationWindowClass")
};
RegisterClass (&window_class);
HWND
window = CreateWindow (TEXT ("ApplicationWindowClass"),
TEXT ("Application"),
WS_VISIBLE | WS_OVERLAPPED | WS_SYSMENU,
CW_USEDEFAULT,
CW_USEDEFAULT,
400, 300, 0, 0,
instance,
0);
MSG
message;
int
success;
while (success = GetMessage (&message, window, 0, 0))
{
if (success == -1)
{
break;
}
else
{
TranslateMessage (&message);
DispatchMessage (&message);
}
}
return 0;
}
The above doesn't handle the user moving the cursor in the edit box.
I would recommend starting up Spy++ and seeing which windows messages are getting sent to where.
http://msdn.microsoft.com/en-us/library/aa264396(VS.60).aspx
Why not use the EM_GETTHUMB message. (Assuming Rich Edit 2.0 or later).
If you are lucky this bottom position will match EM_GETLINECOUNT.
Even though it is possible, I don't think you should do it that way - the user will have no clue why the buttons are disabled. This can be very confusing, and confusing the user should be avoided at all costs ;-)
That's why most license dialogs have radio buttons for accept/decline with decline enabled by default, so you actively have to enable accept.