Varytext control not updating

[cssyphus]

I'm probably making an obvious mistake, but this simple dynamic dialog should switch the text in a VARYTEXT control, but I don't see the text change.
What have I missed?

Code Select Expand


goSub UDFs
Init_Dialog_Constants()

var1 = `Initial value`

MyDialogFormat=`WWWDLGED,6.2`

MyDialogCaption=`WIL Dialog 1`
MyDialogX=132
MyDialogY=090
MyDialogWidth=258
MyDialogHeight=166
MyDialogNumControls=003
MyDialogProcedure=`udsCallback`
MyDialogFont=`DEFAULT`
MyDialogTextColor=`DEFAULT`
MyDialogBackground=`DEFAULT,DEFAULT`
MyDialogConfig=0

MyDialog001=`077,121,036,012,PUSHBUTTON,  "pbOK",       DEFAULT, "OK",        1,  10,@csDefButton,DEFAULT,DEFAULT,DEFAULT`
MyDialog002=`137,121,036,012,PUSHBUTTON,  "pbCancel",   DEFAULT, "Cancel",    0,  20,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
MyDialog003=`033,011,184,092,VARYTEXT,    "vtCtrl",     var1,    "%var1%",  DEFAULT,30,DEFAULT,DEFAULT,DEFAULT,DEFAULT`

ButtonPushed=Dialog("MyDialog")
EXIT

:UDFs
#DEFINESUBROUTINE udsCallback(_hDlg, _dMsg, _dName, _dEvtInfo, _dChgInfo) ;-----------------------------
switch _dMsg
case MSG_INIT
DialogProcOptions(_hDlg, MSG_BUTTONPUSHED, @TRUE)
return(RET_DO_DEFAULT)
case MSG_BUTTONPUSHED
if _dName == `pbOK`
var1 = `I pushed the button`
return(RET_DO_NOT_EXIT)
elseif _dName == `pbCancel`
return RET_DO_CANCEL
endif
endswitch

#ENDSUBROUTINE ;udsCallback ----------------------------------------------------------------------------
#DEFINESUBROUTINE Init_Dialog_Constants() ;-------------------------------------------------------------
; >SNIP!<
#ENDSUBROUTINE ;Init_Dialog_Constants ------------------------------------------------------------------
Return ;UDFs



[td]

If you check the help file documentation for the VARYTEXT control a reference to the @dcTitle(4) constant under the DialogControlSet subtopic. Use this function with this constant to change the text of the control.  For good reasons setting the controls variable in a CallBack does not work.


https://docs.winbatch.com/mergedProjects/WindowsInterfaceLanguage/html/VaryText_Control.htm

[kdmoyers]

Yeah, I had trouble with this myself when I was starting with dialog call backs.

Inside the callback, changing the dialog variable does nothing.  The dialog variable
only establishes the initial value when the Dialog statement starts going.

To truly make a dynamic changing dialog (which is the fun part) you have to
learn to using the DialogControlSet function.  It's actually pretty cool.

Code (winbatch) Select Expand

goSub UDFs

var1 = `Initial value`

MyDialogFormat=`WWWDLGED,6.2`

MyDialogCaption=`WIL Dialog 1`
MyDialogX=132
MyDialogY=090
MyDialogWidth=258
MyDialogHeight=166
MyDialogNumControls=003
MyDialogProcedure=`udsCallback`
MyDialogFont=`DEFAULT`
MyDialogTextColor=`DEFAULT`
MyDialogBackground=`DEFAULT,DEFAULT`
MyDialogConfig=0

MyDialog001=`077,121,036,012,PUSHBUTTON,  "pbOK",       DEFAULT, "OK",        1,  10,@csDefButton,DEFAULT,DEFAULT,DEFAULT`
MyDialog002=`137,121,036,012,PUSHBUTTON,  "pbCancel",   DEFAULT, "Cancel",    0,  20,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
MyDialog003=`033,011,184,092,VARYTEXT,    "vtCtrl",     var1,    "%var1%",  DEFAULT,30,DEFAULT,DEFAULT,DEFAULT,DEFAULT`

ButtonPushed=Dialog("MyDialog")
EXIT

:UDFs
#DEFINESUBROUTINE udsCallback(_hDlg, _dMsg, _dName, _dEvtInfo, _dChgInfo) ;-----------------------------
switch _dMsg
case @deInit
DialogProcOptions(_hDlg, @dePbPush, @TRUE)
return(@retDefault)
case @dePbPush
if _dName == `pbOK`
dialogcontrolset(_hDlg,"vtCtrl",@dcTitle,"I pushed the button")
return(@retNoExit)
elseif _dName == `pbCancel`
return @retCancel 
endif
endswitch

#ENDSUBROUTINE ;udsCallback ----------------------------------------------------------------------------
Return ;UDFs

[cssyphus]

Thanks Kirby. Two questions:

1.  Can you do this:  dialogcontrolset(_hDlg,"vtCtrl",@dcTitle, var1 )

2. Can you force the dialog to refresh?  Would that force the variable to be re-read?

Otherwise, what is point of the variable associated with that control?  I suspect I am missing something key here.

Aha... I also see that the value field (where I put the `%var1%`) is not used by the VARYTEXT control...  So how is that variable value used then?

Many thx!

[JTaylor]

The DialogControlSet() will set the value and everything should appear as you expect.  You do not need to "refresh" it in any explicit way as that is part of the dialog's callback duties.

Generally best to avoid using substitution unless necessary.  It often results in problems and sometimes very hard to find problems.

Jim

[cssyphus]

I think I understand.

The STATICTEXT control and the VARYTEXT control are equivalent within the Dialog - that is, one can do exactly what you both describe above using either a STATICTEXT or a VARYTEXT.  For example, I swapped the VARYTEXT into a STATICTEXT and was able to do the same thing.

Code Select Expand


MyDialog003=`033,011,184,092,STATICTEXT,  "vtCtrl",     DEFAULT, "Initial", DEFAULT,    30,  DEFAULT,       DEFAULT,DEFAULT,DEFAULT`


The difference is that when the dialog is next called, after being closed, the new variable value will be read and will appear on screen when the dialog is opened again. But as long as the dialog remains on screen, the method described by Kirby must be used.

Please correct me if I misunderstood anything... ?

[td]

It is very simple. The variable associated with a VARYTEXT dialog control can be used to set the initial value. That is it. You use a dialog callback to perform changes to the text once the dialog has been created and until it is destroyed.

The VARYTEXT and STATICTEXT controls' only difference besides their respective names is the VARYTEXT control has a variable to place text displayed in the control. The STATICTEXT control does not have a variable. The two controls have existed since the pre-user-defined-callback days of WIL Dialogs. They still exist today to preserve backward compatibility. 

[kdmoyers]

Sounds like you have it cssyphus. 

One extra bit on callbacks: I like your idea of using this little experiment program to test new methods.  Make a tiny change, then test again.  If anything unexpected happens, stop right there and find out why.  Don't use the complex callback logic in your real program until all the tricky bits are well understood.

Because boy howdy you can get into a real pickle when you mix complex callback logic flow with your already complex application program flow.  You don't know why it won't work, or even what's happening!   

Small moves, small moves...
https://youtube.com/clip/UgkxTKsFlO_xXDZSD1xXUC7le3cWtJJM0IJZ

[JTaylor]

Another tip, if you don't already know this, if you call a process from the dialog that will take a significant amount of time, disable the dialog (DialogProcOptions) prior to the call and re-enable upon return.

Jim