Progress Bar Control

Thank you for your suggestion.  I tried the _app suggestion but it didn’t help. 
I think I am making a more fundamental/elementary mistake.  My on-click function
associated with the “START” button initiates a DO “One of the reports”.  If,
just prior to the DO “One of the reports” statement, I
insert:		form.PROGRESS1.visible = true
		nvalue = “a number between 0 & 100”
		form.PROGRESS1.value = nvalue
the progress bar appears with the right # of green dots.  If I suspend the
program at that point, I can change the nvalue and set “form.PROGRESS1.value” to
the new nvalue from the command window and the progress bar immediately reflects
the change.  But, once the DO “One of the reports” statements is initiated, a
“form.PROGRESS1.value = nvalue” doesn’t  talk to the progress bar nor can I
control the bar from the command window as I did above (I can change nvalue).  I
suspend the report file shortly after it is called – before it gets into a major
DO loop -  so there is no number crunching going on,   Note that each of the
reports is a separate  .PRG file.  Is the format –“form.PROGRESS1.value =
nvalue”  incorrect when it comes from a *.PRG file instead of the *.wfm file?

In article <AeGh8MjjIHA.960@news-server>, gei@futureone.com says...
> Thank you for your suggestion.  I tried the _app suggestion but it didn?t
help.  I think I am making a more fundamental/elementary mistake.  My on-click
function associated with the ?START? button initiates a DO ?One of the 
reports?.  If, just prior to the DO ?One of the reports? statement, I
insert:		form.PROGRESS1.visible = true
> 		nvalue = ?a number between 0 & 100?
> 		form.PROGRESS1.value = nvalue
> the progress bar appears with the right # of green dots.  If I suspend the
program at that point, I can change the nvalue and set ?form.PROGRESS1.value? to
the new nvalue from the command window and the progress bar immediately 
reflects the change.  But, once the DO ?One of the reports? statements is
initiated, a ?form.PROGRESS1.value = nvalue? doesn?t  talk to the progress bar
nor can I control the bar from the command window as I did above (I can change 
nvalue).  I suspend the report file shortly after it is called ? before it gets
into a major DO loop -  so there is no number crunching going on,   Note that
each of the reports is a separate  .PRG file.  Is the format ?
?form.PROGRESS1.value = nvalue?  incorrect when it comes from a *.PRG file
instead of the *.wfm file?
> 
> 


George,

Sometimes _app.executeMessages(), together with the _app.allowYieldOnMsg 
mentioned by Jean-Pierre, can help in those situations. If it doesn't, 
show us the basic logic you are using. Maybe there is something else we 
can see.

-- 
Geoff Wass [dBVIPS]
Montréal, Québec, Canada

.|.|.|        dBASE info at http://geocities.com/geoff_wass       |.|.|.
.|.|.| ---------------------------------------------------------- |.|.|.

George Iddings wrote:
> Thank you for your suggestion.  I tried the _app suggestion but it didn’t
help.  I think I am making a more fundamental/elementary mistake.  My on-click
function associated with the “START” button initiates a DO “One of the reports”.
 If, just prior to the DO “One of the reports” statement, I
insert:		form.PROGRESS1.visible = true
> 		nvalue = “a number between 0 & 100”
> 		form.PROGRESS1.value = nvalue
> the progress bar appears with the right # of green dots.  If I suspend the
program at that point, I can change the nvalue and set “form.PROGRESS1.value” to
the new nvalue from the command window and the progress bar immediately reflects
the change.  But, once the DO “One of the reports” statements is initiated, a
“form.PROGRESS1.value = nvalue” doesn’t  talk to the progress bar nor can I
control the bar from the command window as I did above (I can change nvalue).  I
suspend the report file shortly after it is called – before it gets into a major
DO loop -  so there is no number crunching going on,   Note that each of the
reports is a separate  .PRG file.  Is the format –“form.PROGRESS1.value =
nvalue”  incorrect when it comes from a *.PRG file instead of the *.wfm file?

In the loop, after you increment the value of the progress bar:

_app.executeMessages()

Ken

-- 
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm

In article <AeGh8MjjIHA.960@news-server>, gei@futureone.com says...
> Thank you for your suggestion.  I tried the _app suggestion but
> it didn=3Ft help.  I think I am making a more fundamental/elementary
> mistake.  My on-click function associated with the =3FSTART=3F button
> initiates a DO =3FOne of the reports=3F.  If, just prior to the
> DO =3FOne of the reports=3F statement, I insert:
> 		form.PROGRESS1.visible = true
> 		nvalue = =3Fa number between 0 & 100=3F
> 		form.PROGRESS1.value = nvalue
> the progress bar appears with the right # of green dots.  If I
> suspend the program at that point, I can change the nvalue and
> set =3Fform.PROGRESS1.value=3F to the new nvalue from the command
> window and the progress bar immediately reflects the change.
>  But, once the DO =3FOne of the reports=3F statements is initiated,
> a =3Fform.PROGRESS1.value = nvalue=3F doesn=3Ft  talk to the progress
> bar nor can I control the bar from the command window as I did
> above (I can change nvalue).  I suspend the report file shortly
> after it is called =3F before it gets into a major DO loop -  so
> there is no number crunching going on,   Note that each of the
> reports is a separate  .PRG file.
>  Is the format =3F=3Fform.PROGRESS1.value = nvalue=3F  incorrect when it
> comes from a *.PRG file instead of the *.wfm file?
> 

The .prg program may not know what form is.  You probably need to pass a 
reference to the program - something like this:

do report1 with form

Then, at the beginning of the program report1, include a parameters 
statement like this:

parameters mform

mform will now contain a pointer to the form.  You should then be able 
to insert random:

mform.progress1.value := nvalue

statements as needed in the program. 

-- 
Marilyn Price

George Iddings wrote:
> Marilyn Price Wrote:
> 
>> In article <AeGh8MjjIHA.960@news-server>, gei@futureone.com
says...
>>> Thank you for your suggestion.  I tried the _app suggestion but
>>> it didn=3Ft help.  I think I am making a more
fundamental/elementary
>>> mistake.  My on-click function associated with the =3FSTART=3F
button
>>> initiates a DO =3FOne of the reports=3F.  If, just prior to the
>>> DO =3FOne of the reports=3F statement, I insert:
>>> 		form.PROGRESS1.visible = true
>>> 		nvalue = =3Fa number between 0 & 100=3F
>>> 		form.PROGRESS1.value = nvalue
>>> the progress bar appears with the right # of green dots.  If I
>>> suspend the program at that point, I can change the nvalue and
>>> set =3Fform.PROGRESS1.value=3F to the new nvalue from the command
>>> window and the progress bar immediately reflects the change.
>>>  But, once the DO =3FOne of the reports=3F statements is
initiated,
>>> a =3Fform.PROGRESS1.value = nvalue=3F doesn=3Ft  talk to the
progress
>>> bar nor can I control the bar from the command window as I did
>>> above (I can change nvalue).  I suspend the report file shortly
>>> after it is called =3F before it gets into a major DO loop -  so
>>> there is no number crunching going on,   Note that each of the
>>> reports is a separate  .PRG file.
>>>  Is the format =3F=3Fform.PROGRESS1.value = nvalue=3F  incorrect
when it
>>> comes from a *.PRG file instead of the *.wfm file?
>>>
>> The .prg program may not know what form is.  You probably need to pass
a 
>> reference to the program - something like this:
>>
>> do report1 with form
>>
>> Then, at the beginning of the program report1, include a parameters 
>> statement like this:
>>
>> parameters mform
>>
>> mform will now contain a pointer to the form.  You should then be able

>> to insert random:
>>
>> mform.progress1.value := nvalue
>>
>> statements as needed in the program. 
>>
>> -- 
>> Marilyn Price
>> M. P. Data
> 
> Marilyn,
> You were right on!  It not only works -- I think I understand it now! To
Jean-Pierre, Geof and Ken, thanks for your inputs.  They didn't solve this
particular problem but they point out that I need to become much more familiar
with the _app functions.  Many thanks to all of you.  

If it helps, there are a couple books on dBASE out there, see my footer 
below ...

Ken

-- 
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm