Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Dodefault nodefault dodefault
Message
From
10/08/2009 17:41:38
 
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01417200
Message ID:
01417205
Views:
79
That is what I wrote also. But I now have an example where the intrinsic native behavior fires twice if I omit NODEFAULT, due to the DODEFAULT(). This indicates that there are situations that the intrinsic native behavior is tied to a subclass rather than to the chain of subclasses. To say it in other words, which of the following statements is true?
1) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the current VFP subclass after it finishes.
2) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the entire VFP event (including all subclasses) after it finishes.

Having said all that, I think the clearest (and therefore best) article sofar on the topic of the odd behavior of NODEFAULT/DODEFAULT() is written by Andy Kramek on his weblog (http://weblogs.foxite.com/andykramek/archive/2009/04/11/8075.aspx). If his explanation is entirely right, then the next statement is true.

2) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the entire VFP event (including all subclasses) after it finishes, UNLESS the first level subclass (that is based on the base class) contains a DODEFAULT(), in which case that line will invoke the default processing at the end of the code of the first subclass.

The consequence is that the default behavior can fire twice if the NODEFAULT is not declared in the youngest child. That is the situation I'm encountering currently in one of my apps.


>The NODEFAULT statement only sets flag that tells VFP do not perform default processing for that VFP event after it finishes. Functionally, it doesn't matter where you put it.
>
>>The pieces of code below both have dodefault() and nodefault, but their order differs. Some would argue that the effect is entirely similar, but is this always true?
>>
...
>>dodefault()
>>nodefault
>>...
...
>>nodefault
>>dodefault()
>>...
>>I have always thought of NODEFAULT as a toggle that will prevent the intrinsic native behavior of the event, which will fire after all code. But I have also always thought of the intrinsic native behavior as firing ONLY in the topmost (youngest child) subclass. That is, all parentclasses and the base class that are visited via DODEFAULT() will not fire the intrinsic native behavior.
>>
>>Now I have to deal with a subclass that appears to fire the intrinsic native behavior twice. The youngest child contains no NODEFAULT, so the intrinsic native behavior fires at the end of the event, but it also appears to fire as a result of DODEFAULT() in the parent class. This is odd, to say the least. I have searched here and there. There is some debate as to whether it is a bug or a confusing and badly documented design feature.
>>
>>I have tried to discover whether or not there is a difference between declaring NODEFAULT prior to DODEFAULT(). The idea is that this may actually also prevent the intrinsic native behavior in the parent class(es).
>>
>>Who can help?
Groet,
Peter de Valença

Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform