Assign method cannot be recursive?

I noticed that an assign method will not allow itself to
be called while it is in the call stack (i.e. cannot be
recursive in any way). I don't see this mentioned in the
documentation for assign methods. Is this a known restriction?

In my case, a property's value gets changed which causes
a series of other methods to run and update various tables
and controls on a form. During the course of these updates,
the original property may get changed to a new value, but
the assign method does not get called. I can work around
this, and it is an odd case where this would need to be
supported, but it is not completely out of line to need
this to work.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

Altman
Wed Mar 23 15:38:01 CST 2005

This is probably there to protect itself from an infinite recursion
situation. If I change the value of my property for example myClass.MyProp.
Lets say the assign method calls myClass.myMethod which in turn changes the
myProp value. If the assign method is called again this would more than
likely call myMethod again which would call myProp_assign which would call
myMethod (oh boy I am dizzy). Granted there is a way that one can make this
not happen but most people wouldn't think of that until there program
crashes. Not only that, but I wouldn't expect MS to change it, because I am
sure there are many programs that this situation would occur.

"Tim Witort" <trw7at@ixdot.netcomdotcom> wrote in message
news:Xns9622752B42656timwitortwrotethis@207.217.125.201...
>I noticed that an assign method will not allow itself to
> be called while it is in the call stack (i.e. cannot be
> recursive in any way). I don't see this mentioned in the
> documentation for assign methods. Is this a known restriction?
>
> In my case, a property's value gets changed which causes
> a series of other methods to run and update various tables
> and controls on a form. During the course of these updates,
> the original property may get changed to a new value, but
> the assign method does not get called. I can work around
> this, and it is an odd case where this would need to be
> supported, but it is not completely out of line to need
> this to work.
>
> -- TRW
> _______________________________________
> t r w 7
> at
> i x dot n e t c o m dot c o m
> _______________________________________

David
Wed Mar 23 19:50:57 CST 2005

Tim,

You might want to use ProgramaticChange which triggers only when code makes
the change.

--
df - Microsoft MVP FoxPro http://www.geocities.com/df_foxpro

"Tim Witort" <trw7at@ixdot.netcomdotcom> wrote in message
news:Xns9622752B42656timwitortwrotethis@207.217.125.201...
>I noticed that an assign method will not allow itself to
> be called while it is in the call stack (i.e. cannot be
> recursive in any way). I don't see this mentioned in the
> documentation for assign methods. Is this a known restriction?
>
> In my case, a property's value gets changed which causes
> a series of other methods to run and update various tables
> and controls on a form. During the course of these updates,
> the original property may get changed to a new value, but
> the assign method does not get called. I can work around
> this, and it is an odd case where this would need to be
> supported, but it is not completely out of line to need
> this to work.

trw7at
Thu Mar 24 11:27:13 CST 2005

David Frankenbach seemed to utter in
news:#sAbuPBMFHA.3788@tk2msftngp13.phx.gbl:

> Tim,
>
> You might want to use ProgramaticChange which triggers only when code
> makes the change.

This code is related to a custom property, not the Value property
which is what ProgrammaticChange and InteractiveChange look at.
So ProgrammaticChange is not useful is this case.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________