A bug in a disable get

[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  Expand view  RUN

#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

[demont frank]

Maybe tyhe 'msginfo' is disturbing the fosus set by the dialog.

Have you tried with tracelog ?

Frank

[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.

[Antonio Linares]

Yuri,

This code is properly working here:

Code: Select all  Expand view  RUN

#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


[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. )

[Antonio Linares]

Yes, right, because the focus sequence can not be interrupted.

[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 ?

[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  Expand view  RUN

#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.


[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/ms645495(VS.85).aspx

but if such sequence is altered, then its the programmer responsability to decide where the focus should go.

[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/ms645495(VS.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

[hua]

I find it cleaner and neater to code it this way:

Code: Select all  Expand view  RUN

@ 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

[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.