Enrico,
>Just check oGet:oGet:HasFocus. It is .T. in bLostFocus and .F. in bValid.
Thanks for clarifying that. That may be correct but it is unexpected.
Tim,
Perhaps you can use bLostFocus instead of bValid to solve your problem?
James
James Bott wrote:Thanks for clarifying that. That may be correct but it is unexpected.
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
I got around the problem but as James says, there may be a bug to review in this case.
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.)
GET oGetStart
GET oGetEnd VALID ( check() )
func check()
if dStart > dEnd
MsgInfo(" dStart > dEnd ")
retu (.F.)
endif
retu (.T.)For example: as default I use today and today + 7 days.
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.
Regards,
Otto
Check this link
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
Thank you James for you explanation. I will give your suggestion a try.
#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#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 nilOtto,
Silly me. You can also do this with a VALID clause.
redefine get oGetStart...valid checkDates(oGetStart,oGetEnd)
Then just return .t. from the checkDates function (instead of nil). It should work just the same as using bPostEdit.
James
#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.
//----------------------------------------------------------------------------//Thank you, James.
Please have a look at: www.fwcodesnips.com