Board index » delphi » Doing a ReWrite of CRT - a thought on ReadKey

Doing a ReWrite of CRT - a thought on ReadKey

I'm currently in the middle of a longish project to try and provide an
alternative fully functional Borland Compatible CRT unit.

As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
the keyboard which ignores things such as F11, F12 etc.

The thought has now occurred that perhaps I should enhance ReadKey to
use Int 16,10 automatically instead, if supported by the BIOS, which
would read these key codes as well.

Anyone any thoughts either way ?

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.

 

Re:Doing a ReWrite of CRT - a thought on ReadKey


   FWIW, I suggest providing as much functionality (e.g. F11 and F12 key
processing) as possible, because some users have requested such things in
the past.  I've never needed these specific keys, but I suspect the
"need" will grow, rather than diminish...
Quote
> I'm currently in the middle of a longish project to try and provide an
> alternative fully functional Borland Compatible CRT unit.

> As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
> the keyboard which ignores things such as F11, F12 etc.

> The thought has now occurred that perhaps I should enhance ReadKey to
> use Int 16,10 automatically instead, if supported by the BIOS, which
> would read these key codes as well.

> Anyone any thoughts either way ?

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <9sjjAHAfu+k2Y...@pedt.demon.co.uk>,
Pedt Scragg  <newsmas...@pedt.demon.co.uk> wrote:

Quote

>I'm currently in the middle of a longish project to try and provide an
>alternative fully functional Borland Compatible CRT unit.

>As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
>the keyboard which ignores things such as F11, F12 etc.

>The thought has now occurred that perhaps I should enhance ReadKey to
>use Int 16,10 automatically instead, if supported by the BIOS, which
>would read these key codes as well.

If you do so then make sure you handle the 224 codes properly. That is
if the scan code is zero, or more like under 70 then 224 in place of the
ASCII code is just that, character number 224. Otherwise, it should be
converted into zero as it just signals the difference between grey and
numeric bad cursor keys.

Well here is my version:

const scancode:char=#0;
var extended_kbd:boolean;  

function readkey:char; assembler;
         asm
         mov al,scancode
         or al,al
         jz @new
         mov scancode,0
         ret

@new:    mov ah,extended_kbd
         mov cl,4
         shl ah,cl
         int 16h
         cmp al,0E0h
         jne @x
         cmp al,70
         jbe @x
         xor al,al

@x:      or al,al
         jnz @out
         mov scancode,ah
@out:    end;

function status:word;
         inline(
         $B8/$00/$12/      {MOV AX,1200h}
         $CD/$16           {INT 16h }
         );

{$ifdef msdos}
const seg0040=$40;
{$endif}

begin
  tmp:=mem[Seg0040:$17];
  extended_kbd:=false;
  if lo(status)=tmp then begin
     mem[Seg0040:$17]:=tmp xor 7;
     tmp2:=status;
     extended_kbd:=(tmp2<>$1200) and (lo(tmp2)=tmp xor 7);
     mem[Seg0040:$17]:=tmp;
  End;
end.

Quote
>Anyone any thoughts either way ?

>--
>Pedt Scragg

>No-one is completely useless, they can always be a bad example.

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <9sjjAHAfu+k2Y...@pedt.demon.co.uk>,
  Pedt Scragg <newsmas...@pedt.demon.co.uk> wrote:

Quote

> I'm currently in the middle of a longish project to try and provide an
> alternative fully functional Borland Compatible CRT unit.

> As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
> the keyboard which ignores things such as F11, F12 etc.

> The thought has now occurred that perhaps I should enhance ReadKey to
> use Int 16,10 automatically instead, if supported by the BIOS, which
> would read these key codes as well.

> Anyone any thoughts either way ?

Only one way, YES.

It's nice to stay compatible, but given that most programs now written in
TP/BP will run on Pentium and higher PCs, all of them using new keyboards, it
would be a silly thing not to use these features.

In fact, I would even go so far as to suggest that you use 386 instructions...

Robert
--
Robert AH Prins
prin...@williscorroon.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <771pmd$7j...@nnrp1.dejanews.com>,
Robert AH Prins  <prin...@williscorroon.com> wrote:

Quote

>It's nice to stay compatible, but given that most programs now written in
>TP/BP will run on Pentium and higher PCs, all of them using new keyboards, it
>would be a silly thing not to use these features.

Naturally one should still keep backwards compatibility. It is not nice
if the compiler hangs as it gets no input.

Quote

>In fact, I would even go so far as to suggest that you use 386 instructions...

There is no point as BP does not give Dword alignment. One really gets
no increase in speed. Also in such a basic unit it is always nice to
keep compatibility. If there is a real need one can always check the
test8086 variable.

Osmo

Re:Doing a ReWrite of CRT - a thought on ReadKey


The complete unit Keyboard below includes revised ReadKey and KeyPressed
functions.  I believe that it does what you want.

     - RIch

unit Keyboard;

(* By Rich Pasco  <pa...@best.com>
   You may freely use provided that above comment is retained.

   This unit provides functions KeyPressed and ReadKey, which behave
   identically to the ones in the Turbo Pascal CRT unit, except that
   they support the enhanced keyboard when available.

   > The keyboard type is indicated by Boolean variable EnhKeybd.

   > Support for the enhanced keyboard may be disabled by assigning
     EnhKeyBd := false.

   > Never assign EnhKeybd := true if it is not originally true.

   As with the built-in ReadKey, keys with ASCII codes are returned in
   a single call; other keys are returned as a NUL (#0) followed by the
   scan code.

   This unit works with Turbo Pascal versions 4 and successors... *)

interface

uses
  DOS;

var
  EnhKeybd: Boolean;
{ BreakPressed: Boolean; }
function  KeyPressed: Boolean;
function  ReadKey: char;

implementation

var
  pending: char;

procedure QueryKeyboard; (* Set EnhKeyBd according to hardware. *)
  var r: registers;
  begin
    with r do begin
      AX:=$11FF;
      intr($16,r);
      if AL<>$FF then EnhKeybd := true
      else begin
        AX:=$1100;
        intr($16,r);
        EnhKeybd := AL<>$00;
      end;
    end;
 end;

function KeyPressed: Boolean;
  var regs: registers;
  begin
    if Pending <> #0 then KeyPressed := true
    else begin
      if EnhKeybd then Regs.ax := $1100 else Regs.ax := $100;
      Intr($16,Regs);
      KeyPressed := Regs.Flags and FZero = 0;
    end;
  end;

function ReadKey: char;
  var
    regs: registers;
  begin
    if pending <> #0 then begin
      ReadKey := pending;
      pending := #0;
    end else begin
      if EnhKeybd then Regs.ax := $1000 else Regs.ax := 0;
      Intr($16,Regs);
      if (regs.AL = $E0) and (regs.AH <> 0) then Regs.AL := 0;
      if Regs.AL <> 0 then ReadKey := chr(Regs.AL)
      else begin
        ReadKey := #0;
        pending := chr(Regs.AH);
      end;
    end;
  end;

(* Initialization code. *)
begin
  QueryKeyboard;
  pending := #0;
{
  BreakPressed := false;    (* Until the user presses it...   *)
  ExitSave := ExitProc;     (* Save for exit proc to restore  *)
  ExitProc := @MyExit;      (* Insert mine into the chain     *)
  GetIntVec($1B,Int1Bsave); (* Save for exit proc to restore  *)
  SetIntVec($1B,@Int1Bsvc); (* Service routine for Ctrl-Break *)

Quote
}

end.

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <3697e174.9016...@nntp.ftc-i.net>, Higgi...@ftc-i.SpAmZaP.net
writes

Quote

>Great idea, I think.  A couple questions... is doing this as easy as just
>changing CRT.ASM to call INT 16 with function 10 rather than func 00?  

Almost. As Osmo posted elsewhere in this thread, it is essential to handle
224 correctly and also, after determining in the BIOS can handle the
relevant calls or not, use the correct Int $16 calls for that BIOS.

The check is essential as, without a BIOS that correctly understands the Int
$16,10 calls, the computer may well hang if the wrong call is made.

The onoly problem I can personally see is if a program *requires* the
enhanced keyboard then old systems will not owrk correctly. Unfortunately
there is no way that a function can be added to CRT for the programmer to
call to check for an enhanced keyboard without altering the interface to the
CRT unit. Altering the interface would break usage of pre-compiled units
that used CRT that you had no source code for.[1]

Quote
>Does that
>introduce any other changes in action other than the ability to read all keys?

Coded correctly, enhancing ReadKey will not affect any other part of the CRT
unit.

[1]It is my intention to provide a separate unit with a publicly available
function that will determine if you can use the enhanced keyboard codes.

--
Pedt

Mobile sig does not exist *yet*

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <771pmd$7j...@nnrp1.dejanews.com>, Robert AH Prins
<prin...@williscorroon.com> writes

Quote

>In fact, I would even go so far as to suggest that you use 386 instructions...

Certainly if I was looking to rewrite SYSTEM it would be a good idea to
use 386 instructions when possible but I cannot (yet) see a need to use
Test8086 for conditional execution. If I do see areas where it would
advantageous then I will certainly do so.

--
Pedt

Mobile sig does not exist *yet*

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <771c7h$...@kruuna.Helsinki.FI>, Osmo Ronkanen
<ronka...@cc.helsinki.fi> writes

Quote
>In article <9sjjAHAfu+k2Y...@pedt.demon.co.uk>,
>Pedt Scragg  <newsmas...@pedt.demon.co.uk> wrote:

<enhancing ReadKey>

>If you do so then make sure you handle the 224 codes properly. That is
>if the scan code is zero, or more like under 70 then 224 in place of the
>ASCII code is just that, character number 224. Otherwise, it should be
>converted into zero as it just signals the difference between grey and
>numeric bad cursor keys.

Indeed.
Quote

>Well here is my version:

Thanks very much for the input, much appreciated.

Your routine for determining whether an enhanced keyboard is present is
far neater and smaller than the routine I had been intending to use.
When finished I will certainly credit your input on this.

--
Pedt

Mobile sig does not exist *yet*

Re:Doing a ReWrite of CRT - a thought on ReadKey


JRS:  In article <9sjjAHAfu+k2Y...@pedt.demon.co.uk> of Wed, 6 Jan 1999
23:02:55 in news:comp.lang.pascal.borland, Pedt Scragg

Quote
<newsmas...@pedt.demon.co.uk> wrote:
>I'm currently in the middle of a longish project to try and provide an
>alternative fully functional Borland Compatible CRT unit.

>As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
>the keyboard which ignores things such as F11, F12 etc.

>The thought has now occurred that perhaps I should enhance ReadKey to
>use Int 16,10 automatically instead, if supported by the BIOS, which
>would read these key codes as well.

I used to have a task in which it would have been useful.

I think, though, that one needs to sit on two stools, using conditional
compilation.  One should be able to have a fully compatible CRT, with
only the REAL bug (s) fixed, and all other limitations as standard; and
one should be able to turn on improvements, either individually or all-
at-once.

Another enhancement might be to provide named constants or functions to
access those variables in Seg0040 that are CRT-relevant - page number,
rows, columns, area, ... - and such as VideoBase (pointer to $B000/$B800,
or just the segment part).

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v4.00    MIME.
  Web <URL: http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <3697e174.9016...@nntp.ftc-i.net>,

Quote
 <Higgi...@ftc-i.SpAmZaP.net> wrote:

>Great idea, I think.  A couple questions... is doing this as easy as just
>changing CRT.ASM to call INT 16 with function 10 rather than func 00?  Does that
>introduce any other changes in action other than the ability to read all keys?

It is not that simple as the function 10h uses character code 224 to
point the to tell the difference between numeric pad and grey cursor
keys, one is 224, scancode and the other is 0,scancode (I do not recall
which is which.) To make things more complicated the code 224 is
perfectly valid character code (alpha) and can be entered with
Alt-Numeric pad and in theory could be as a key in a keyboard. (Though I
do not think there is such a keyboard in existence). This means one has
to use some kind of logic to tell the difference between alpha and the
cursor keys. One way is to check if the scancode is below 70. here is an
unit that handles F11 and F12 with readkey/keypressed interface (one has
to change keypressed also as the function 1 removes extended keystrokes)

Note a good programming practice says that one should not make F11 or
F12 the sole ways to invoke a critical function. One might for example
use Alt-F1 and Alt-F2 as alternative ways:

case scancode of
      Alt_f1,F11:...
      ...

One never knows if one has to use it with a standard keyboard. Note that
the code detects only support for extended kbd, not the actual presence
of such.

The unit should work on TP 4.0+

Unit F1112;

interface

var extended_kbd:boolean;  { Set to false if no extended support. }

function readkey:char;
function keypressed:boolean;

{* = extended }

Const F1=#59;    Shift_F1=#84;    Ctrl_F1=#94;    Alt_F1=#104;
      F2=#60;    Shift_F2=#85;    Ctrl_F2=#95;    Alt_F2=#105;
      F3=#61;    Shift_F3=#86;    Ctrl_F3=#96;    Alt_F3=#106;
      F4=#62;    Shift_F4=#87;    Ctrl_F4=#97;    Alt_F4=#107;
      F5=#63;    Shift_F5=#88;    Ctrl_F5=#98;    Alt_F5=#108;
      F6=#64;    Shift_F6=#89;    Ctrl_F6=#99;    Alt_F6=#109;
      F7=#65;    Shift_F7=#90;    Ctrl_F7=#100;   Alt_F7=#110;
      F8=#66;    Shift_F8=#91;    Ctrl_F8=#101;   Alt_F8=#111;
      F9=#67;    Shift_F9=#92;    Ctrl_F9=#102;   Alt_F9=#112;
      F10=#68;   Shift_F10=#93;   Ctrl_F10=#103;  Alt_F10=#113;
      F11=#133;  Shift_F11=#135;  Ctrl_F11=#137;  Alt_F11=#139;  {****}
      F12=#134;  Shift_F12=#136;  Ctrl_F12=#138;  Alt_F12=#140;  {****}

      Alt_1=#120;     Alt_2=#121;     Alt_3=#122;   Alt_4=#123;
      Alt_5=#124;     Alt_6=#125;     Alt_7=#126;   Alt_8=#127;
      Alt_9=#128;     Alt_0=#129;

      Alt_A=#30;      Alt_B=#48;      Alt_C=#46;     Alt_D=#32;
      Alt_E=#18;      Alt_F=#33;      Alt_G=#34;     Alt_H=#35;
      Alt_I=#23;      Alt_J=#36;      Alt_K=#37;     Alt_L=#38;
      Alt_M=#50;      Alt_N=#49;      Alt_O=#24;     Alt_P=#25;
      Alt_Q=#16;      Alt_R=#19;      Alt_S=#31;     Alt_T=#20;
      Alt_U=#22;      Alt_V=#47;      Alt_W=#17;     Alt_X=#45;
      Alt_Y=#21;      Alt_Z=#44;

      Shift_Tab=#15;
      Ctrl_tab=#148;  {*}
      Alt_tab=#165;   {*}

      Alt_Esc=#1;     {*}
      alt_BS=#14;     {*}

      Home=#71;
      Up=#72;
      PgUp=#73;
      Left=#75;
      Right=#77;
      End_=#79;    { Note the underscore as End is a reserved word }
      Down=#80;
      PgDn=#81;
      Ins=#82;
      Del=#83;

      Ctrl_PrtSc=#114;

      Ctrl_Left=#115;
      Ctrl_Right=#116;
      Ctrl_End=#117;
      Ctrl_PgDn=#118;
      Ctrl_Home=#119;
      Ctrl_PgUp=#132;

implementation

{$undef asm}

{$ifdef ver70} {$define asm} {$endif}
{$ifdef ver60} {$define asm} {$endif}

{$ifndef asm}
uses dos;
{$endif}

const scancode:char=#0;

{ This routine replaces crt.keypressed. It uses int 16h, ah=11h.
  if there is a scancode in buffer then it immediately returns true }

{$ifndef asm}
function keypressed:boolean;
var rg:registers;
begin
  if scancode>#0 then keypressed:=true
    else begin
           rg.ah:=ord(extended_kbd)*$10+1;
           intr($16,rg);
           keypressed:=rg.flags and fzero=0;
         End;
End;
{$else}

function keypressed:boolean; assembler;
         asm
         cmp scancode,0
         jz @peek
         mov al,1
         ret

@peek:   mov ah,extended_kbd
         mov cl,4
         shl ah,cl
         inc ah
         int 16h
         mov al,1
         jnz @out
         xor al,al
@out:    end;

{$endif}

{ This routine replaces the crt.readkey. It uses int 16h. ah=10h.
  If there is a scancode in buffer it is immediately returned.

  They grey cursor keys report E0h as ASCII code instead of
  zero, so this has to be changed to zero. However, one must be
  careful as ASCII E0h (224d) can also be alpha as entered from
  keypad }

{$ifndef asm}
function readkey:char;
var rg:registers;
begin
  if scancode>#0 then begin
      readkey:=scancode;
      scancode:=#0;
      exit;
  End;
  rg.ah:=ord(extended_kbd)*$10;
  intr($16,rg);
  if (rg.al=$E0) and (rg.ah>70) then rg.al:=0;  { Grey cursor keys }
  readkey:=chr(rg.al);
  if rg.al=0 then scancode:=chr(rg.ah);
End;

{$else}

function readkey:char; assembler;
         asm
         mov al,scancode
         or al,al
         jz @new
         mov scancode,0
         ret

@new:    mov ah,extended_kbd
         mov cl,4
         shl ah,cl
         int 16h
         cmp al,0E0h
         jne @x
         cmp al,70
         jbe @x
         xor al,al

@x:      or al,al
         jnz @out
         mov scancode,ah
@out:    end;

{$endif}

var tmp:byte;
    tmp2:word;

function status:word;
         inline(
         $B8/$00/$12/      {MOV AX,1200h}
         $CD/$16           {INT 16h }
         );

{$ifdef msdos}
const seg0040=$40;
{$endif}

begin
  tmp:=mem[Seg0040:$17];
  extended_kbd:=false;
  if lo(status)=tmp then begin
     mem[Seg0040:$17]:=tmp xor 7;
     tmp2:=status;
     extended_kbd:=(tmp2<>$1200) and (lo(tmp2)=tmp xor 7);
     mem[Seg0040:$17]:=tmp;
  End;
end.

Re:Doing a ReWrite of CRT - a thought on ReadKey


On Wed, 6 Jan 1999 23:02:55 +0000, Pedt Scragg

Quote
<newsmas...@pedt.demon.co.uk> wrote:

>I'm currently in the middle of a longish project to try and provide an
>alternative fully functional Borland Compatible CRT unit.

GOOD FOR YOU.

Quote
>As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
>the keyboard which ignores things such as F11, F12 etc.

NOT TRUE, or they wouldn't list all variations of F11 and F12 in the
appendix to the manual (TP6).

Quote
>The thought has now occurred that perhaps I should enhance ReadKey to
>use Int 16,10 automatically instead, if supported by the BIOS, which
>would read these key codes as well.

>Anyone any thoughts either way ?

The specification to be met, WITHOUT DEVIATION, is in the manual.
Matching the functionality will not be easy. I would suggest you take
a look at the RTL source and go from there. Alternatively, you could
get someone with access to the code to write a VERY tight spec for you
and you develop the code to match that spec.
Quote
>--
>Pedt Scragg

>No-one is completely useless, they can always be a bad example.

Really? Sorta like people who don't RTFM?

Bill
------------------------------
Remove NOSPAM for direct reply.

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <36953ad0.216...@news.winshop.com.au>,
  bill_boul...@NOSPAM.winshop.com.au (Bill Boulton) wrote:

Quote
> On Wed, 6 Jan 1999 23:02:55 +0000, Pedt Scragg
> <newsmas...@pedt.demon.co.uk> wrote:

> >I'm currently in the middle of a longish project to try and provide an
> >alternative fully functional Borland Compatible CRT unit.

> GOOD FOR YOU.

> >As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
> >the keyboard which ignores things such as F11, F12 etc.

> NOT TRUE, or they wouldn't list all variations of F11 and F12 in the
> appendix to the manual (TP6).

> >The thought has now occurred that perhaps I should enhance ReadKey to
> >use Int 16,10 automatically instead, if supported by the BIOS, which
> >would read these key codes as well.

> >Anyone any thoughts either way ?

> The specification to be met, WITHOUT DEVIATION, is in the manual.

Agree & disagree...

Agree: changing it might introduce bugs in currently working programs, and
changing the interface would cause even more problems.

Disagree: Time has passed on, and if additional functionality is useful I am
of the opinion that it should be included, even if that introduces a some
incompatibilities. As I mentioned in an earlier post, if 386 instructions are
useful, USE them, even if this means that a few people cannot use the new
unit.

Quote
> Matching the functionality will not be easy. I would suggest you take
> a look at the RTL source and go from there. Alternatively, you could
> get someone with access to the code to write a VERY tight spec for you
> and you develop the code to match that spec.

The latter would certainly avoid problems about copyright, but may not be
feasible.

Robert
--
Robert AH Prins
prin...@williscorroon.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <36953ad0.216...@news.winshop.com.au>,

Quote
Bill Boulton <bill_boul...@NOSPAM.winshop.com.au> wrote:
>On Wed, 6 Jan 1999 23:02:55 +0000, Pedt Scragg
><newsmas...@pedt.demon.co.uk> wrote:

>>As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
>>the keyboard which ignores things such as F11, F12 etc.

>NOT TRUE, or they wouldn't list all variations of F11 and F12 in the
>appendix to the manual (TP6).

Some of us actually rely on more concrete evidence than what one could
conclude from what is listed in some manual. (this evidence can include
testing, reading the source and relevant documentation like Ralf Brown's
interrupt list).

Osmo

Re:Doing a ReWrite of CRT - a thought on ReadKey


In article <36953ad0.216...@news.winshop.com.au>, Bill Boulton
<bill_boul...@NOSPAM.winshop.com.au> writes

Quote

>>As you may be aware, the TP/BP ReadKey function uses Int 16,00 to read
>>the keyboard which ignores things such as F11, F12 etc.

>NOT TRUE, or they wouldn't list all variations of F11 and F12 in the
>appendix to the manual (TP6).

Although the manual *does* list these codes, it does not follow that
CRT.ReadKey can actually make use of them.

It is a trivial matter to prove that the CRT.ReadKey function, as
supplied by Borland, does not recognise F11 etc. despite them being
listed in the Manual.

Quote

>The specification to be met, WITHOUT DEVIATION, is in the manual.
>Matching the functionality will not be easy. I would suggest you take
>a look at the RTL source and go from there. Alternatively, you could
>get someone with access to the code to write a VERY tight spec for you
>and you develop the code to match that spec.

I do have the RTL available to me and it is a good resource for working
out how Borland implemented some of the functions - therefore providing
the basis for rewriting the same functionality.

I do very much agree that any replacement unit *must* have the same
functionality as the original Borland supplied unit with regards to the
procedures and functions supported and must be _drop in_

It is possible of course that a replacement unit may have enhanced
functionality, where available, without compromising the original
especially as the interface part of the unit must be identical to the
Borland supplied unit.

As the replacement must have exactly the same interface as the original
unit (to avoid unit mismatch errors) I think that I am only going to be
able to release CRT.TPU as I could not provide the CRT.PAS source
without compromising Borland's License Agreement even if the remainder
of the unit was completely rewriten.

<sig>

Quote
>>No-one is completely useless, they can always be a bad example.
>Really? Sorta like people who don't RTFM?

Indeed, also those who ask VFAQ's without reading first :-)

--
Pedt

Mobile sig does not exist *yet*

Go to page: [1] [2]

Other Threads