Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
DODEFAULT with parameters
Message
From
07/08/2001 10:28:07
Keith Payne
Technical Marketing Solutions
Florida, United States
 
 
To
04/08/2001 02:45:48
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00538014
Message ID:
00540674
Views:
14
>Keith-
>
>>An important item that may be overlooked is that using dodefault() effectively breaks pcount().
>
>That's interesting. I've never run up against it with PCOUNT(). I wouldn't use PARAMETERS(), of course. That _does_ break. Do you have an example for PCOUNT()? I, for example tried it with keypress in the spirit of the thread and found it *seemed* to operate fine.

Nancy,

I recently modified one of my apps by adding code to a method in one of the classes. The method had been defined in a parent class and expected 3 or 4 parameters - the last is optional.

When I added the code, I used DODEFAULT(param1, param2, param3, param4) because I saw that 4 parameters were in the auto-generated LPARAMETERS line. Of course, the program exhibited some unexpected behavior. When I traced through the code, I saw that I was using PCOUNT() in the original class.

Passing the original paramaters through with DODEFAULT() didn't work because the 4th parameter comes through as .F. when there is not a corresponding parameter in the original call. When the .F. is passed up the chain, the receiving methods see 4 parameters, not 3:
oParentTest = createobject('MyClass')
oParentTest.Testit('This is a test')

oTest = createobject('MyChildClass')
oTest.Testit('This is a test')

release oTest, oParentTest

define class MyClass as custom
	procedure Testit
		lparameters p1, p2

		wait 'P1:'+vartype(p1)+':'+transform(p1) window
		if pcount() > 1
			wait 'P2:'+vartype(p2)+':'+transform(p2) window
		else
			wait 'P2: No parameter passed' window
		endif
	endproc
enddefine

define class MyChildClass as MyClass
	procedure Testit
		lparameters p1, p2

		dodefault(p1, p2)
	endproc
enddefine
From this example you can see that in order to obtain the correct results, we would have to test for the existance of parameters in the child method before calling the parent with dodefault():
define class MyChildClass as MyClass
	procedure Testit
		lparameters p1, p2

		do case
			case pcount() = 0
				dodefault()
			case pcount() = 1
				dodefault(p1)
			otherwise
				dodefault(p1, p2)
		endcase
	endproc
enddefine
So we have some choices as a developer:

1. Never use optional parameters in our custom methods
2. Always use a do case..endcase when using dodefault()
3. Always test the count and type of all parameters in every public method before using them AND write some error handling code if they don't match, which could break when dealing with logical parameters.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform