optiongroup not refreshing after interactivechange 2

[chilltoad]

I have an optiongroup with two options, "Yes" and "No", to be used in response to some question, and I want to hide or show other controls depending on the selection. I use the interactive method of the optiongroup to carry out the appropriate action,

eg if this.value=1 then somecontrol.visible=.T. else somecontrol.visible=.f.

After clicking on one option or the other the interactivechange method is actioned, but the bullet remains on the wrong option. The optiongroup control then seems to lock up, and can't be changed thereafter. Oddly, if I suspend at the start of the interactive change method and then step through the code in the trace window (or even then just 'resume'), it all works perfectly. If I remove or comment out the interactivechange code, then the bullet switches back and forth as expected. If I put it back, it goes wrong again.

Refreshing the form (or page if its in a pageframe), or simply refreshing the control makes no difference.

This does not happen with every optiongroup in the application, just some. I'm going mad trying to figure it out - can anyone point me in the right direction?

 

[Nigel Gomm]

try moving the code from the interactivechange event to the valid event.

hth

nigel

 

[GriffMG]

Is there any chance that the 'somecontol' you are setting in your code is actually the same one that you are changing interactively?



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

Chilltoad,

Your code looks fine - nothing unusual about it. In fact, this is a fairly typical thing to do.

Is there any other code that also gets executed when you click on the option group? For example, in the Click event, or in the InteractiveChange of the object's parent class?

Or is any code executing in any of "somecontrols"'s method that might be causing it?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[chilltoad]

Many thanks.
I might have fixed it but I don't understand what the problem actually is (I hate that).

The control is on page3 of pageframe1 on a single form. The interactivechange method finishes with "thisform.pageframe1.page3.refresh". Removing this line seems to cure the strange behaviour, but as I say, I don't know why, particularly as while investigating the problem I'm sure I tried it outside a pageframe. Equally, I don't understand why interrupting the profgram flow would make it work.

I shall continue to try various context permutations.

@nigel - not tried yet but I'll give it a go.
@griff - while I am perfectly capable of being recursively stupid to the nth degree, not in this case!
@mike - I tried stripping out as much code as possible both from this control and others,as well as taking out all other objects and leaving just enough to demonstrate whether or not it was working. No success until I hit the refresh code mentioned above.
I'm not finished yet, but feeling comforted!

 

[Nigel Gomm]

you can't trust the value of the control (or of the bound data) within the interactivechange event. That seems to occur BEFORE the value is changed.

Not sure this is supposed to be the case but i've learnt to put all code that tests the value of the control into the valid event.

nigel

 

[GriffMG]

I *generally* tend to put it in the lost focus event

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[chilltoad]

Thanks again. Still working on it but it is clearly related to 'refresh'. I'm now down to two objects on a form, one is the optiongroup, the other is an object to be visible or not depending on which option is selected. 'thisform.refresh' makes it misbehave, taking it out cures it.

I think though that the key might be the fact that the control has a control source which is a field from a table - I overlooked this, and I hope you don't all go "Duh, if only you'ld told us....". Now checking various buffer modes.

 

[Mike Lewis]

Chilltoad,

The only time a refresh has any effect is if the controls being refreshed have a ControlSource. In general, there's no point in doing a refresh just because you've changed the appearance or visibility of a control.

I don't understand why your refresh is causing this particular problem, but it would definitely make sense to try removing the ControlSources to see what happens.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Mike Lewis]

you can't trust the value of the control (or of the bound data) within the interactivechange event. That seems to occur BEFORE the value is changed.

Nigel, that's definitely not my experience. I use InteractiveChange all the time, including to do the same sort of thing that Chilltoad is trying to do. I don't see any problems with that.

And, at the point that InteractiveChange fires, the value of the control has been updated, so there's no reason not to trust the values.

That said, by all means use a different event if you prefer. I'm not saying the InteractiveChange is the only one, or even the best one - only that it does work reliably.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Nigel Gomm]

Mike,

It was a while ago and one of those things that i never really investigated but problems went away when i moved the code into the valid event.

Most of my controls are bound to custom object properties which may make a difference but i'm sure i remember putting diagnostic code into the interactivechange event and seeing that the the 'value' of the control had not changed (so my code that tested it and changed the form's appearance much as described here wasn't doing what was expected).

From what you say I may well be wrong... but valid() works and i haven't had cause to revisit.

Odd

n

 

[chilltoad]

Well, I'm still not sure what is happening, but with a form with the following (1 x optiongroup, 1 x shape, 2 x options in the group which show or hide the shape, and the optiongroup bound to an integer control source, optimistic buffering) I get:

THISFORM.Refresh within the interactivechange event = misbehaves.

No refresh = works fine.

Remove the control source, works fine with or without the refresh.

BUT
Transfer the code to the valid event of the optiongroup and it seems to work perfectly under all circumstances. > hats off to Nigel.

I'm going to stop worrying about it now, though I'd still be interested to know exactly why the problem arises at all.