Possible bug in TGet w/ @k picture

James Bott · Post by **James Bott** » Sat May 27, 2006 6:35 pm

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

#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 · Post by **James Bott** » Sat May 27, 2006 6:40 pm

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 · Post by **Randal** » Mon May 29, 2006 4:18 pm

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 · Post by **James Bott** » Mon May 29, 2006 10:24 pm

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 · Post by **Vladimir Grigoriev** » Tue May 30, 2006 2:09 pm

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 · Post by **James Bott** » Tue May 30, 2006 4:11 pm

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 · Post by **James Bott** » Tue May 30, 2006 6:12 pm

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

Code: Select all

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