Missing Mouse cursor

#1 I'm pretty sure that the problem is that the Windows T2D window has the mouse pointer icon set to NULL. Meaning that once the mouse is over any part of the Window (including the non-client area), it disappears. The mouse cursor drawn by Torque is a sprite, not the Windows mouse pointer. To get the behavior you want, you'd have to call SetCapture, ReleaseCapture, and SetCursor and track when the mouse pointer is in the client area (turn off), non-client area (turn on), and outside the window altogether (ReleaseCapture). For normal Windows programs this wouldn't be too hard, but I haven't looked into this in Torque. I find it irritating too, though. :-)

#2 Jason (s)

There is a resource about this by Brandon Maness but it may be a TGE one only ->www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7688

If you cannot see that, the main bit is below (its only a short one and I dont see anything that shouldnt be here) :

...

Add these lines to the engine\platformWin32\winWindow.cc file at the begining of the WindowProc switch block:

case WM_NCMOUSEMOVE:
      {
         while(ShowCursor(TRUE) < 0);
         break;
      }

Now throw the last line a little further down in the OurDispatchMessages code block. Find the switch statement then right after the case WM_MOUSEMOVE: throw in just the while statement. It should look like this.

case WM_MOUSEMOVE:
      while(ShowCursor(FALSE) >= 0); //Here is the one added line
               if ( !windowLocked )
               {
                  MouseMoveEvent event;

Note: If you are wondering why you don't just set the ShowCursor to true or false without the while statement the answer is that the ShowCursor function is really a value and not a switch. When you set it to true or false it increases or decreases the value it has stored. When the value is below 0 it turns off the cursor. Above that and it turns the cursor on.

Thanks again to Michael Melson for posting the file, location, and commands for this fix.

...

#3 Thanks David, I will give this a try tonight!

(Yet another example of why not having access to TGE fourms makes me grumpy)

#4 No problem - hopefully TDN will make all the relevant core engine stuff available to all.

#5 Fyi, this works! pay attention to David's "note" 3 posts up.

#6 It worked for me too. But I had to find a different fix, because my real problem was how the mouse cursor would disappear completely within Smalltalk while using T2D as a DLL. I noticed a couple of discrepancies: (1) ShowCursor(TRUE) is called too many times when T2D is shut down; (2) whenever I toggled between applications, T2D would received two WM_ACTIVATE events, causing ShowCursor(FALSE) to be called an extra time (I don't know whether this is a problem for the unmodified engine or an artifact of my changes). Neither of these issues is much of a problem when using T2D as a stand-alone executable (who cares if ShowCursor is called too many times upon shutting down if the entire process terminates?).

The real issue, however, was that the cursor's visibility needed to be window-based, not process-based. The workaround was to set the window's class cursor to NULL, stub out all calls to ShowCursor, and invoke SetCursor(NULL) every time there's a WM_SETCURSOR event. As a bonus, the title bar problem was also fixed. But if you aren't running T2D within an existing process, Brandon's solution is simpler.

#7 @Aaron: i had this problem too.

my solution was to:

1) add an "on mouse move" event in my .NET Form GUI that would enable the cursor.
2) add an "on mouse leave" event to disable the cursor.

doing the step outlined by david wasnt really nessicary for me, but I did it anyway because it is very annoying to not be able to click the title menu.

#8 @Jason:
Ah, I was wondering whether T2D.NET had been affected. I had considered a solution similar to yours, but I think it would have been more difficult to implement (e.g., the "mouse leave" message isn't sent unless the cursor is repeatedly registered for tracking) -- also, less efficient and less useful to non-Smalltalkers. It sounds like .NET hides some of that drudgery.

My fix also solved the title bar problem. I guess WM_SETCURSOR is sent only when the cursor is within the client area of the window.