[fpc-devel] Quick patch for bug 3762

[Sterling Bates]

In response to Tomas Hajny:
 
I'd certainly be willing to give it a try.  Granted, I only have Windows XP, but if I'm careful it should be a smooth transition.  No promises on a timeline :)
 
Another problem with Windows (not sure about other OSs) is in bug 2084.  (Use the second example in the description.)  I was able to narrow down what the problem is, and it's pretty daunting.  Essentially, initmouse will call SetMouseEventHandler() in winevent.pp.  This spawns a thread that runs EventHandleThread in a fairly tight loop, which captures all console input.
 
The problem comes when ReadKey then calls KeyPressed, which also attempts to read console input.  No matter what, EventHandleThread will capture the input (since it places a call to WaitForSingleObject, waking up the instant something is in the queue), leaving KeyPressed with nothing to process.
 
My initial attempt to get around this is to tie KeyPressed to EventHandleThread as well.  (If you can't beat 'em, join 'em, right?)  I've attached the work I've done so far, but it's not quite right.  With two ReadKey calls in a row, the first will read the key, the second will exit without even reading the queue.  I think this is because the first ReadKey hasn't had a chance to clear the ScanCode variable before the second ReadKey call to KeyPressed (which exits when ScanCode <> #0).  This results in the DOS window outputting a garbage character when the program finishes because there's still something in the queue.
 
It's possible to fix it by wrapping the contents of ReadKey in a critical section, but that, to me, is just more overhead.  I think there's a more elegant solution waiting to be discovered :-)
 
Thanks,
 
Sterling
 
 
Your message below:
------------------
Unfortunately, the problem is wider - there are several other issues with the current OS/2 implementation (if you just quickly compare it with e.g. the GO32v2 implementation, you'd find some other problems too - e.g. handling of #8 is surely incorrect etc.).

The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance?




---------------------------------
Post your free ad now! Yahoo! Canada Personals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20050331/69100b85/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug2084.diff
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20050331/69100b85/attachment.ksh>