I have a window that asks for Login/Password with five child windows:
An editable one: Login
Another editable one: Password
An OK button
A "forgot your password" one
And a "Register" one.
Basically, when you click on either of the last two, you are sent to a website where you can perform the appropriate actions.
It's all fine and dandy, but I would love to know how it's possible to check (with messages I guess) if the mouse cursor is hovering over one of the two links, and if that's the case, to change it to a hand cursor.
I'd especially like to know how to detect it! I can figure out how to change the cursor afterwards with SetCursor and such!
EDIT: I actually found out that WM_SETCURSOR is a really easy message to handle. Basically, you check if the wParam is equal to the handle of the child window it's hovering over and voilà!
But I actually find the SetCursor to be a bigger issue.
Here's what I did:
The declaration of my cursors:
static HCURSOR hCursorHand;
static HCURSOR hCursorArrow;
The value is set here (in the handle for WM_CREATE):
hCursorHand = LoadCursor( NULL, IDC_HAND );
hCursorArrow = LoadCursor( NULL, IDC_ARROW );
And here's where I set it:
else if (msg == WM_SETCURSOR)
{
if ((HWND)wParam == hwndLinkFPasswd || (HWND)wParam == hwndLinkSignUp)
SetCursor(hCursorHand);
else
SetCursor(hCursorArrow);
}
I know the cursor is properly detected (thank you breakpoints), but it doesn't seem to do anything. The cursor stays an arrow...
So! As I said, I figured it out! (I just couldn't answer my question within the first 8 hours!)
Here's what I missed: (for anyone having the same problem)
else if (msg == WM_SETCURSOR)
{
if ((HWND)wParam == hwndLinkFPasswd || (HWND)wParam == hwndLinkSignUp)
{
SetCursor(hCursorHand);
return(TRUE);
}
}
I find the documentation on this API awful, so I hope my contribution will one day help someone in my situation! ;)
Related
I was hoping someone out there would help me with my predicament I ran into. Essentially I have a Checkbox and a RichEditControl next to each other. I want to be able to know when a user has clicked on my RichEditControl so i can send a message to my checkbox to flag it on and off.
At first i tried to overlay my checkbox with empty text to act as a "blank" background for my RichEditControl so i wouldn't have to worry about sending messages left and right. No matter what i tried the "blank" background would overlap the RichEditControl text and leave it completely blank.
I searched on here for some help and i found this which is exactly what I ran into. I understand what he is saying but don't have the knowledge to implement what they said.
Right now I'm playing around with EN_LINK to attempt to capture a message so i can tell my checkbox to flag itself.
BEGIN_MESSAGE_MAP(TempInit, CDialog)
ON_NOTIFY(EN_LINK, IDC_TempInitMsg, &TempInit::OnEnLinkTempinitmsg)
END_MESSAGE_MAP()
void TempInit::OnEnLinkTempinitmsg(NMHDR *pNMHDR, LRESULT *pResult)
{
ENLINK *pEnLink = reinterpret_cast<ENLINK *>(pNMHDR);
// TODO: Add your control notification handler code here
// TODO: Add your control notification handler code here
radioClicked = !radioClicked;
if (radioClicked == true)
{
GetParent()->SendMessage(WM_MYRADIOCLICKED, CHECKENABLED, 0);
}
else
{
GetParent()->SendMessage(WM_MYRADIOCLICKED, CHECKDISABLED, 0);
}
}
*pResult = 0;
}
I'm sorry in advance if this is totally the wrong way to go about this. I've been googling for a few hours and have come empty handed. If anyone has any other method please help me if possible. I can post more code if what i have above isn't enough.
Steven,
One way to go about this would be to handle the EN_MSGFILTER notification from the rich edit control. I can't provide you any code to show you how to do this off hand but here's the documentation for the Notification messages from that the Rich edit control generates. Simply handle it the same way your doing with your radio button.
This will check the check box when the Rich Edit Ctrl has the focus and untick
it when it losses the focus.
BEGIN_MESSAGE_MAP(TempInit, CDialogEx)
ON_EN_SETFOCUS(IDC_RICHEDIT21, &TempInit::OnEnSetfocusRichedit21)
ON_EN_KILLFOCUS(IDC_RICHEDIT21, &TempInit::OnEnKillfocusRichedit21)
END_MESSAGE_MAP()
void CMFCApplication1Dlg::OnEnSetfocusRichedit21()
{
CButton* pCheckBox = (CButton*)GetDlgItem(IDC_CHECK1);
pCheckBox->SetCheck(1);
}
void CMFCApplication1Dlg::OnEnKillfocusRichedit21()
{
CButton* pCheckBox = (CButton*)GetDlgItem(IDC_CHECK1);
pCheckBox->SetCheck(0);
}
I have seen a similar question here:
How to close a modeless MFC dialog in C++
This is how I close my modeless dialogue:
void CChristianLifeMinistryEditorDlg::OnDestroy()
{
if (m_pAssignHistoryDlg != NULL)
{
delete m_pAssignHistoryDlg;
m_pAssignHistoryDlg = NULL;
}
CDialogEx::OnDestroy();
}
This has always been sufficient, until today. What I have found out (quote by chance) is that if the modeless dialogue has a message box up, and the user goes and closes the parent dialogue, the modeless dialogue stays on screen until you close the message box.
The modelless dialogue is clearly still within an event handler since it has just performed some action and displayed the results to the user.
Is it possible to force it to shut? Or should I somehow stop my parent dialogue from being closed whilst the modelless popup is on screen?
What is the right thing to do?
Thank you.
Update:
I tried this:
void CChristianLifeMinistryEditorDlg::OnDestroy()
{
if (m_pAssignHistoryDlg != NULL)
{
CWnd *pPopupMessage = m_pAssignHistoryDlg->GetWindow(GW_ENABLEDPOPUP);
if (pPopupMessage != NULL)
pPopupMessage->PostMessage(WM_CLOSE);
delete m_pAssignHistoryDlg;
m_pAssignHistoryDlg = NULL;
}
CDialogEx::OnDestroy();
}
It didn't work. When I debugged, it refused to process that call etc until I had dismissed the popup message box myself.
Things are further complicated by the fact the the modelless dialogue makes use of two message boxes:
Are you sure you want to delete the name? YES | NO
Name deleted OK
Either the code can be changed to work, or if I go the custom message route I need to know the result of the message box before my code can proceed (for scenario 1).
Update 2:
I am now confused. I added a custom registered message in the parent dialogue:
afx_msg LRESULT CChristianLifeMinistryEditorDlg::OnDisplayMessage(WPARAM wParam, LPARAM lParam)
{
return AfxMessageBox((LPCTSTR)wParam, (UINT)lParam);
}
The modeless dialogue invokes it like this:
iResult = ::SendMessage(GetParent()->GetSafeHwnd(), UWM_DISPLAY_MESSAGE_MSG,
(WPARAM)strEntry.GetBuffer(_MAX_PATH), MB_YESNO | MB_ICONQUESTION);
strEntry.ReleaseBuffer();
I have placed a breakpoint in the message handler so I know it is being fired correctly. And indeed a message box is being displayed.
But for some reason, the message box is still showing central to the modeless dialogue and not the editor. I don't understand why?
Result!
I found this topic: How to force AfxMessageBox to center on mainframe and not whatever child window that currently has focus
I adjusted my code:
afx_msg LRESULT CChristianLifeMinistryEditorDlg::OnDisplayMessage(WPARAM wParam, LPARAM lParam)
{
return MessageBox((LPCTSTR)wParam, NULL, (UINT)lParam);
}
Now it shows center of the parent dialogue.
I do apologize that this question started of in one direction and ended up with an answer in another direction. I am not sure what we do about that? Technically, the comment to me to use GetWindow didn't seem to work for me. So as such, there is no answer. But by changing my design I have been able to prevent the situation.
Premature Result
Whilst the message box showed centered, it affects the subsequent code. Coming up with read allocation errors.
But I have come up with a viable solution now:
GetParent()->EnableWindow(FALSE);
strEntry.Format(IDS_TPL_SURE_DELETE_FROM_ASSIGN_HIST, psHist->strName);
if (AfxMessageBox(strEntry, MB_YESNO | MB_ICONQUESTION) == IDNO)
{
GetParent()->EnableWindow(TRUE);
return;
}
I disable the parent before showing the message box and enable it again once it is dismissed. This prevents the user from closing the main window. They much close the popup message. I will have to go this way for now.
Thanks guys.
I am currently writing a wrapper for an existing application that has its own GUI. I don't have access to original application's source code (unfortunately). The program that I am writing is in C++ and I am making use of WinAPI. I am manipulating target application by simulating button-clocks, ticking checkboxes etc.
The problem I am facing at the moment is following:
I need to make a selection in droplist implemented as WinAPI ComboBox. I am doing it by using macro ComboBox_SetCurSel. The selection in the droplist changes correctly. However in the original application there is a read-only textbox that changes the value depending on the selection in combobox. And this one does not change when I execute ComboBox_SetCurSel.
The assumption I made is that CBN_SELENDOK and/or CBN_SELCHANGE are sent when selecting an entry in ComboBox manually and this is the bit I am not doing when setting the selection with ComboBox_SetCurSel macro.
However due to lack of experience I cannot figure out how to resolve the problem. Who is normally listening for CBN_SELENDOK and CBN_SELCHANGE. Is it main application window, parent element of the combobox or main application thread? How do I find out.
Is there a macro that would do the whole thing? Like changing the selected item in ComboBox and sending all necessary notifications? Is there some smart workaround?
Any help on the subject, or any additional questions that would help to make situation more clear are welcome.
UPDATE: thanks for comment by Jonathan Potter. I am now attempting to send messages explicitly. Here is the part of the code where I am doing it:
int res = ComboBox_SetCurSel(this->handle, index);
if (res == CB_ERR)
{
return false;
}
PostMessage(GetParent(this->handle),WM_COMMAND, MAKEWPARAM(0,CBN_SELENDOK),0);
PostMessage(GetParent(this->handle),WM_COMMAND, MAKEWPARAM(0,CBN_SELCHANGE),0);
Note this->handle is just a handle to ComboBox itself as I have packed it into the structure for convenience. GetParent(this->handle) Should get immediate parent of ComboBox
Still no result. Does the order of messages matter? Also how do I obtain the identifier that needs to go into LOWORD of WPARAM sent along with WM_COMMAND?
ANSWER:
Thanks to AlwaysLearningNewStuff I have found and an answer. I have been sending messages with 0 as LPARAM. Apparently a handle to ComboBox itself neets to be sent as LPARAM in order for solution to work. This would take me ages to figure it out.
#AlwaysLearningNewStuff, you should have posted this as an answer, not a comment.
Also the bit about using GetDlgCtrlID() to get ControlID of the ComboBox is very useful. This makes code more reliable.
Thank you, everyone who participated.
Here is my final code:
if (this->handle == NULL)
{
return false;
}
int res = ComboBox_SetCurSel(this->handle, index);
if (res == CB_ERR)
{
return false;
}
PostMessage(GetParent(this->handle), WM_COMMAND, MAKEWPARAM(GetDlgCtrlID( this->handle ),CBN_SELENDOK),
(LPARAM)(this->handle));
PostMessage(GetParent(this->handle), WM_COMMAND, MAKEWPARAM(GetDlgCtrlID( this->handle ),CBN_SELCHANGE),
(LPARAM)(this->handle));
return true;
You are correct that CBN_SELCHANGE is not sent when using ComboBox_SetCurSel(), and the documentation says as much:
The CBN_SELCHANGE notification code is not sent when the current selection is set using the CB_SETCURSEL message.
So you have to send the notifications manually. However, you are missing key elements in your messages - the ComboBox's Control ID and HWND. The parent window uses those to identify which child control is sending messages to it so it can then act accordingly.
Try this instead:
int res = ComboBox_SetCurSel(this->handle, index);
if (res == CB_ERR)
{
return false;
}
HWND hParent = GetParent(this->handle);
int iCtrlId = GetDlgCtrlID(this->handle);
if (GetWindowLong(this->handle, GWL_STYLE) & CBS_SIMPLE)
PostMessage(hParent, WM_COMMAND, MAKEWPARAM(iCtrlId,CBN_SELENDOK), LPARAM(this->handle));
PostMessage(hParent, WM_COMMAND, MAKEWPARAM(iCtrlId,CBN_SELCHANGE), LPARAM(this->handle));
I'm trying to restrict the mouse pointer (with a custom cursor) to the client area of the window for my app which works initially but runs into problems when I switch away from the app and back. I'm using ClipCursor() to restrict the cursor and using a couple of different cursors which are situation dependant so I'm using SetCursor() instead of setting the window's class cursor.
I've got the cursor reinstating itself correctly when Alt-Tabbing away from the app and back (which I want to allow) by checking for the WM_SETCURSOR message in my WndProc:
case WM_SETCURSOR:
{
if (mIsMouseGrabOn) // a bool that indicates if the mouse should be restricted to the cient area or not
SetCursor(gmInstance->m_cursorTargetGreen);
else
SetCursor(gmInstance->m_cursorTargetRed);
return 0; // prevent DefWndProc from resetting it
}
but on switching back the cursor is no longer clipped to the client area of my app's window. I've tried checking for WM_ACTIVATEAPP (as shown below) with no luck and tried checking for WM_ACTIVATE with the same code and the same result.
case WM_ACTIVATEAPP:
{
if(wParam == TRUE) // When we are activated
{
if (mIsMouseGrabOn)
GrabMouse(); // function to determine client area and call ClipCusor with the results
else
ClipCusor(NULL); // make the sure cursor is freed
}
else if(wParam == FALSE) // When we are deactivated
{
ClipCursor(NULL);
}
//return 0; // Let DefWndProc handle anything else
}
With the above code in place, the cursor changes correctly but doesn't get captured regardless of the state of mIsMouseGrabOn.
How do I get my cursor to be bound correctly when switching away from the app and back? What message(s) should I be watching for instead of WM_ACTIVATEAPP?
You can watch lost focus and got focus messages
1) WA_ACTIVE or WA_CLICKACTIVE - window got focus
2) WA_INACTIVE - window lost focus
and you should watch if your app run in fullscreen mode:
3) WM_DISPLAYCHANGE - when Windows changing desktop resolution
and resize message
WM_SIZE - if wparam equals SIZE_MINIMIZED,SIZE_MAXIMIZED or SIZE_RESTORED you can clip or unclip cursor
WM_SETFOCUS is sent after the Window receives keyboard focus, which allows ClipCursor to work.
If i press the "show desktop" button in Windows7, my program will still think its not minimized, and if i press WIN+D while my program is focused, only then my program will catch this minimize command. How can i check for 100% sure that my program is visible or not?
Here is my main loop:
while(!done){
if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)){
if(msg.message == WM_QUIT){
done = TRUE;
}else{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}else if(active){
render();
}
}
Edit3: Is this good? looks like its working:
case WM_WINDOWPOSCHANGED:
{
flags = ((PWINDOWPOS)lParam)->flags;
if((flags & 0x8000) && (flags & SWP_NOCOPYBITS) && (flags & SWP_FRAMECHANGED)){
active = !(flags & SWP_NOACTIVATE);
}
if((flags & 0x1000) && (flags & 0x0800) && (flags & SWP_NOMOVE) && (flags & SWP_NOSIZE)){
active = 1;
}
}
case WM_ACTIVATE:
{
active = !HIWORD(wParam);
return 0;
}
WM_ACTIVATE is sent when another window becomes active. When you say show desktop, no other window becomes active, so technically, your app is still active, even though it has been minimized.
You probably want to watch for WM_WINDOWPOSCHANGED. You can look at the flags to see what type of position event it was, or you can check IsIconic and IsWindowVisible whenever the window position changes.
There are a variety of potential functions that may get you the information you need depending on exactly what you want to do:
GetForegroundWindow() : Gets the window the user is currently "working" with. You could use this if you only wanted to draw things when a user is using your application but not another one.
GetActiveWindow() : Returns the active window within the calling thread which is probably not what you want. This might be useful if you wish to enable/disable drawing depending on which window was active within your own application.
GetFocus() : Returns the window with the current keyboard focus in the calling thread. Probably not what you want and use GetForegorundWindow() instead.
IsWindowVisible(): Returns whether the show/hide flag of the window is set to visible. This doesn't actually tell you whether the window is actually visible on the screen.
GetTopWindow(): Tells you the highest window in the z-order but not whether it actually has the focus/foreground. It may be possible for your window to be focused/activate/foreground but not have the highest z-order (I think anyways).
From your comments, however, you seem to actually want to see if there is at least one pixel of your window actually visible on the screen. For that I would probably use the technique mentioned in this SO question using the strangely named GetRandomRgn() although a simpler check may be to use GetClipBox() and check the return code for NULLREGION.
With Windows 8/10, there's another window visibility flag which is separate from IsWindowVisible. Check DwmGetWindowAttribute and the DWMWA_CLOAKED attribute.
Additionally, windows can be semitransparent, and GetLayeredWindowAttributes can tell you what the alpha level of a window is.
IsWindowVisible tells you if your window is visible. GetTopWindow tells you if it is the uppermost one in the Z order.
Try WM_ACTIVATEAPP.
wParam will be false if a window from any other app is getting focus. This includes pressing the "show desktop" button.