ON CHANGE in tGet
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
It seems that this must be causing some undesirable effects. If bValid is not eval'd until AFTER the control looses focus, then bLostFocus has already been eval'd and then if bValid fails, then bGotFocus is going to be eval'd too, even though, theoretically you have never left the control.
bValid should be getting eval'd before the control looses focus and it should not loose focus until bValid returns .t. --at least this seems to be the correct behavoir to me.
James
bValid should be getting eval'd before the control looses focus and it should not loose focus until bValid returns .t. --at least this seems to be the correct behavoir to me.
James
OK
I got around the problem but as James says, there may be a bug to review in this case.
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
Hello James,
>Just check oGet:oGet:HasFocus. It is .T. in bLostFocus and .F. in bValid.
If I have two get-fields where I check if the end-date is later I think you need such a behavior.
If I jump to the start field then I need a return .t. and no checking.
Is there another way to bypass the checking?
Regards,
Otto
GET oGetStart
GET oGetEnd VALID ( check() )
func check()
if oGetAnkunft:oGet:HasFocus=.t.
retu (.T.)
endif
if dStart > dEnd
MsgInfo(" dStart > dEnd ")
retu (.F.)
endif
retu (.T.)
>Just check oGet:oGet:HasFocus. It is .T. in bLostFocus and .F. in bValid.
If I have two get-fields where I check if the end-date is later I think you need such a behavior.
If I jump to the start field then I need a return .t. and no checking.
Is there another way to bypass the checking?
Regards,
Otto
GET oGetStart
GET oGetEnd VALID ( check() )
func check()
if oGetAnkunft:oGet:HasFocus=.t.
retu (.T.)
endif
if dStart > dEnd
MsgInfo(" dStart > dEnd ")
retu (.F.)
endif
retu (.T.)
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Otto,
I'm not sure I understand what you are trying to do. Wouldn't this work? Why do you need to check for focus?
James
I'm not sure I understand what you are trying to do. Wouldn't this work? Why do you need to check for focus?
James
Code: Select all
GET oGetStart
GET oGetEnd VALID ( check() )
func check()
if dStart > dEnd
MsgInfo(" dStart > dEnd ")
retu (.F.)
endif
retu (.T.)
- Patricio Avalos Aguirre
- Posts: 1028
- Joined: Fri Oct 07, 2005 1:56 pm
- Location: La Serena, Chile
- Contact:
Saludos
Patricio
__________________________________________________________________
Version: Harbour 3.2.0dev (r1307082134),Compiler: Borland C++ 5.8.2 (32-bit)
PCode version: 0.3, FWH 13.2
http://www.sialm.cl
Patricio
__________________________________________________________________
Version: Harbour 3.2.0dev (r1307082134),Compiler: Borland C++ 5.8.2 (32-bit)
PCode version: 0.3, FWH 13.2
http://www.sialm.cl
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Otto,
>If I begin editing in the end get field and I choose a date before the start date there is not possibility to jump to the start date to change this value too.
There seems to be a circular logic problem here. When start > end then EITHER the start is wrong, the end is wrong, or they are both wrong. So doing a valid on the end date presents you with the problem of figuring out which date needs to be changed. Jumping to the start date MAY be the right solution or not--there is no way to know. Plus, as you pointed out, you can't leave the end field until it is valid and it can't be valid unless it is greater than the start. Thus the Catch-22.
I would color the background of both fields pink when start > end, and popup a tooltip explaining the problem. I would use bPostEdit to trigger this action on both GETs. This way the user can edit either field to get the backgrounds to turn white again (valid). I wouldn't use a VALID since you want the user to be able to exit one field to edit the other. And they can go back and forth between the fields until they are right. The color and the tooltip give them visual indications of the problem without presenting them with a msg that they have to click to get rid of.
Also you could do a validity check when the dialog is closed to make sure the two fields are valid before saving.
James
>If I begin editing in the end get field and I choose a date before the start date there is not possibility to jump to the start date to change this value too.
There seems to be a circular logic problem here. When start > end then EITHER the start is wrong, the end is wrong, or they are both wrong. So doing a valid on the end date presents you with the problem of figuring out which date needs to be changed. Jumping to the start date MAY be the right solution or not--there is no way to know. Plus, as you pointed out, you can't leave the end field until it is valid and it can't be valid unless it is greater than the start. Thus the Catch-22.
I would color the background of both fields pink when start > end, and popup a tooltip explaining the problem. I would use bPostEdit to trigger this action on both GETs. This way the user can edit either field to get the backgrounds to turn white again (valid). I wouldn't use a VALID since you want the user to be able to exit one field to edit the other. And they can go back and forth between the fields until they are right. The color and the tooltip give them visual indications of the problem without presenting them with a msg that they have to click to get rid of.
Also you could do a validity check when the dialog is closed to make sure the two fields are valid before saving.
James
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Otto,
Here is some sample code to get you started.
James
Here is some sample code to get you started.
James
Code: Select all
#include "wcolor.ch"
#define COLOR_CRITICAL Rgb(255,197,255) // backround color of critical data - Pink
oGetStart:bPostEdit := {|oGetStart,oGetEnd| checkDates(oGetStart,oGetEnd) }
oGetEnd:bPostEdit := {|oGetStart,oGetEnd| checkDates(oGetStart,oGetEnd) }
function checkDates(oGetStart,oGetEnd)
if oGetStart:varGet() > oGetEnd:varGet()
oGetStart:setColor( COLOR_TEXT, COLOR_CRITICAL )
oGetEnd:setColor( COLOR_TEXT, COLOR_CRITICAL )
else
oGetStart:setColor( COLOR_TEXT, COLOR_WINDOW )
oGetEnd:setColor( COLOR_TEXT, COLOR_WINDOW )
endif
oGetStart:refresh()
oGetEnd:refresh()
return nil
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Otto,
Here is an improved version--not tested.
James
Here is an improved version--not tested.
James
Code: Select all
#include "wcolor.ch"
#define COLOR_CRITICAL Rgb(255,197,255) // backround color of critical data - Pink
oGetStart:bPostEdit := {|oGetStart,oGetEnd| checkDates(oGetStart,oGetEnd) }
oGetEnd:bPostEdit := {|oGetStart,oGetEnd| checkDates(oGetStart,oGetEnd) }
function checkDates(oGetStart,oGetEnd)
if oGetStart:varGet() > oGetEnd:varGet() .and. ! empty( oGetEnd:varGet() )
oGetStart:setColor( COLOR_TEXT, COLOR_CRITICAL )
oGetEnd:setColor( COLOR_TEXT, COLOR_CRITICAL )
oGetStart:cTooltip:= "Start date cannot be later than end date."
oGetEnd:cTooltip:="Start date cannot be later than end date."
else
oGetStart:setColor( COLOR_TEXT, COLOR_WINDOW )
oGetEnd:setColor( COLOR_TEXT, COLOR_WINDOW )
oGetStart:cTooltip:=nil
oGetEnd:cTooltip:=nil
endif
oGetStart:refresh()
oGetEnd:refresh()
return nil
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Otto,
OK, here is a tested working example.
James
OK, here is a tested working example.
James
Code: Select all
#include "fivewin.ch"
#include "wcolors.ch"
#define COLOR_CRITICAL Rgb(255,197,255) // backround color of critical data - Pink
function main()
local oDlg, oGetStart, oGetEnd
local dStart:= ctod("09/09/09"), dEnd:=ctod(" / / ")
set epoch to 1980
define dialog oDlg title "Test Date field valids"
@ 2,2 Get oGetStart var dStart of oDlg valid checkDates( oGetStart, oGetEnd )
@ 3,2 Get oGetEnd var dEnd of oDlg valid checkDates( oGetStart, oGetEnd )
activate dialog oDlg centered
return nil
//---------------------------------------------------------------------------//
function checkDates(oGetStart,oGetEnd)
local nClrFore:=getSysColor( COLOR_WINDOWTEXT ), nClrPane:= getSysColor( COLOR_WINDOW )
if oGetStart:varGet() > oGetEnd:varGet() .and. ! empty( oGetEnd:varGet() )
oGetStart:setColor( nClrFore, COLOR_CRITICAL )
oGetEnd:setColor( nClrFore, COLOR_CRITICAL )
oGetStart:cTooltip:= "Start date cannot be later than end date."
oGetEnd:cTooltip:="Start date cannot be later than end date."
else
oGetStart:setColor( nClrFore, nClrPane )
oGetEnd:setColor( nClrFore, nClrPane )
oGetStart:cTooltip:=nil
oGetEnd:cTooltip:=nil
endif
oGetStart:refresh()
oGetEnd:refresh()
return .T.
//----------------------------------------------------------------------------//