OK, gang ... I have a form, containing a pageframe, containing several
pages. On one of those pages is a combobox (dropdown list style). In
the interactivechange method of the combobox is a call to a method of
the parent form (a new method I've written). The form method does a
bunch of calculations and then updates two other controls on the same
page as the combobox.

When I run this form normally, it does not work properly. When I try to
select an item in the combobox, it somehow defaults back to the last
item in the picklist. (The rowsourcetype is 6, Fields from a table in
the form's data environment.) The other two controls that should be
updated do not change.

What's really mystifying is that if I step thru this process with the
debugger, everything works as it should. The combobox behaves properly,
the form method is executed, and the other two controls are updated.

Anyone have any thoughts as to what's going on here?

Thanks as usual --
Doug Schwarz

Doug Schwarz <odougs (AT) alum (DOT) colby.edu> wrote:

[snip]

Just a guess, but are your controls getting properly refreshed?
Having the debugger in circuit can result in more refreshes occurring,
and this can make broken code work. (Hey, it really is a debugger.
<G>)

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

I read about this effect on FoxWiki, so tried introducing extra
refreshes at various points in my code. No joy.

-- Doug

Gene Wirchenko wrote:

any activeX involved ?
the debugger also seems to give more power
to the working off of events, like many sprinkled in "doevents"

HTH

thomas

Another guess - you cannot Refresh() a control as long as its
own InteractiveChange() is still in the calling stack.
IOW, when your combo.InteractiveChange() calls a custom
method and that method does a "Thisform.Refresh()" (or any
container-refresh including the orginal combo), you'd get that
"undo" effect.
(Hm, bad English probably?... please post back if this was not
well explained)


hth
-Stefan

"Doug Schwarz" <odougs (AT) alum (DOT) colby.edu> schrieb im Newsbeitrag
news:40B3AE12.6000905 (AT) alum (DOT) colby.edu...

Hi Stefan,

curious

thomas

I think I've found my problem, and figured I'd pass my discovery along
in case anyone is interested.

The calculations in my form method were based on the value of the
combobox's CONTROLSOURCE, rather than directly on the combobox's value.
Apparently when the combobox's InteractiveChange is fired, the value
of the controlsource has not yet changed. However, when stepping thru
with the debugger, the controlsource value DOES change -- hence my
method works.

Thanks to all for your suggestions.

-- Doug

Stefan Wuebbe wrote:

Hi Thomas -

"Thomas Ganss" <TGanss_RemoveForRealAdress (AT) T-Online (DOT) de> schrieb im Newsbeitrag
news:c91ssb$g15$05$1 (AT) news (DOT) t-online.com...
Hm, not sure .. maybe a "Schroedinger's Cat" effect?
The test.prg below seems to repro it for me -
with Set Asserts Off the value does not change because of the Refresh,
with Set Asserts On it does for me, apparently because of the debugger
jumping in...


-Stefan

* test.prg
LOCAL oForm
oForm = CREATEOBJECT('TestForm')
oForm.Show(1)
RETURN

DEFINE CLASS TestForm as Form
AutoCenter = .T.
bGreen = .F.

PROCEDURE Load
CREATE CURSOR temp (test C(10))
INSERT INTO temp VALUES ('Two')
ENDPROC
PROCEDURE Refresh
WITH This
.BackColor = IIF(.bGreen,RGB(0,255,0),RGB(255,255,0))
.bGreen = !.bGreen
ENDWITH
ENDPROC

ADD OBJECT ComboX as Combobox WITH ;
Left = 50, Top = 50, ;
RowSourceType = 1, ;
RowSource = 'One,Two,Three', ;
ControlSource = 'temp.test'
PROCEDURE ComboX.InteractiveChange
assert.f.
Thisform.Refresh()
ENDPROC

ENDDEFINE
*