search

minnkyaw / waitzar

This project has evolved, from a simple plugin which converts romanised Burmese to native text, to a solid multi-font system for typing Burmese at all levels of its computerized history: past (Win Innwa), present (Zawgyi-One), and future (Unicode 5.1). Community involvement has been overwhelmingly positive, leading to a re-thinking of the Wait Zar romanisation (now in progress), collaboration and support from several developers and forums, and a general positive attitude towards the technology.
Other
0 stars 0 forks source link

Better support for cursor tracking #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
#Suggestion by Dr. Carbon, WaitZar 1.5+
There are ways to track the text cursor; e.g.,
http://msdn.microsoft.com/en-us/library/ms538471(VS.85).aspx

...even if we can't implement this on all systems, XP and Vista seem to
have built-in support and they represent the majority of our user base.

If we can #define out the code for this under Windows 2000/NT, then I'm
happy to implement this.

Original issue reported on code.google.com by seth.h...@gmail.com on 20 Aug 2008 at 8:04

GoogleCodeExporter commented 9 years ago 
Wait.. this one is probably better:
http://msdn.microsoft.com/en-us/library/ms538475(VS.85).aspx

Original comment by seth.h...@gmail.com on 20 Aug 2008 at 8:22

GoogleCodeExporter commented 9 years ago 
Ok, I've added rudimentary support to SVN for this. However, there are some 
flaws,
and I can't figure out if they're in my code, or from Windows. Plus, it only 
works on
certain windows. 

I'm disabling it for now.... we'll have a look after 1.6.

Original comment by seth.h...@gmail.com on 11 Sep 2008 at 5:34

GoogleCodeExporter commented 9 years ago 
Putting this as medium priority --I want to add an option to allow rudimentary
support for version 1.7, off by default.

Original comment by seth.h...@gmail.com on 9 Feb 2009 at 6:11

GoogleCodeExporter commented 9 years ago 
Ok, and the summary is:
  Call GetForegroundWindow() to get the window with the caret.
  Call AttachThreadInput() to allow you to get more information about this window. 
    *Attaching a thread with Window capabilities is a BAD IDEA as it will steal focus.
  Call the confusingly-named GetFocus() to get the child window with the focus (and
thus the caret)
  Get the caret, get the child window's client area, add them, and you'll have your
caret's position (I'm thinking it's the top of the caret)
  Call DetachThreadInput(), lest we get information from the wrong window.

The current solution creates and destroys a thread each time the window 
appears. This
isn't so bad, but I'd rather have the thread "reset" somehow. Again, though, 
it's a
minor point.

There is a config file option for people who prefer to drag the window to a 
special
location and leave it there. Enabled by default, because I rather like this 
feature
more than I thought I would.

Thanks, Carbon....
-Closed-

Original comment by seth.h...@gmail.com on 27 Mar 2009 at 10:22