I am working on Windows GUI Application.There are 20 Push Buttons on my Window. Against each button click, I want to open up a new window for displaying some information. It can be anything which can display some information but since I am new to all this and I didn’t want to try anything complicated, I decided to go with the idea of creating a pop up window against each button click.
Now the problem that I am facing is that since there are 20 different windows, do I need to create 20 different window callback functions? Though there is only one control in the pop up window i.e. a Close sign, but even for that I need to have a CALLBACK function.
I had been trying with this but now this idea looks senseless. Is there any other option in which I can achieve the desired functionality?
Waiting for help.
If all of the windows should behave the same way, then you can create a single window procedure (what you're calling the CALLBACK function) that is shared by all of the pop-up windows.
Window procedures do not have to be unique to individual windows, but if multiple windows share the same window procedure, they will react identically to all messages that they receive.
For example:
// Message procedure for all pop-up windows.
LRESULT CALLBACK MyPopupWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
// handle any messages you want here in order to
// customize the behavior of your pop-up window
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
You specify a pointer to the MyPopupWndProc function when you register the window class for your pop-up windows (using the RegisterClassEx function), and then you pass the name of the registered window class when you call CreateWindowEx to create/display a pop-up window whenever one of the buttons on your main window is clicked.
Of course, if you're just wanting something simple for testing purposes, remember that you can always call the MessageBox function! No window procedures or class registration required.
Related
I can disable window movement by doing this in the message loop:
case WM_MOVING:
GetWindowRect(hWnd, (RECT*)lParam);
break;
This, however does not work if you remove the call to GetWindowRect(). Why ?
This looks like the message loop is only modifying the message in passing (WM_MOVING.lParam points to the destination RECT of the movement). The message still gets processed (by the system ?). Just doing a break; does not throw away the message, the window is movable.
The message is processed no matter what (even if you don't call DefWindowProc() on it), you can just set its lParam so that the window goes back to its initial position. Is there no way to discard the message completely ? And who's doing the processing ? (obviously, the system is, is there a ubiquitous DefWindowProc() up there in the sky - that you cannot turn off- ?)
What is exactly going on ?
WM_MOVING is one of calbacks done inside callig SetWindowPos. Window is moved after returnig from callback, and after finally moving window next is send WM_MOVE. There are also WM_NCCALCSIZE, WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGE, WM_GETMINMAXINFO, WM_SIZING, WM_SIZE.
Some messages when routed to DefWindowProc do real work (for example WM_NCPAINT, WM_ERASEBKGND), some are used for gathering information for further processing (WM_NCHITTEST, WM_GETMINMAXINFO), some are used for notifying you about changes (WM_MOVING, WM_MOVE, WM_SETTINGCHANGE) or actions (WM_COMMAND, WM_LBUTTONDOWN). It is recommended that when you don't process message, you should route it through DefWindowProc. If you fail to do this for some messages that wouldn't have any effect, but for others you will miss essential functionality.
For modifying interactive moving or sizing of a window, WM_NCHITTEST is a good choice. You can disable default action activated by part of window, or implement selected action on any part of the window.
case WM_NCHITTEST:
{
LRESULT r = DefWindowProc( hwnd, msg, wparam, lparam );
if ( r == HTCAPTION )
r = HTNOWHERE;
return r;
}
Or try bellow code and see what happens when left or top border is dragged.
case WM_NCHITTEST:
{
LRESULT r = DefWindowProc( hwnd, msg, wparam, lparam );
if ( r == HTLEFT )
r = HTTOP;
else if ( r == HTTOP )
r = HTLEFT;
return r;
}
The "Window Procedures" doc says:
For example, the system defines a window procedure for the combo box
class (COMBOBOX); all combo boxes then use that window procedure
I imagine that procedure belongs with the system (the appropriate system DLL, comctl32.dll I guess, unless you subclass it), but it executes in the app thread of course (after it loads that DLL). What that excerpt, and the apparent behavior suggest is the following:
If the style you select requires a title bar, a title bar window (a
system facility) is instantiated for your app, with its own
windowProc, let's say "sysTtlBarProc".
When you try to move this window,
messages (system-created, starting from the input driver) are sent to
both your app's windowProc() and to sysTtlBarProc()
sysTtlBarProc() waits on your windowProc() (which can call DefWindowProc() or not) to return before acting on the message
This would explain the behavior: this protocol gives your windowProc() a chance to act (on its own) and/or modify the message, thus potentially modifying sysTtlBarProc's behavior. This is just a general concept, some messages I guess are purely informative (you can't change sysTtlBarProc's behavior for these), you can only monitor what's happening, and do something of your own next to what sysTtlBarProc() does.
This can easily be demonstrated by doing this :
case WM_SIZING:
case WM_MOVING:
Sleep(1000);
break;
You can then try and move/resize the window and watch the new "sluggish" behavior. Whoever is processing those two WM_SIZING/MOVING messages (you're not calling DefWinProc(), and you're not doing anything with the messages) is definitely delaying his work by a second now.
I packaged the winapi CreateWindowEx into a simple class. Since every window sharing a same wndProc(hwnd,msg,wparam,lparam), I put every window created by CreateWindowEx into a map to distribute msg, like this:
wndProc(hwnd, msg, wparam, lparam){
if(map[hwnd]!=nil){
switch(msg){
map[hwnd].wndProc(...)
}
}
}
And each time a window or its parent window being destroyed, remove it from the map:
case WM_DESTROY: delete(map, hwnd)
But things like buttons do not receive WM_DESTROY. I printed all msg in WM_NOTIFY and WM_COMMAND but i got noting.
So how can I remove those child windows form the map at the right time? Or a way distribute the msg without creating a hwnd map?
They certainly do get that message. But their window procedure is inside Windows, not inside your program. So you never see it. Something you can read in the MSDN documentation, note how WM_DESTROY doesn't get any special treatment. Nor generate a notification that your parent window can see.
Short from automatically removing all the child windows when you see the parent window destroyed, subclassing controls is a pretty standard requirement for C++ class library wrappers. Best to not invent your own btw, this has been done many times already.
So how can I remove those child windows form the map at the right time?
You have to subclass every window you create, either with SetWindowLongPtr(GWL_WNDPROC) or SetWindowSubClass(), then you will receive all of the WM_DESTROY messages.
Or a way distribute the msg without creating a hwnd map?
Frameworks like ATL and VCL handle that by dynamically allocating a thunk for each window and putting the object pointer right in the thunk, then use the thunk as the window procedure. That way, whenever the thunk is called, it passes the message directly to its associated object.
Im trying to scroll other program (PowerPoint 2013) by sending WM_HSCROLL,
and it will work only if I offer the correct LPARAM (not NULL) to SendMessage.
The value of LPARAM is dynamic, it will change if you close and open a new program.
Now I can only get its value by hooking WM_HSCROLL and clicking scroll bar manually.
// This is my code:
LPARAM lParam = 0x0a616c38; // Found by hooking WM_HSCROLL
SendMessage(hTarget, WM_HSCROLL, SB_LINERIGHT, lParam);
So is it possible to get the correct LPARAM programatically?
Many thanks!
p.s. The scroll bar is not a real window in PowerPoint 2013.
p.s. It returns 1 if I use GetScrollInfo(hTarget, SB_CTL, &scrollinfo), but all values inside scrollinfo are zero.
p.s. Office Home and Student 2013 Official Site
Did you try to call GetLastError?
GetScrollInfo will probably not work across process boundaries, so I would say that's why you're not getting valid values back.
The lParam value of a WM_HSCROLL message is either NULL for the standard window scroll bar, or the handle of the scroll control. The handle of the scroll control will obviously change every time the program is run, so you need to find that out yourself before you can reliably simulate scroll input.
To do this, you can use the FindWindowEx function to search the parent window (hTarget in your example) for child windows of class "SCROLLBAR". As you will probably find more than one scrollbar child window you'll need some way to tell them apart - most probably, via the window's GWL_ID value as this will probably not change from run to run.
Is there a defined constant somewhere in MFC that is the standard define for the File->Exit menu command? I'm trying to determine if a command is that one, but I've only got a WPARAM to work with.
The APP_EXIT (57665 or 0xE141) is sent on command to the message map declared in appcore.cpp (or if you override it in your CWinApp derived class);
BEGIN_MESSAGE_MAP(CWinApp, CCmdTarget)
ON_COMMAND(ID_APP_EXIT, &CWinApp::OnAppExit)
END_MESSAGE_MAP()
In turn, OnAppExit sends a WM_CLOSE message to the main window in CWinApp:
void CWinApp::OnAppExit()
{
// same as double-clicking on main window close box
ASSERT(m_pMainWnd != NULL);
m_pMainWnd->SendMessage(WM_CLOSE);
}
That's how your application ends in MFC, no WM_QUIT.
I'm trying to track focus changes between several TrackBars (aka sliders, all within the same window) using WTL.
So far I've tried a
MESSAGE_HANDLER(WM_SETFOCUS, func)
as well as one
COMMAND_HANDLER(IDC_SLIDERn, WM_SETFOCUS, func)
for each slider without success.
The about trackbar controls page on msdn says: "WM_SETFOCUS Repaints the trackbar window." ..
edit:
I now have derived the sliders from my own class where I handle WM_SETFOCUS with MESSAGE_HANDLER and notify the parent window by posting the message to it with m_hWnd as lParam so I can check in the parent which slider gained focus.
This works, but is there a more elegant way to do this?
WM_SETFOCUS is sent to the specific window that gets focus, not to the parent, as you've discovered.
However, there's an alternate tecnique that you can use to avoid subclassing; most controls (specifically the 'common controls', which includes sliders) will send a WM_NOTIFY to their parent when certain events happen, allowing the parent to handle these events for a collection of children.
In your case, try listening for WM_NOTIFY message at the parent window, specifically checking for the case where the notification ID is NM_SETFOCUS - from MSDN:
Notifies a control's parent window that the control has received the input focus. This notification code is sent in the form of a WM_NOTIFY message.
...which sounds like what you are looking for. Apparently ATL supports these in the message map using NOTIFY_HANDLER, something like:
NOTIFY_HANDLER(IDC_SLIDERn, NM_SETFOCUS, func)
Note that this works because the Win32 Common Controls support this sort of notification forwarding; if you were to use some other custom control instead, you may not get these notifications and would have to resort to subclassing. But for the common controls, this is the simplest way of doing it.
You don't need to derive your class, subclassing with CContainedWindowT is just fine.
BEGIN_MSG_MAP_EX(CDialog)
// ...
ALT_MSG_MAP(IDC_TRACKBAR)
MSG_WM_SETFOCUS(OnControlSetFocus)
MSG_WM_KILLFOCUS(OnControlKillFocus)
END_MSG_MAP()
// ...
CContainedWindowT<CTrackBarCtrl> m_TrackBar;
// ...
CDialog() :
m_TitleListView(this, IDC_TRACKBAR)
// ...
LRESULT OnInitDialog(HWND, LPARAM)
{
// ...
ATLVERIFY(m_TrackBar.SubclassWindow(GetDlgItem(IDC_TRACKBAR)));
// ...
// ...
LRESULT OnControlSetFocus(...) { }
LRESULT OnControlKillFocus(...) { }