Controlling CWaitCursor from different methods

Another challenge then ...
I changed my CDialog to be a CPropertyPage now... and guess : the cursor does not change any more using BeginWaitCursor().

Any idea why?? How could I do that?

Marina

Why did you that???? My boss will kill me if he knows what I'm spending my time on... Well, well, here we go with some thoughts. Haven't tested much, and again I'm no expert:

I think the problem is still related to some MFC-classes doing their own thing with cursors, only that now we deal with new classes. CPropertyPage is derived from CDialog, it might or might not have its own implementation of OnSetCursor(). Haven't checked.

But, and here I think the main issue in your case lies, if you now have your dialog implemented as CPropertPage, you probably also have involved the class CPropertySheet. This one is NOT derived from CDialog, and limited testing indicates that this class definetly has its own handling of Cursor (or maybe it uses the CWnd-implementation).

If you have your CPropertyPage dialog implemented in the "standard" way, i.e. with some tabs to bring up different CPropertPages, be aware that when you click the tab, you're actually interacting with the CPropertySheet class, not your CPropertyPage. Since the CPropertPage shows up "immediately", and long before you're able to move your mouse away from the CPropertySheet, any cursor settings done in your CPropertyPage::OnInitDialog() will be overridden by CPropertySheet::OnSetCursor() immediately...

BTW; Found that for instance the header in a CListBox also changes cursor to whatever it wants, arrow or cross-hair, dependant on where you place the pointer. It's tricky these things, it seems like. Lots of "under the hood action" performed by MFC by default you need to handle appropriately...

Sorry I don't have time to test out more, and maybe come up with a complete solution, maybe tomorrow, if you still have the issue... ;)

Quote:

---

Originally Posted by DP TWO

Simply handle WM_SETCURSOR in your dialog class and make sure that the default handler isn't called. Like this:

Code:

---

BOOL CYourDlg::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message)
{
        // TODO: Add your message handler code here and/or call default

        //return CDialog::OnSetCursor(pWnd, nHitTest, message); // Don't invoke this.
        return TRUE; // Do this instead
}

---

It seems like CDialog sets the cursor by default, thus you need to block its default action. Why it is like this I don't know. Maybe someone else can elaborate more on that?

---

WM_SETCURSOR if windows' way of asking the window beneath the mouse pointer to modify it to it's wishes.. Different window classes do it in their own way. A grid class may show a + kind of cursor and list view may show a hand cursor and things like that. Generally, a defautl window proc would handle this message to return the handle to the cursor passed during RegisterClass in the WNDCLASS structure's hCursor member.

Hence, calling CDialog::OnSetCursor does that bring back the arrow cursor.

Now, what the OP could do is:

Code:

---

CYourclass::OnSetCursor(..)
{
    if(m_bIsProcessing)
      SetCursor(m_hWaitCursor) ; // this could be LoadCursor(IDC_WAIT) in ctor
  else
        CYourBaseClass::OnSetCursor()
}

---

Quote:

---

Originally Posted by DP TWO

you might need to introduce a helper-flag to be used to determin if the wait cursopr should be restored or not after such an action.

---

I agree with Kirants that a helper flag to be used to determine which cursor to load in OnSetCursor would be doable and also preferrable maybe, and it was a suggestion earlier in this thread. At that time Marina needed to handle two dialogs and set the wait cursor in both, based on some action in one. That would have required messages to be sent from one to the other (unless she did some class deriving allowing them to know about each other).

Maybe now, with the change to PropertyPage, the helper flag would be an easier and better solution? I still think she needs to look to he CPropertySheet class as well (which I presume she's using, since she's dealing with Property Pages). If the action requiring wait cursor happens in CPropertyPage, CPropertySheet needs to know about as well to ensure desired cursor effect, I would imagine.

My main point is that when dealing with cursor shapes, we need to take care because some classes might override our desires without us knowing about it, causing unexpected cursors to show up. If you don't do anything, MFC has a default way of handling a lot of stuff.... This is, I believe, also what Kirantis is pointing out.

Quote:

---

Originally Posted by DP TWO

If you don't do anything, MFC has a default way of handling a lot of stuff.... This is, I believe, also what Kirantis is pointing out.

---

Close.. MFC doesn't have that much a role here. It is more Windows doing that..

Of course, you're right... I've been lured away from the good old days of using Windows APIs, to using MFC, and now have a tendency to give MFC more credit/blame it more than what it actually deserves...

Marina, my advice: Do not use CWaitCursor. It uses BeginWaitCursor and EndWaitCursor.
See this thread and this thread for more.

Thank you John, and thank you all.

JohnCz , if I use BeginWaitCursor() this brings back to the first problem, which is that I 'm not calling the begin and the end from the same function.

Thanks for the reminder about the handling of OnSetCursor().