Mouse Cursor on Windows XP

#21 NOTE: I am an Associate, I am not a Garage Games employee, views expressed are my own.


As you feel the need to pull out sarcastic quotes about people not seeing the urgency of this minor UI issue... here are some quotes about problems and problem solving.

"When a problem comes along, you must whip it"
~ Devo

"A problem is a chance for you to do your best."
~ Duke Ellington (1899-1974)

"Problems are only opportunities in work clothes."
~ Henry J. Kaiser

"The best way to escape from a problem is to solve it."
~ Alan Saporta


And I leave this thread with the following:

"A clever person solves a problem. A wise person avoids it."
~ Albert Einstein (1879-1955)

#22 Hello Lab Rat,

If you would like to talk offline perhaps that's a better idea.

BTW - What exactly is an associate? I assume it means you have some relationship other than paying customer ?

#23 Associates are members of the community that've been exceptionally helpful to the community. LabRat, and a dedicated group of people like him, have spent a lot of time over the past five years contributing their time and effort to the GG cause, cheering us on, helping us out, and generally being awesome. Without GG Associates, and the spirit they exemplify shared among everyone here in the community, we would not be where we are today.

#24 The GG cause? What is the GG cause? Perhaps that's what I don't get. Thanx.

#25 Promoting indie developers and smaller, lighterweight development practices. Keeping good game making technology within the reach of everyone, not just those with huge budgets. Game-making as a sustainable practice, not one that burns people out and produces crap.

I would sum it up as "Changing the way games are made and played."

It's the motivation behind Torque, the IndieGamesCon, our website, and all of our other activities.

#26 To fill in the details where Michael Melson left off:

Add these lines Michael spoke about to the winWindow.cc file at the begining of the WindowProc switch block:

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

Now throw the rest 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 added line
               if ( !windowLocked )
               {
                  MouseMoveEvent event;

Hope that clarifies what Michael was talking about.

B--

#27 Thanx very much Brandon.

#28 Paul: It was no trouble at all, Michael really had the bright idea, but I hope that fixes everything how you wanted it.

B--

#29 @Brandon
Is you implementation the complete implementation? Or should it be used in conjunction with Michael's?

Michael has this code going in the switch block in WindowProc.

// We want to show the system cursor whenever we leave
      // our window, and it'd be simple, except for one problem:
      // showcursor isn't a toggle.  so, keep hammering it until
      // the cursor is *actually* going to be shown.      
      case WM_NCMOUSEMOVE:      
      {
         while(ShowCursor(TRUE) < 0);
         break;
      }
      case WM_MOUSEMOVE:
      {
         // keep trying until we actually show it
         while(ShowCursor(FALSE) >= 0);
         break;
      }

While you seem to have the first portion concerning the WM_NCMOUSEMOVE event being handled in WindowProc but do not have the WM_MOUSEMOVE changes that the Michael implemented for WindowProc.

Then you seem to take the WM_MOUSEMOVE change that Michael made to WindowProc and implemented it in OurDispatchMessages.

#30 @Todd: Just use the one I posted. The post I left shows you where to put the 2 lines of code Michael was talking about. I submitted a small resource explaining where to put the 2 lines to clarify, it just hasn't been approved yet.

B--

#31 It's up.

#32 Thanks Brandon, works like a charm

#33 @Todd: Glad I could help...

B--

#34 I've seen this behavior too on WinXP. For the part about clicking on the window after it's lost focus, here's what I have found:

1) If I click *inside* the TGE window to regain focus (not on the title bar, or window border - I guess this is called the "client area" of the window)... it seems to work with no strangeness.

2) If I click on the titlebar to gain focus, the window gets repositioned, most of the time, halfway off-screen. That's the "really annoying" part.

Has anyone figured out a fix for this "moves the window off-screen when regaining focus" problem?

Thanks,

Ed

#35 @Ed: I believe this fix also corrects the problem you are speaking about. Give it a try, and see if it fixes the problem.

B--

#36 Hi Everyone,

Quite a bit of traffic for something that is "too low priority to be fixed in the foreseeable future by GG".

#37 Quite a bit of traffic for a minor annoyance rather than a critical engine-crippling bug, I'd say. Good job to the community members for fixing this minor cosmetic flaw (akin to a freckle) and letting GG work on the larger problems (akin to growing a third head).

#38 Yep... it's "minor" in some sense. But it *is* very obvious to someone who might be considering purchasing a TGE license, when they run the demos... and think, "Man, they can't even get the window to operate correctly... hmmmm... this is a AAA game engine?"

Personally, I use windowed mode a lot so I can have other apps open at the same time, and switch back and forth, working on this and that, trying out stuff, etc.

And I've always been of the mindset that "little cosmetic flaws" are the easiest to fix... so there's no really *good* excuse for *not* fixing them (plenty of *lame* ones tho'), if they really are in fact SO easy to fix and SO minor and would only require the smallest effort... ;)

#39 Don't get me wrong tho'... GG has limited time and staff and they've got plenty of "more important" things to work on. I just want to see the fix for this problem(s) make it into the fold... :-)

#40 Chill out, guys. :) I noted that I'd logged this fix to include in the next RC on the 21st of April, when I posted:

Quote:
Michael,

Thank you very much for sharing your fix! I've added this to my list of fixes for the next RC.

I've been subscribed to this thread, too, because it seemed like some relevant discussion on the topic of fixing the bug was occuring, and I wanted to keep abreast of it. I think there's been some pretty constructive work going on here, and I'm glad that the community is (by and large) taking a positive note to GG's limited resources.

I am really proud of our community, and how we all work together to solve our problems and get our projects done. It's been a long tradition here, and I think it should continue for an even longer time to come.

World domination through collaboration!

(PS - I would love to see someone take point on fixing these cosmetic bugs. Great way to learn a bit more about the engine, great way to earn some community "street cred", and a great way to put those Win32 API skills to use. If anyone's interested, feel free to mail me about it (contact info in my profile). :)