Borislav,

actually adding the second parameter to DoDefault() made the strange behavior stop. I don't mean to be ungrateful, but I was not so interested in solving the problem itself, because I already had that solved. I was more interested in knowing WHY the construct

If condition1 and condition2
  do something
Endif

behaves differently from

If condition1 
  If condition2
    do soemthing
  Endif
Endif

I am pretty sre that this is a bug, but I don't expect it to be fixed. :-)

>Tore, I didn't test the code, but one thing I saw You call DODEFAULT() w/o second parameter. When you call DODEFAULT() function you always have to send the same number of parameters as your method/event:
>

>LPARAMETERS nKeyCode, nShiftAltCtrl
>if IsAlpha(Chr(nKeyCode)) && and nKeyCode=>0 && Remove the first && to see the bug
>  DoDefault(Asc(Upper(Chr(nKeyCode))), nShiftAltCtrl)
>  NoDefault
>EndIf

>
>Also what happens when you move NODEFAULT before DODEFAULT()?
>Like:
>

>LPARAMETERS nKeyCode, nShiftAltCtrl
>if IsAlpha(Chr(nKeyCode)) && and nKeyCode=>0 && Remove the first && to see the bug
>  NoDefault
>  DoDefault(Asc(Upper(Chr(nKeyCode))), nShiftAltCtrl)
>EndIf

>
>
>
>>I have created a textbox baseclass which I use whenever I want only uppercase text. The code in Keypress is/was as follows

>>LPARAMETERS nKeyCode, nShiftAltCtrl
>>if IsAlpha(Chr(nKeyCode)) && and nKeyCode=>0 && Remove the first && to see the bug
>>  DoDefault(Asc(Upper(Chr(nKeyCode))))
>>  NoDefault
>>EndIf

>>This code runs fine EXCEPT when any of the function keys are cleared, because default function keys set negative values for nKeyCode, and cause chr(nKeyCode) to generate an error. So I added a check for nKeyCode>0, which appeared to work fine for most keys, but not all. The following keys are simply "eaten" when I check for nKeyCode>0 by adding the "and nKeyCode=>0": D,E,F,G,T,U,V and W, plus a few international characters.
>>
>>I checked the ascii value for these characters:
>>D 68 0x00000044
>>E 69 0x00000045
>>F 70 0x00000046
>>G 71 0x00000047
>>T 84 0x00000054
>>U 85 0x00000055
>>V 86 0x00000054
>>W 87 0x00000056
>>My observation is that the groups of "eaten" characters are exactly 4 bit apart, but I have no idea of why.
>>
>>In desperation I isolated the two conditions, and then it worked as expected:

>>LPARAMETERS nKeyCode, nShiftAltCtrl
>>if IsAlpha(Chr(nKeyCode))
>>  If nKeyCode=>0
>>    DoDefault(Asc(Upper(Chr(nKeyCode))))
>>    NoDefault
>>  EndIf
>>EndIf

>>
>>Does anybody have a logical explanation for this strange behavior, which must be an obscure bug?