Page 1 of 1
A bug in a disable get
Posted: Fri Aug 01, 2008 8:07 pm
by yury
Hi everyone
This code below have a 3 gets, all enabled in first moment
The first get have a valid calling a function and this one show a
message, set the variable lWhen2 with .F. (disabling the second
get) and returns .T.
But the cursor dont focus in the third get, it´s back to the first
please, try the code below and check if the problems realy exist
Code: Select all
#include "FiveWin.ch"
FUNCTION Test()
nCpo = 0
nCp2 = 15
cCp3 = SPACE(20)
lWhen1 = .T.
lWhen2 = .T.
lWhen3 = .T.
define dialog oDlg from 01,01 TO 25,50
@ 01,01 say 'I have a valid:' of oDlg
@ 01,10 get oCpo var nCpo pict '9999' of oDlg when lWhen1 valid xFunc()
@ 02,01 say 'I am enable for while:' of oDlg
@ 02,10 get oCp2 var nCp2 pict '99' of oDlg when lWhen2
@ 03,01 say 'I am enable forever:' of oDlg
@ 03,10 get oCp3 var cCp3 pict '@!' of oDlg when lWhen3
activate dialog oDlg center
RETURN
FUNCTION xFunc()
MSGINFO('Testing...')
lWhen2=.F.
oDlg:Aevalwhen()
SysRefresh()
RETURN .t.
regards and many thanks
Posted: Sat Aug 02, 2008 6:05 am
by demont frank
Maybe tyhe 'msginfo' is disturbing the fosus set by the dialog.
Have you tried with tracelog ?
Frank
Posted: Sat Aug 02, 2008 7:48 am
by nageswaragunupudi
The above program works correctly as expected without MsgInfo(). Even with MsgInfo(), it works second time onwards.
But why should it not work when there is MsgInfo() ? I think this is the main quetion raised by Yuri. It is not unusual to have some messages to the user in the valid clauses.
Posted: Sat Aug 02, 2008 7:49 am
by Antonio Linares
Yuri,
This code is properly working here:
Code: Select all
#include "FiveWin.ch"
function Main()
local nCpo := 0, nCp2 := 15, cCp3 := SPACE(20)
local lWhen1 := .T., lWhen2 := .T., lWhen3 := .T.
define dialog oDlg from 01,01 TO 25,50
@ 01,01 say 'I have a valid:' of oDlg
@ 01,10 get oCpo var nCpo pict '9999' of oDlg when lWhen1 valid ( lWhen2 := .F., .T. )
@ 02,01 say 'I am enable for while:' of oDlg
@ 02,10 get oCp2 var nCp2 pict '99' of oDlg when lWhen2
@ 03,01 say 'I am enable forever:' of oDlg
@ 03,10 get oCp3 var cCp3 pict '@!' of oDlg when lWhen3
activate dialog oDlg center
RETURN nil
Posted: Sat Aug 02, 2008 7:54 am
by nageswaragunupudi
Mr Antonio
The problem is when the valid is changed to include a msginfo. The problem is when the above code is written as :
.... valid ( msginfo( 'something' ), lWhen2 := .f., .t. )
Posted: Sat Aug 02, 2008 10:06 am
by Antonio Linares
Yes, right, because the focus sequence can not be interrupted.
Posted: Mon Aug 04, 2008 11:53 am
by yury
Mr. Antonio and Mr.NageswaraRao, thanks for your suport !
The problem happens with any dialog open in a valid function, in exemple above I used a msginfo for a test, but if were a dialog (define dialog...) happen the same error...
If no exists dialog or message in the valid function it's works fine, disabling the second get and focus in the third...
it would be possible to correct the get/control class for avoid this error ?
Posted: Mon Aug 04, 2008 1:15 pm
by yury
Hi everyone,
With a setfocus in the valid function directing the cursor for the third get it's works, but I think that it's not correct, because should be a natural behavior of FWH when the next control is a get and it's enable...
for now I solved this way, but I think that should be receive the proper treatment in the FWH classes...
regards
Code: Select all
#include "FiveWin.ch"
FUNCTION Test()
nCpo = 0
nCp2 = 15
cCp3 = SPACE(20)
lWhen1 = .T.
lWhen2 = .T.
lWhen3 = .T.
define dialog oDlg from 01,01 TO 25,50
@ 01,01 say 'I have a valid:' of oDlg
@ 01,10 get oCpo var nCpo pict '9999' of oDlg when lWhen1 valid xFunc()
@ 02,01 say 'I am enable for while:' of oDlg
@ 02,10 get oCp2 var nCp2 pict '99' of oDlg when lWhen2
@ 03,01 say 'I am enable forever:' of oDlg
@ 03,10 get oCp3 var cCp3 pict '@!' of oDlg when lWhen3
activate dialog oDlg center
RETURN
FUNCTION xFunc()
MSGINFO('Testing...')
lWhen2=.F.
oDlg:Aevalwhen()
SysRefresh()
oCp3:SetFocus() ==> HERE
RETURN .t.
Posted: Mon Aug 04, 2008 1:27 pm
by Antonio Linares
Yuri,
Your solution is fine, because there is no way to know where the focus should go once you open a dialogbox on top of the controls.
Windows API uses GetNextDlgTabItem() on a standard change focus sequence:
http://msdn.microsoft.com/en-us/library ... S.85).aspx
but if such sequence is altered, then its the programmer responsability to decide where the focus should go.
Posted: Mon Aug 04, 2008 2:39 pm
by yury
Yuri,
Your solution is fine, because there is no way to know where the focus should go once you open a dialogbox on top of the controls.
Windows API uses GetNextDlgTabItem() on a standard change focus sequence:
http://msdn.microsoft.com/en-us/library ... S.85).aspx
but if such sequence is altered, then its the programmer responsability to decide where the focus should go.
thanks Mr.Antonio, you are right, I understand your explanation...
regards
Posted: Thu Aug 07, 2008 9:05 am
by hua
I find it cleaner and neater to code it this way:
Code: Select all
@ 01,10 get oCpo var nCpo pict '9999' of oDlg when lWhen1 valid xFunc(oDlg, oCpo)
.
.
FUNCTION xFunc(oDlg, oGet)
MSGINFO('Testing...')
lWhen2=.F.
oDlg:Aevalwhen()
SysRefresh()
oDlg:GoNextCtrl(oGet:hWnd)
RETURN .t.
That way, if in the future I add new Gets, the jumping of the focus will follow the tab order that I specified within Resource Workshop. I won't have to remember to recode the setFocus part. Of course all of my screens were developed using Resource Workshop, not using the @..,.. syntax.
Just my 2 cents
Posted: Thu Aug 07, 2008 9:48 am
by Antonio Linares
Hua,
Thanks for your suggestion, anyhow keep in mind that there is no way to know in advance where the programmer wants to send the focus to, if he shows a dialogbox where the user may select or fill something.