I've got a slight problem with my dialog box. it shows its contents in the parent windows. instead of a different frame, nothing seems to be wrong. I used the DS_MODALFRAME and the WS_ styles but it isn't working
END
This is the dialog procedure
BOOL CALLBACK AboutDialog(HWND fsr_win,UINT f_msg, WPARAM fwParam, LPARAM flParam)
{
switch (f_msg)
{
case WM_COMMAND:
switch(fwParam)
{
case ID_OK:
EndDialog(fsr_win,TRUE);
return TRUE;
break;
};
return TRUE;
};
return TRUE;
}
1 RT_MANIFEST "File searcher 2.exe.Manifest"
FSR_ABOUT DIALOG FIXED 6, 21, 100,100
STYLE DS_MODALFRAME
CAPTION "About Generic"
FONT 10, "MS Shell Dlg"
BEGIN
DEFPUSHBUTTON "&Okay", ID_OK, 40, 80, 40, 10
LTEXT "File searcher", 104, 10, 20,90,
8
LTEXT "Copyright © DONSN® 2014 ", 107, 10,40,90, 8
END
B
The simple solution was to change a bit of the line of code in the dialog procedure which apparently returns true instead of false...
So we have
{
/* after the case statements*/
Return FALSE
}
And that's all it shows with a close button...but with the common control stuff on.
Related
I'm working on a Lua binding for Windows API. So far I've been able to create a basic window with a list box control:
require('Alien')
package.path = 'libs\\?.lua;libs\\?\\init.lua;' .. package.path
local function printf(...) io.write(string.format(...)) end
Windows = require('Windows')
local W = Windows
print("loaded OK")
print("Command line=", W.GetCommandLine())
local windowClassName = "testWindow"
local windowClass, window
local hInstance = assert(W.GetModuleHandle(nil))
assert(W.WM_CREATE)
assert(W.WM_CLOSE)
assert(W.WM_DESTROY)
assert(W.DefWindowProc)
assert(W.DestroyWindow)
assert(W.PostQuitMessage)
local msgID = {}
for k, v in pairs(Windows) do
if k:match('^WM_') then msgID[v] = k end
end
local function wndProc(hWnd, msg, wParam, lParam)
local id = msgID[msg] or ('%08X'):format(msg)
printf('wndProc(%08X, %20s, %08X, %08X\n',
hWnd,id, wParam, lParam)
if msg == W.WM_CREATE then
printf("window %08X create\n", hWnd)
elseif msg == W.WM_CLOSE then W.DestroyWindow(hWnd)
elseif msg == W.WM_DESTROY then W.PostQuitMessage(0)
else return W.DefWindowProc(hWnd, msg, wParam, lParam)
end
return 0
end
local wndProcCB = alien.callback(wndProc,
assert(W.LRESULT), assert(W.HWND),
assert(W.UINT), assert(W.WPARAM), assert(W.LPARAM))
windowClass = assert(W.WNDCLASSEX:new {
cbSize = assert(W.WNDCLASSEX.size),
style = bit.bor(W.CS_HREDRAW, W.CS_VREDRAW),
lpfnWndProc = assert(wndProcCB),
cbClsExtra = 0,
cbWndExtra = 0,
hInstance = assert(hInstance),
hIcon = nil,
hCursor = nil,
hbrBackground = assert(W.COLOR_APPWORKSPACE)+1,
lpszMenuName = nil,
lpszClassName = assert(windowClassName),
hIconSm = nil,
})
assert(W.RegisterClassEx(windowClass))
local dwExStyle = bit.bor(
W.WS_EX_TOOLWINDOW,
W.WS_EX_OVERLAPPEDWINDOW)
local dwStyle = bit.bor(
W.WS_OVERLAPPEDWINDOW,
W.WS_CLIPSIBLINGS,
W.WS_CLIPCHILDREN)
window = assert(W.CreateWindowEx(
assert(dwExStyle), --dwExStyle
assert(windowClassName), --lpClassName
"Test Window", --lpWindowName
assert(dwStyle), --dwStyle
assert(W.CW_USEDEFAULT), --x
assert(W.CW_USEDEFAULT), --y
420, 314, --width, height
nil, nil, assert(hInstance), nil)) --hWndParent, hMenu, hInstance, lpParam
local SWP_SHOW_ONLY = bit.bor(
W.SWP_ASYNCWINDOWPOS,
W.SWP_SHOWWINDOW,
W.SWP_NOACTIVATE,
W.SWP_NOMOVE,
W.SWP_NOSIZE,
W.SWP_NOZORDER)
W.SetWindowPos(assert(window), nil, 0, 0, 0, 0, assert(SWP_SHOW_ONLY))
local msg = assert(W.MSG:new())
while W.GetMessage(msg, 0, 0, 0) do
W.TranslateMessage(msg)
W.DispatchMessage(msg)
end
It creates and displays a window, but the window doesn't redraw correctly. From the console output I can see lots of WM_PAINT, WM_ERASEBKGND, WM_NCPAINT etc, which I pass on to DefWindowProc, but it seems to be not handling them.
Example screenshots:
When the window first appears, it either takes the image of whatever was behind it (as in this case) or appears solid gray. As it's dragged around, it keeps that image and anything that drags over it leaves behind a ghost image. (Can be seen on the titlebar, where I have a small white button following the active window around.) If I drag it off screen a bit, it starts to get even more glitchy but never successfully repaints itself.
I've tried various methods of handling WM_PAINT, WM_ERASEBKGND, etc but none have had any effect. Examples don't show these messages being handled either. Am I doing something wrong, or is there something else I need to be doing?
Well, I found the issue (I hope) with the help of Rohitab API Monitor. It was indeed a problem with the Lua binding: it had DefWindowProc declared as taking four int parameters. That's mostly fine, until we get a WM_ERASEBKGND message with a wParam (a handle to a device context) which is > 0x7FFFFFFF, and the call to DefWindowProc fails at converting that to an int and passes the wrong value. So the window never renders certain items to the correct device context. My debug logging (which wraps Windows API functions to print their parameters to the console) didn't catch this either, since it was logging the value before it got mangled.
Changing the declaration to use uint seems to have resolved it. (And maybe I can use API Monitor's definition files for my bindings, since the ones I have seem to be somewhat inaccurate.)
I am making a win32 api window application project on visual studio 2012.I use a LPWSTR type variable to store my strings described as follow.
LPWSTR MyStringList[3]={L"apple",L"orange",L"watermelon"};
I expect to copy the text from an editbox to one of the strings in MyStringList. Therefore,I made a simple editbox and button.
Here is the definition of editbox and button.
case WM_CREATE:
hEdit = CreateWindow(L"EDIT",
L"",
WS_CHILD | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL,
10, 10, 200, 25,
hWnd,
(HMENU)ID_EDIT,
GetModuleHandle(NULL),
NULL);
hBtn = CreateWindow(L"BUTTON",
L"",
WS_CHILD | WS_VISIBLE,
250, 10, 50, 30,
hWnd,
(HMENU)ID_BUTTON,
GetModuleHandle(NULL),
NULL);
Here is the action when the button is pushed.The two messagebox are used to see if the string has been changed after function GetWindowText is called.
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
switch (wmId)
{
case ID_BUTTON:
MessageBox(hWnd,MystringList[1],L"Before_Pusing",MB_OK);
GetWindowText(hEdit,MystringList[1],sizeof(MystringList[1]));
MessageBox(hWnd,MystringList[1],L"After_Pushing",MB_OK);
InvalidateRect(hWnd,NULL,TRUE);
break;
Now I tried to push the button after typing "banana" into the editbox. The second string "orange" should be replaced with "banana". However,it turned out that nothing changed .The second messagebox displayed "orange" as the first messagebox did. What's wrong with my code? Please help! Thanks a lot!
You could try this, adding whatever programming quirks that Windows needs.
#define MYLEN 20
...
char MyStringList[3][MYLEN+1] = {"apple", "orange", "watermelon"};
Then you can fetch the string from the edit box with
GetWindowText(hEdit,MystringList[1],MYLEN);
Although the GetWindowText() documentation says
"Copies the text of the specified window's title bar (if it has one) into a buffer. If the specified window is a control, the text of the control is copied. However, GetWindowText cannot retrieve the text of a control in another application."
I have the problem with my dialog, that when i invoke the function "DialogBoxA" the Dialog doesn't appear. I only get the "Busy Cursor" and the the cursor is also trapped inside of a small rectangle (the size of the dialog). After the press of (almost) any button it magically appears.
Dialog box call
DialogBoxA(hInstance,MAKEINTRESOURCEA(IDD_ORACLE_DIALOG),0,reinterpret_cast<DLGPROC>(DlgProc));
Dialog resource code
IDD_ORACLE_DIALOG DIALOGEX 0, 0, 155, 71
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | DS_CENTER | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
DEFPUSHBUTTON "OK",IDOK,43,50,50,14
PUSHBUTTON "Cancel",IDCANCEL,98,50,50,14
COMBOBOX IDC_COMBOSERVER,53,6,94,30,CBS_DROPDOWN | CBS_SORT | CBS_NOINTEGRALHEIGHT | WS_VSCROLL | WS_TABSTOP
EDITTEXT IDC_EDITLOG,54,25,94,14,ES_AUTOHSCROLL
LTEXT "Server",IDC_STATIC,7,7,47,13
LTEXT "Log",IDC_STATIC,7,25,47,13
END
DialogProc
LRESULT CALLBACK DlgProc(HWND hWndDlg, UINT Msg, WPARAM wParam,LPARAM lParam){
switch(Msg){
case WM_INITDIALOG:
for(auto it = vServerList.begin();it!=vServerList.end();++it){
SendMessageA(GetDlgItem(hWndDlg,IDC_COMBOSERVER),CB_ADDSTRING,0,reinterpret_cast<LPARAM>(it->c_str()));
}
if(vServerList.size()>0){
SendMessage(GetDlgItem(hWndDlg,IDC_COMBOSERVER),CB_SETCURSEL,0,0);
SendMessage(GetDlgItem(hWndDlg,IDC_EDITLOG),WM_NCLBUTTONDOWN,HTCAPTION,0);
}else{
SendMessage(GetDlgItem(hWndDlg,IDC_COMBOSERVER),WM_NCLBUTTONDOWN,HTCAPTION,0);
}
#ifdef _DEBUG
SendMessageA(GetDlgItem(hWndDlg,IDC_EDITLOG),WM_SETTEXT,0,reinterpret_cast<LPARAM>("q40log"));
#endif
return TRUE;
case WM_COMMAND:
switch(wParam){
case IDOK:
size_t tServer,tLog;
tServer = GetWindowTextLength(GetDlgItem(hWndDlg,IDC_COMBOSERVER))+1;
tLog = GetWindowTextLength(GetDlgItem(hWndDlg,IDC_EDITLOG))+1;
char *pszServer,*pszLog;
pszServer = static_cast<char*>(calloc(tServer,sizeof(char)));
pszLog = static_cast<char*>(calloc(tLog,sizeof(char)));
GetDlgItemTextA(hWndDlg,IDC_COMBOSERVER,pszServer,tServer);
GetDlgItemTextA(hWndDlg,IDC_EDITLOG,pszLog,tLog);
szServer = pszServer;
szUser = pszLog;
free(pszServer);
free(pszLog);
EndDialog(hWndDlg,0);
return TRUE;
case IDCLOSE:
case IDCANCEL:
EndDialog(hWndDlg,0);
return FALSE;
}
break;
}
return FALSE;
}
The obvious failure modes are:
The dialog procedure is faulty.
The dialog resource is invalid.
The dialog resource is linked incorrectly and so cannot be loaded.
The instance handle is incorrect.
Of these options, the cast that you used in the dialog procedure parameter, it seems very likely that the dialog procedure is faulty.
I expect that you added the cast because the code would not compile. And it would not compile because the dialog procedure has an incorrect signature. The cast does not change that fact. It is just a way for you to suppress the compiler and tell it that you know better than it does. Generally speaking, the compiler tends to be right. If your dialog procedure has the wrong signature you need to correct it. Refer to the documentation to find out the correct signature.
The other big problem with your code is that you ignore the return value of DialogBox. If the function fails then the documentation tells you that a value of 0 or -1. In that scenario you can call GetLastError to get extended error information. You must get into the habit of checking for errors when using Win32 API functions.
I maintain a Win32 desktop application that shows tooltips. This so far works pretty well on many XP And Windows 7 installations.
We now get reports from a few customers that they do not see our tool tips. The See a rectangular tooltip (that does not have the TTS_BALLOON attribute. But those created with TTS_BALLOON are not visible. The log files sent by a customer report that CreateWindowEx returns a valid windows handle as well as the coordinates and string contained are correct.
The machine concerned runs Windows XP and is updated regularly.
Has anybody encountered a similar behavior?
How can we solve this problem?
Source Code:
gHintInfo.hwnd = CreateWindowEx(NULL, TOOLTIPS_CLASS, NULL,
WS_POPUP | TTS_NOPREFIX | TTS_ALWAYSTIP | TTS_BALLOON,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL,
(HINSTANCE)xvt_vobj_get_attr(TASK_WIN, ATTR_WIN_INSTANCE),
NULL);
Trace(1, "\n### DrawHint %d, hwnd = %08x, Text =\n%s\n###\n\n", __LINE__, gHintInfo.hwnd, tx);
if (gHintInfo.hwnd != NULL)
{
TOOLINFO ti;
ti.cbSize = sizeof (ti);
ti.uFlags = TTF_TRANSPARENT | TTF_ABSOLUTE;
ti.hwnd = hwndParent;
ti.uId = 0;
ti.hinst = NULL;
ti.lpszText = (char *) tx;
GetClientRect (hwndParent, &ti.rect);
dbgrct(ti.rect);
dbgpnt(gHintInfo.LastHintLoc);
SendMessage(gHintInfo.hwnd, TTM_TRACKPOSITION,0, MAKELONG(gHintInfo.LastHintLoc.v, gHintInfo.LastHintLoc.h));
SendMessage (gHintInfo.hwnd, TTM_ADDTOOL, 0, (long) &ti);
SendMessage (gHintInfo.hwnd, TTM_SETDELAYTIME, TTDT_AUTOMATIC, -1);
SendMessage (gHintInfo.hwnd, TTM_SETMAXTIPWIDTH, 0, 500);
SendMessage (gHintInfo.hwnd, TTM_TRACKACTIVATE, TRUE, (long) &ti);
}
The log output created by this code on the machine that does not diesplay the tooltips is:
### DrawHint 474, hwnd = 00090112, Text =
Some text with
multiple lines
###
ti.rect left = 0, top = 0, right = 1280, bottom = 978
gHintInfo.LastHintLoc h = 295, v = 539
(We set ti.rect to the coordiantes of the whole screen, as windows resizes the tool tip to the containing text anyway.)
EDIT:
We actually added a configuration property to our Software that does nothing more than adding or removing the TTS_BALLOON attribute. This solves the problem on the machines concerned.
The best solution can be found here.
To disable the tooltip balloon, set EnableBalloonTips to 1
I want to create an array of 256 colored buttons with the owner draw extended style to a dialog box created with the visual studio dialog design tool. I added a loop to the WM_INITDIALOG message handler in the dialog procedure to do this:
for (i=0; i<=255; i++)
{
int xp, yp;
HWND status;
xp = rect_pos.left+16*(i%16);
yp = rect_pos.top+16*(i>>4);
status = CreateWindow (
TEXT("button"),
"\0",
WS_CHILD|WS_VISIBLE|BS_OWNERDRAW|BS_PUSHBUTTON,
xp,
yp,
15,
15,
hDlg,
(HMENU) 5000+i, // id used to report events
hInst,
NULL
);
if (status == NULL)
xp =7;
}
I added a message handler for the WM_CTLCOLORBTN message.
case WM_CTLCOLORBTN:
{
int zz;
zz = GetWindowLong ((HWND) lParam, GWL_ID); // window identifier
zz -= 5000;
if ((zz >= 0) && (zz <= 255))
{
HBRUSH BS;
SetTextColor ((HDC) wParam, Collector.Color);
SetBkColor ((HDC) wParam, Collector.Color);
return ((LRESULT) Collector.Brush);
}
break;
}
It more or less works but only the first 64 buttons are displayed. I intend to use a different brush to color each button but for debug puproses, I substituted a single well defined brush. I've debugged the code and satisfied myself the x/y coordinates are proper for each button and that the ID provided in the hMenu createwindow call is proper. I watched all 256 buttons get colored in the WM_CTLCOLORBTN handler. I included a check to make sure the createwindow call does not return failure (NULL). I can get either 4 rows of 16 buttons or 4 columns of 16 buttons by interchanging the x/y parameters on the createwindow call.
If I remove the BS_OWNERDRAW bit from the createwindow call, all 256 buttons are drawn.
It's as if there a limit of 64 buttons with BS_OWNERDRAW :-(
Any help would be greatly appreciated!
TIA, Mike
Are you handling the WM_DRAWITEM message in conjunction with the BS_OWNERDRAW style?
In your case, it seems surprising to me that any buttons are displayed while using the BS_OWNERDRAW style, while BS_PUSHBUTTON is set.
As mentioned in the following link to the documentation for BS_OWNERDRAW, you need to handle WM_DRAWITEM and avoid specifying any other BS_ button styles.
Button Styles from MSDN
Also curious is that the WM_CTLCOLORBUTTON message may be received and then ignored for buttons containing the BS_PUSHBUTTON style. Check out the following link for the documentation on that window message.
WM_CTLCOLORBUTTON from MSDN
From what I can see in your code snippet, most likely you will want to do the following:
Set BS_OWNERDRAW when creating the child buttons.
Handle WM_DRAWITEM on the dialog and draw the button in its correct state. Note that you don't have to handle WM_CTLCOLORBUTTON, just use the Brushes and Fonts and modify the DC as you wish inside your WM_DRAWITEM handler.
Also, depending on your application, you might benefit from making your own window class to represent a grid of buttons on your own, and just drawing the items to taste. This is preferable if you're just displaying internal state and not really looking for the user to manage or interact with a grid of buttons.
Thanks to all who gave advice and help. I now have this working to my satisfaction. I have successfully colored the buttons and surrounded them with a black outline if selected or if they have the input focus. I'll add some code snippets below to show the final state of things but here is synopsis. First, I believe there is some legacy code in my system which makes owner drawn buttons respond to the WM_CTLCOLORBTN for the first child 64 buttons created. Second, I believe the only thing one needs to do is create the buttons, respond properly to the WM_DRAWITEM and WM_COMMAND/BN_CLICKED messages.
Here are the code snippets from my dialog box handler.
In the WM_INITDIALOG code -- create the buttons
for (i=0; i<=255; i++)
{
int xp, yp;
HWND status;
xp = rect_pos.left+16*(i&0x0F);
yp = rect_pos.top+16*(i>>4);
status = CreateWindow
(
TEXT("button"),
"\0",
WS_CHILD|WS_VISIBLE|WS_TABSTOP|BS_OWNERDRAW,
xp,
yp,
15,
15,
hDlg,
(HMENU) (5000+i), // id used to report events
hInst,
NULL
);
if (status == NULL)
xp =7;
SetFocus (status);
}
Respond to the WM_DRAWITEM message
case WM_DRAWITEM: // Owner drawn botton
{
LPDRAWITEMSTRUCT lpDrawItem;
HBRUSH BS, BS_Old;
HPEN PN_Old;
int sz=15;
int cntl;
cntl = LOWORD (wParam) - 5000;
lpDrawItem = (LPDRAWITEMSTRUCT) lParam;
if (lpDrawItem->CtlType != ODT_BUTTON)
return FALSE;
BS = CreateSolidBrush (ColorRef[cntl]);
if (lpDrawItem->itemState & (ODS_SELECTED | ODS_FOCUS))
{
sz = 14;
PN_Old = (HPEN) SelectObject(lpDrawItem->hDC, GetStockObject(BLACK_PEN));
}
else
PN_Old = (HPEN) SelectObject(lpDrawItem->hDC, GetStockObject(NULL_PEN));
BS_Old = (HBRUSH) SelectObject(lpDrawItem->hDC, BS);
Rectangle (lpDrawItem->hDC, 0, 0, sz, sz);
SelectObject(lpDrawItem->hDC, PN_Old);
SelectObject(lpDrawItem->hDC, BS_Old);
DeleteObject (BS);
return true;
}
and finally in the WM_COMMAND code
if (HIWORD(wParam) == BN_CLICKED)
{
if ((LOWORD(wParam) >= 5000) && (LOWORD(wParam) <=5255))
{
Color[0] = ColorRef[LOWORD(wParam)-5000] & 0xFF;
Color[1] = (ColorRef[LOWORD(wParam)-5000] >> 16) & 0xFF;
Color[2] = (ColorRef[LOWORD(wParam)-5000] >> 8 ) & 0xFF;
InvalidateRect (hDlg, NULL, TRUE);
goto Set_Color;
}
}