Possible bug in TGet w/ @k picture

[James Bott]

Antonio,

There may be a bug in either the TGet class or the GET class object within the TGet class (TGet:oGet). If you are using the @k picture (which erases the rest of a field when a new character is entered in the first position) and if you call oDlg:update() just prior to entering the field, the picture fails to work. In the sample code below, the first field calls oDlg:update() from it's VALID clause. Then next field's picture clause does not work as expected. If you then move to the third field (which doesn't call oDlg:update()), then back to the second field, the picture clause works as expected.

I cannot figure out why this is happening. It doesn't seem logical that calling oDlg:update() (which calls the control's refresh() method) would cause a problem with the picture clause. I can't find any reference to this particular picture clause in TGet so I am guessing the problem lies within the GET class in Harbour, but I am not sure.

I have also confirmed that if you just call oGet2:refresh() instead of oDlg:update() the same problem occurs.

I am using the FWH May 2006 release with Harbour. The problem also existed with the May 2005 version so it is not a new problem.

James

Code: Select all  Expand view

#include "fivewin.ch"

function main()
   local oDlg, oGet2, cVar1:="AAAAAA", cVar2:="BBBBBB", cVar3:="CCCCCC"
   define dialog oDlg title "Test Get"
   @ 1,1 get cVar1 picture "@!@k" of oDlg update valid (oDlg:update(), .t.)
   @ 2,1 get oGet2 var cVar2 picture "@!@k" of oDlg update
   oGet2:bGotFocus:={|| oGet2:setPos(1) }
   @ 3,1 get cVar3 picture "@!@k" of oDlg update
   activate dialog oDlg centered
return nil

[James Bott]

I just checked and the problem does NOT occur with FW2.1 and Clipper so it looks like it may be a Harbour problem.

James

[Randal]

James,

I confirm the problem is the same using xHarbour. I don't know if they share the same underlying get class.

Tget class in FWH has changed considerably since FW 2.1.

Regards,
Randal Ferguson

[James Bott]

Randal,

Thanks for checking it with xHarbour.

I realize the FW TGet class has changed a lot since FW2.1, but I had that version installed and I wanted to see what the Clipper GET class's behavior was. If the picture clauses are handled by the GET class in Clipper then one can assume that they are also handled by the GET class in Harbour/xHarbour. Since Clipper's GET class was handling it correctly, I think we can assume that there is a bug in the Harbour/xHarbour GET class.

James

[Vladimir Grigoriev]

By the way I think (though I might be wrong) the expression "@!@k" is not valid for PICTURE clause though it may have no any serious consequence. IMO it is better to use @!K before either right quatation mark or a space.

[James Bott]

Vladimir,

Thanks, you are right, "@!K" is correct. The code I am testing is someone else's and I didn't think to check the syntax. I does work either way under Clipper however. And it doesn't work either way under FWH/Harbour. I also tried "@K!" without success.

James

[James Bott]

This seems to be a possible fix. Change one line in the TGet:GoHome() method.

Code: Select all  Expand view

METHOD GoHome() CLASS TGet

   ::oGet:Home()
   // if ::oGet:Type == "N"  // original
   if ::oGet:Type == "N" .or. "K" $ UPPER(::oGet:cPicture) // modified
      ::oGet:Clear := .t. // flag to clear buffer if typing is detected
   endif
   ::SetPos( ::oGet:Pos )

return Self

James