Bug 124 - Micropause 'warning' window doesn't move away from cursor
Status:
RESOLVED WONTFIX
Component:
Core :: Win32
Version:
0.2.0
Hardware:
PC Windows 2000
Importance:
P3 normal
Target Milestone:
---
Assignee:
Raymond Penners
URL:
Depends on:
Blocks:
Reported:
Oct 4 2002 00:37:05 UTC
by:
Arnaud Gouder
Modified:
Oct 22 2002 01:56:53 UTC
WhoWhenWhatRemovedAdded
Raymond PennersOct 4 2002 02:03:24 UTCstatusNEWRESOLVED
resolutionWONTFIX
Raymond PennersOct 4 2002 02:48:37 UTCstatusRESOLVEDREOPENED
resolutionWONTFIX
Raymond PennersOct 10 2002 11:18:15 UTCstatusREOPENEDRESOLVED
resolutionWONTFIX
Description
Arnaud Gouder  Oct 4 2002 00:37:05 UTC
The Micropause 'warning' window, moves away form the mouse cursor, but it 
doesn't do the same for the 'typing' cursor in the active application. So if 
that is in the middle of the screen when the warning window popups, it doesn't 
move away....
Comment 1
Raymond Penners  Oct 4 2002 02:03:24 UTC
Sorry, but this simply cannot be fixed properly. In theory, it is possible to
check if the active window is a standard text area, or textfield, try and fetch
its cursor position and do some evasive manouvers.

In practice, however, most applications do not use the standard widgets for
their edit controls. Consider Emacs, it has its own custom display that draws
its own cursor. Just use Spy++ on Word, Emacs, Mozilla, Studio and Explorer, and
see if you can detect a common text widget ... 

Comment 2
Raymond Penners  Oct 4 2002 02:48:37 UTC
I snooped around a bit, and learned about GetCaretPos(). Perhaps I can put this
at use, but don't expect _all_ applications to work with it. For example, a guy
at Usenet mentions:

> I am writing a program that needs to popup a menu in any running app at the
> current caret position. Using GetCaretPos() works fine for the majority of
> applications, but a number of apps (in particular MSWord 95) always return
> a (0,0) point regardless of where the caret is. Has anyone else seen this
> behaviour and is there a work around ?
Comment 3
Raymond Penners  Oct 10 2002 11:18:15 UTC
Okay, I gave it a spin. Conclusion: it works for Notepad and some standard text
fields, but not for Mozilla, Emacs and lots of other apps. The coordinates
returned are faulty, so I cannot even tell the difference between successful
caret coordinates, and bogus coordinates. This makes it impossible to add this
feature... WONTFIX.

If anybody thinks they can do better than me, try improving this code:

#include <windows.h>

int main(int argc, char* argv[])
{
    while (1) {
      HWND hwnd1 = ::GetForegroundWindow ();
      DWORD a = ::GetWindowThreadProcessId (hwnd1, NULL);
      DWORD b = ::GetCurrentThreadId();
      ::AttachThreadInput (a, b, TRUE);
      HWND hwnd2 = ::GetFocus ();
      POINT pt;
      if (::GetCaretPos ((LPPOINT) &pt))
        {
          ::ClientToScreen (hwnd2, (LPPOINT) &pt);
          ::AttachThreadInput (a, b, FALSE);
          printf("%d-%d\n", pt.x, pt.y);
        }
      Sleep(1000);
    }
}