Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Dodefault nodefault dodefault
Message
De
13/08/2009 15:38:01
 
 
À
13/08/2009 09:10:18
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
01417200
Message ID:
01417993
Vues:
60
Yes, that's right. However, your argument about parentclass=baseclass is not entirely true, imo. See my newer thread #1417566.

>>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 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 alos 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?
>
>The NODEF position is not important.
>It prevents the processing of the native Baseclass VFP code when the event/method ends.
>
>If you put a DODEF() into a Class where ParentClass=BaseClass,
>the Baseclass's intrinsic native behavior can to be performed.
>
>Example:
>
>PUBLIC oform1
>
>oform1=NEWOBJECT("form1")
>oform1.Show
>RETURN
>
>DEFINE CLASS form1 AS form
>
>
>	DoCreate = .T.
>	Caption = "Form1"
>	Name = "Form1"
>
>
>	ADD OBJECT text1 AS textbox WITH ;
>		Height = 23, ;
>		Left = 86, ;
>		Top = 27, ;
>		Width = 100, ;
>		Name = "Text1"
>
>
>	ADD OBJECT text2 AS textbox WITH ;
>		Height = 23, ;
>		Left = 86, ;
>		Top = 78, ;
>		Width = 100, ;
>		Name = "Text2"
>
>
>	PROCEDURE text1.Click
>		thisform.text2.Value = SECONDS()
>	ENDPROC
>
>
>	PROCEDURE text1.LostFocus
>		NODEFAULT
>		DODEFAULT()	&& this is a void call
>	ENDPROC
>
>
>	PROCEDURE text1.KeyPress
>		LPARAMETERS nKeyCode, nShiftAltCtrl
>		NODEFAULT
>		DODEFAULT() && native code call, put the char
>		DODEFAULT() && native code call, put the char
>	ENDPROC
>
>
>	PROCEDURE text1.GotFocus
>		NODEFAULT
>		DODEFAULT() && native code call
>	ENDPROC
>
>
>	PROCEDURE text1.MouseUp
>		LPARAMETERS nButton, nShift, nXCoord, nYCoord
>		NODEFAULT
>		DODEFAULT()	&& this is a void call
>	ENDPROC
>
>ENDDEFINE
>
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.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform