[fpc-devel] Quick patch for bug 3762

[Tomas Hajny]

From: "Sterling Bates" <iwannabefp at yahoo.ca>
To: fpc-devel at lists.freepascal.org
Subject: RE: [fpc-devel] Quick patch for bug 3762
Date: 31.3.2005 - 8:26:06


> 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 :)

Fine. I can perform testing for OS/2 and GO32v2, and testers for
Unix targets shouldn't be difficult to find in FPC core team, I
guess... ;-) In addition, you can do everything on one platform
(successively replacing all Win32 API calls with the low-level
functions from our "console" units) and then perform necessary
testing on other platforms just before switching them to the common
implementation, so this is rather easy to handle, IMHO. I'd just
suggest to refer to the GO32v2 implementation while working on it,
because this one is probably the most compatible one to TP/BP
behaviour.


> Another problem with Windows (not sure about other OSs) is in
> bug 2084.  (Use the second example in the description.)  I was

That's the point - there are quite a few different issues on
different platforms. Instead of trying to address them in
platform-specific implementations, it would be probably better to
replace them with common implementation based on existing "console"
units (Keyboard, Video, Mouse) which are already used in FVision and
thus in our text-mode IDE (so there's quite some chance they might
be working fairly well nowadays). I don't know whether this would
eliminate all the problems (see below too), but if not, it would
probably mean that the problem already exists in these console
units and should be fixed there anyway. Especially the clash
between Crt and "console" (former "FPC API" units) appearing in bug
2084 is exactly something which should get automatically resolved
with this Crt unit rewrite.


> 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.

I'm no Win32 person, so I wouldn't be probably able to help with
details here. However - does unit Keyboard suffer from the same
problem (GetKeyEvent versus PollKeyEvent)?


> 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
> :-)

The fewer critical sections the better - I'd try to avoid that
unless absolutely necessary.

Tomas



-- 
! NOVINKA ! -- SURVIVAL L-Carnitin+Chrom -- Zbav se kil a dej se do
formy! http://www.sportwave.cz