Re: [fpc-devel] Quick patch for bug 3762
From: DrDiettrich [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Quick patch for bug 3762 Date: 31.3.2005 - 22:49:06 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). From the discussion I have the impression that there exist problems in separating keyboard and mouse events. If I'm right here, then I'd suggest to separate platforms with separate mouse and keyboard events from platforms with common events for both devices. The platform independent implementation then should assume and use separate queues, as provided (separated if required) by the platform specific code. Implementation of the low-level units (Keyboard, Mouse and Video) for all supported platforms is different from each other (well, with the exception of Unix being handled as one common group), so no special separation is necessary there. OTOH, Crt (once rewritten to be built on top of these low-level units) should be (almost?) completely platform independent and thus no separation would exist there either. Tomas -- Akcni unorova nabidka 3 za cenu 1! Ziskejte VOLNY ADSL 512/128 3GB za cenu 1GB! http://adsl.volny.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
Sterling Bates schrieb: 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 This is Windows specific. My initial attempt to get around this is to tie KeyPressed to EventHandleThread as well. [...] 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 :-) Yes, a quick fix can be made by replacing the ReadConsoleInput() in winevent.pp by a PeekConsoleInput() call and crt works again. Maybe this was even intended by the original developer since there is a read, but don't remove the event comment in front of the offending line (although it uses the ReadConsoleInput() call which actually removes the event). Already sent this patch to a developer a two days ago (or so). But may have undesirable side effects if no one else is eating the console events (not sure if this is actually possible, that means a problem, in console programs). The IDE does not seem to mind though from a short try afair. Seems like we are working on the same things atm =) Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
From: Thomas Schatzl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Quick patch for bug 3762 Date: 31.3.2005 - 12:44:20 Sterling Bates schrieb: 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 :) . . Seems like we are working on the same things atm =) Which part do you concetrate on, Thomas? Is your work related to unit Crt (which could/should become cross-platform in its majority), or are you rather fixing implementation of console (API) units (keyboard, mouse, video) for Windows (which includes winevent)? These two don't need to interfere, IMHO (so there definitely can be enough space for both of you ;-) ). Tomas -- Akcni unorova nabidka 3 za cenu 1! Ziskejte VOLNY ADSL 512/128 3GB za cenu 1GB! http://adsl.volny.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
Hello, But may have undesirable side effects if no one else is eating the console events (not sure if this is actually possible, that means a problem, in console programs). More testing showed that this is a problem after all. So don't apply it. The IDE does not seem to mind though from a short try afair. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
Tomas Hajny wrote: 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). From the discussion I have the impression that there exist problems in separating keyboard and mouse events. If I'm right here, then I'd suggest to separate platforms with separate mouse and keyboard events from platforms with common events for both devices. The platform independent implementation then should assume and use separate queues, as provided (separated if required) by the platform specific code. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Quick patch for bug 3762
Turns out the CRT unit in OS/2-- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored. SterlingPost your free ad now! Yahoo! Canada PersonalsIndex: crt.pas === RCS file: /FPC/CVS/fpc/rtl/os2/crt.pas,v retrieving revision 1.8 diff -w -b -i -u -p -1 -0 -r1.8 crt.pas --- crt.pas 14 Feb 2005 17:13:31 - 1.8 +++ crt.pas 27 Mar 2005 04:27:58 - @@ -379,25 +379,22 @@ var ca:Pchar; begin i:=0; getcursor(y,x); while i=len-1 do begin case s[i] of #8: x:=x-1; #9: x:=(x-lo(windmin)) and $fff8+8+lo(windmin); - #10: ; - #13: begin - x:=lo(windmin); - inc(y); -end; + #10: inc(y); + #13: x:=lo(windmin); else begin ca:[EMAIL PROTECTED]; n:=1; while not(s[i+1] in [#8,#9,#10,#13]) and (x+n=lo(windmax)) and (ilen-1) do begin inc(n); inc(i); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
From: Sterling Bates [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject: [fpc-devel] Quick patch for bug 3762 Date: 30.3.2005 - 12:18:31 Hi Sterling Turns out the CRT unit in OS/2 -- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored. Thanks for your patch, it's correct and I'll apply it once I get to a machine with CVS access (unless somebody else applies it earlier ;-) ). 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? Regards Tomas -- Akcni unorova nabidka 3 za cenu 1! Ziskejte VOLNY ADSL 512/128 3GB za cenu 1GB! http://adsl.volny.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
On 30 mrt 2005, at 13:39, Tomas Hajny wrote: 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? We can't give you a free computer if you do so, though :) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Quick patch for bug 3762
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===
RCS file: /FPC/CVS/fpc/rtl/win32/crt.pp,v
retrieving revision 1.24
diff -w -b -i -u -p -1 -0 -r1.24 crt.pp
--- crt.pp 14 Feb 2005 17:13:32 - 1.24
+++ crt.pp 31 Mar 2005 06:08:59 -
@@ -20,21 +20,22 @@ interface
{$i crth.inc}
procedure Window32(X1,Y1,X2,Y2: DWord);
procedure GotoXY32(X,Y: DWord);
function WhereX32: DWord;
function WhereY32: DWord;
implementation
uses
- windows;
+ windows,
+ winevent;
var
SaveCursorSize: Longint;
{
definition of textrec is in textrec.inc
}
{$i textrec.inc}
@@ -347,130 +348,138 @@ begin
end
else
case Scancode of
// Function keys
$57..$58: inc(Scancode, $2E); // F11 and F12
end;
RemapScanCode := ScanCode;
end;
+var
+ KeyEvt: THandle; // signal that a key is ready for processing
+ KeyPrcEvt: THandle; // signal that the key has been processed
+ KeyBuf: PInputRecord; // pointer to incoming INPUT_RECORD
+ KeyCS: TCriticalSection; // restricts KeyPressed access to single thread
+
+
+procedure OnKeyEvent(var ir: INPUT_RECORD);
+begin
+ KeyBuf := @ir;
+ Windows.SetEvent(KeyEvt);
+ WaitForSingleObject(KeyPrcEvt, INFINITE);
+ Windows.ResetEvent(KeyEvt);
+end;
+
+
function KeyPressed : boolean;
var
nevents,nread : dword;
- buf : TINPUTRECORD;
AltKey: Boolean;
c : longint;
begin
KeyPressed := FALSE;
+ { Leave KeyPrcEvt set at the end of the proc; this avoids deadlocks in }
+ { OnKeyEvent while waiting for the event to signal. }
+ Windows.ResetEvent(KeyPrcEvt);
+
if ScanCode #0 then
KeyPressed := TRUE
else
begin
- GetNumberOfConsoleInputEvents(TextRec(input).Handle,nevents);
- while nevents0 do
- begin
- ReadConsoleInputA(TextRec(input).Handle,buf,1,nread);
- if buf.EventType = KEY_EVENT then
-if buf.Event.KeyEvent.bKeyDown then
+ WaitForSingleObject(KeyEvt, INFINITE);
+
+ if KeyBuf^.Event.KeyEvent.bKeyDown then
begin
{ Alt key is VK_MENU }
{ Capslock key is VK_CAPITAL }
- AltKey := ((Buf.Event.KeyEvent.dwControlKeyState AND
+ AltKey :=
Re: RE: [fpc-devel] Quick patch for bug 3762
From: Sterling Bates [EMAIL PROTECTED] To: fpc-devel@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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
