Page 1 of 1
TGet and bChange
Posted: Fri Mar 16, 2007 4:32 pm
by James Bott
I found that in the FWH 2.7 Aug 2006 build, the location of the eval of bChange in the TGet:keyChar() method was changed from a previous version (Feb 2006). It was moved below the code that rejects new keystrokes. Now if your bChange function returns .f. the keystroke still gets accepted--before it got rejected. You can test this with the code below. It should reject all keystrokes.
Has the location of the eval of bChange been returned to it's original location in newer versions of FWH? If not, why was it moved, and can we resolve both issues somehow? I really need to be able to reject keystrokes like when doing incremental searches.
James
Code: Select all
#include "fivewin.ch"
function main()
local oDlg, oGet, cVar:=space(10)
define dialog oDlg title "Test bChange"
@5,5 get oGet var cVar of oDlg update;
on change test(nKey,nFlags,oGet) pixel
activate dialog oDlg center
return nil
function test(nKey,nFlags,oGet)
return .f.
.
Re: TGet and bChange
Posted: Fri Mar 16, 2007 5:09 pm
by Enrico Maria Giordano
I confirm the problem, although I never used that feature so far.
EMG
Posted: Sat Mar 17, 2007 10:36 am
by Antonio Linares
James,
Do you mean this code (changed as you suggest):
Code: Select all
case nKey >= 32 .and. nKey < 256
#ifdef __HARBOUR__
// <lk> deadkey+tab [or enter] previously pressed will cause a r/t error
if ::oGet:buffer == nil
return 0
endif
#endif
::GetSelPos( @nLo, @nHi )
// Delete selection
if nHi != nLo
::GetDelSel( nLo, nHi )
::EditUpdate()
endif
if ::bChange != nil
lAccept = Eval( ::bChange, nKey, nFlags, Self )
if ValType( lAccept ) == "L" .and. ! lAccept
return 0
endif
endif
if ::oGet:Type == "N" .and. ;
( Chr( nKey ) == "." .or. Chr( nKey ) == "," )
if ::oGet:Clear()
::oGet:DelEnd()
endif
::oGet:ToDecPos()
else
if Set( _SET_INSERT ) // many thanks to HMP
::oGet:Insert( Chr( nKey ) )
else
::oGet:Overstrike( Chr( nKey ) )
end
endif
if ::oGet:Rejected
if Set( _SET_BELL )
MsgBeep()
endif
endif
::EditUpdate()
if ::oGet:TypeOut
if ! Set( _SET_CONFIRM )
::oWnd:nLastKey = VK_RETURN
::oWnd:GoNextCtrl( ::hWnd )
else
if Set( _SET_BELL )
MsgBeep()
endif
endif
endif
Eval( ::bPostKey, Self, ::oGet:Buffer )
Will that be ok ?
Posted: Sat Mar 17, 2007 2:02 pm
by James Bott
Antonio,
> Will that be OK?
I'm not sure, I will have to do some testing. I think it will solve my problem, but I am also concerned as to the reason it was moved. Do you remember why? I don't want this change to undo whatever you were attempting to do by moving it in the first place.
In the Feb 2006 code, bChange was in a different place (see below). It was after numeric keys were processed. Is the new location going to create a problem with that--or maybe it solves a problem?
To be consistant, the msgBeep() should probably also be added before the RETURN 0 as it is when ::oGet:Rejected is true.
James
Code: Select all
case nKey >= 32 .and. nKey < 256
#ifdef __HARBOUR__
// <lk> deadkey+tab [or enter] previously pressed will cause a r/t error
if ::oGet:buffer == nil
return 0
endif
#endif
::GetSelPos( @nLo, @nHi )
// Delete selection
if nHi != nLo
::GetDelSel( nLo, nHi )
::EditUpdate()
endif
if ::bChange != nil
lAccept = Eval( ::bChange, nKey, nFlags, Self )
if ValType( lAccept ) == "L" .and. ! lAccept
return 0
endif
endif
if ::oGet:Type == "N" .and. ;
( Chr( nKey ) == "." .or. Chr( nKey ) == "," )
if ::oGet:Clear()
::oGet:DelEnd()
endif
::oGet:ToDecPos()
else
//--- bChange was here in Feb 2006 version
if Set( _SET_INSERT ) // many thanks to HMP
::oGet:Insert( Chr( nKey ) )
else
::oGet:Overstrike( Chr( nKey ) )
end
endif
if ::oGet:Rejected
if Set( _SET_BELL )
MsgBeep()
endif
endif
::EditUpdate()
if ::oGet:TypeOut
if ! Set( _SET_CONFIRM )
::oWnd:nLastKey = VK_RETURN
::oWnd:GoNextCtrl( ::hWnd )
else
if Set( _SET_BELL )
MsgBeep()
endif
endif
endif
Eval( ::bPostKey, Self, ::oGet:Buffer )
Posted: Mon Mar 19, 2007 5:26 pm
by Maurilio Viana
In older FW versions bChange was evaluated in wrong place. Then if you ask to show the variable buffer the last key pressed wasn't considered.
I think Antonio fixed it months ago...
If I'm not wrong it was corrected 2006/march.
Regards,
Maurilio
Posted: Mon Mar 19, 2007 6:14 pm
by James Bott
Maurilio,
Thanks for your response.
>In older FW versions bChange was evaluated in wrong place. Then if you ask to show the variable buffer the last key pressed wasn't considered. I think Antonio fixed it months ago...
Well, that explains it, but there is a problem. Before the "fix," you could reject any keystroke by returning .f. from the bChange codeblock. This was really useful as you could have complete control over what was entered. The downside is that if you need everything that has been input you have to use oGet:varGet() + chr( nKey ). Note that nKey is automatically passed by the eval so this can be done.
Code: Select all
Eval( ::bChange, nKey, nFlags, Self )
The "fix" you mentioned makes it much more difficult to reject keystrokes. You might think that you could just chop off the last character, but it is not so simple. First, the user will have already seen the character in the GET (not so with the previous method). Second, the user could be inserting or overstriking a character in the middle of the existing data in the GET. So, you have to write a rather complex processing routine and you still can't overcome the issue of the last character already having been displayed to the user.
I notice in TGet:keyChar() there is also another codeblock that could be used the way you want. Near the end of the method you will see this:
Code: Select all
Eval( ::bPostKey, Self, ::oGet:Buffer )
At the time of this eval, ::bPostKey will contain the entire buffer including the last key typed (unless the last key was rejected either by other code or by bChange).
So, the last "fix" broke existing code. Any change now will likely break other code so there is no perfect solution, but I think you can easily change your code to use bPostkey instead of bChange. If that works, then we can move bChange back to its original location and we will have access to both features. Having both features would also allow you to easily both reject keystrokes before they reached the buffer AND to evaluate the buffer with each new keystroke by using both bChange and bPostKey.
Will you test changing your existing code to use bPostKey instead of bChange to see if that works for you? Then let us know what you find and we can either look for a different solution or we can make a recommendation to Antonio.
Anyone else have any comments or suggestions?
Regards,
James
Posted: Mon Mar 19, 2007 7:21 pm
by Maurilio Viana
James, I understood the problem.
I'll try bPostKey instead bChange in all code I have and I'll post here my results.
Regards,
Maurilio
Posted: Wed Mar 21, 2007 6:46 pm
by Maurilio Viana
I changed all code were I used bChange to bPostKey and worked fine.
In all cases were I used bChange worked fine replacing to bPostKey.
Best regards
Maurilio
Posted: Thu Mar 22, 2007 5:20 am
by James Bott
Maurilio,
Thanks for testing that and reporting your results.
So, Antonio, I recommend putting bChange back were it was initially (see my message above for the specific location). Also, I recommend putting in the msgbeep() if SET BELL is on. If you like I can write something up explaining all this that you can put into the What's New.
James