Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Enable or Visible Event ?
Message
From
12/11/1997 15:41:46
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
10/11/1997 11:30:01
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00058138
Message ID:
00059797
Views:
38
>>Maybe I wasn't reading your post correctly, but I did not see >>any place that you actually change the "this.value". As Erik said >>you have to change the "this.value" not the "this.controlsource" to >>trigger the programmatic change event. Anyways the point is moot. >>I think Erik's method using timers is going to be a better way of >>handling the problem, for reasons he suggested earlier in the >>thread. Try that first. > >To elaborate on Dan's point; >control.programmatic change does not fire when the value of a control >source is changed. For programmatic change to fire, youmust explicitly >change the value in code: control1.value = "so-and-so". You can verify this >by putting code in the programmatic change of a databound control and >moving the record pointer. No fire. This really isn't so bad though, I >think that if you want code to fire when the value of a databound control >changed, you could fire it whereveryou move the pointer from, check the >value in the control's refresh (where the value databound control's value >really gets changed anyway.) Thanks, you gave me a push into the right direction, and this did the trick: * checkbox.refresh DoDefault() if this.value this.caption="Enabled" else this.caption="Disabled" endif nodefault The reason is that the values are assigned from controlsources to the object.value in the refresh(); I've noticed this had fired wrong way, because the checkbox.controlsource="Thisform.command1.enabled" was evaluated only _after_ the checkbox.refresh. But there's one drawback to this solution - I have to call thisform.refresh else checkbox.refresh won't fire just by itself. >Your second strategy (though pretty creative) is flawed as well. I believe >that the caption property is evaluated only at the control's init, or when >the value is explicitly changed. It cannot be used like a gridcolumn's >dynamic properties, or like a control source. Also, if the code you posted >is what you actually used, I would guess that you got a data type mismatch, >becuase a control.enabled property is a logical field, and doesn't evaluate >to "Enabled" or "Disabled". Of course, so it was either like the code above, or Iif(thisform.command1.enabled,"Enabled","Disabled"). >I think that these methods fail because of a simple hard fact: there is no >built in automatic mechanism that watches the values of properties of >controls and notifies us. Each property takes care of itself internally, >and the people who designed those controls didn't think that we developers >need to automatically know when the value changes. If we want to know, we >have to check it ourselves. The timer method is not only (I believe) the >best method we have, but it is the published and standard method not only >in VFP, but in VB, and I suspect in other event-driven languages. Since the timer has its drawbacks (like overhead, firing at wrong moments etc), this way is an alternative - it costs you only firing thisform.refresh when you want to see the controls changing value, caption, color or whatever, based on the value of any other control's property. (I'm not sure who originated this thread - probably it was Dan, but then my initials are DAN, so it's half mine - I just got curious). HTH to whoever needed this.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform