Setting hidden properties in Init via DoDefault breaks Hidden visibility 1

[nqramjets]

This seems to just be a bug. (VFP9 SP2) Can anyone confirm that this is strange behavior and that I'm not crazy, or is this something that can be explained away somehow?

This may be related to the thread 626553

I laid out all 3 permutation that are worth investigating in the Case comments in the code.

	LOCAL lcErrorHandler AS String
	lcErrorHandler = ON('ERROR')
	
	ON ERROR ? CHR(9) + "Error: " + MESSAGE()
	
	*
	* Main program
	*
	CLEAR
	LOCAL loChild AS Object
	
	loChild = CREATEOBJECT("cusChild", 8)
	
	? "[Child] Refer to hidden property from outside"
	? loChild.inValue
	
	? "[Child] Call accessor method on class"
	loChild.PrintValue()
	
	* Restore Error Handling
	ON ERROR &lcErrorHandler.
	
RETURN

******************************
DEFINE CLASS cusBase as Custom
******************************

	HIDDEN inValue
	inValue = -1
	
	**************
	PROCEDURE Init
	**************
		LPARAMETERS tnValue
		? PROGRAM() + IIF(VARTYPE(tnValue) == 'N', TEXTMERGE(' - set to <<tnValue>>:'), '')
		IF VARTYPE(tnValue) == 'N'
			*
			* Executing this line via a DoDefault causes an issue
			*
			this.inValue = tnValue
		ENDIF
	ENDPROC
	*******
	
	********************
	PROCEDURE PrintValue
	********************
		? PROGRAM()
		? this.inValue
	ENDPROC
	*******
ENDDEFINE
*********

********************************
DEFINE CLASS cusChild as cusBase
********************************

	**************
	PROCEDURE Init
	**************
		LPARAMETERS tnValue
		*
		* Case 1: DoDefault()			- This causes the desired behavior
		* Case 2: DoDefault(tnValue)	- This UNHIDES the hidden property
		* Case 3: Comment this Init		- This causes the desired behavior
		*
		DODEFAULT()
		
		? PROGRAM() + ' - set to 5:'
		this.inValue = 5
	ENDPROC
	*******
	
	********************
	PROCEDURE PrintValue
	********************
		DODEFAULT()
		? PROGRAM()
		? this.inValue
	ENDPROC
	*******
ENDDEFINE
*********

I have also run into instances after this happens where calling to code in cusBase cannot see the hidden member, but the code in cusChild could. This code sample does not include that behavior, but I believe it's related to the same bug.

Has anyone else run into this?

Thanks,
Ryan

 

[vgulielmus]

Very useful, thank you.
Interesting, a PROTECTED property behaves as expected, only a HIDDEN one shows this peculiarity.


Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[nqramjets]

Interesting, a PROTECTED property behaves as expected, only a HIDDEN one shows this peculiarity.

I know! I noticed that too, which is even more bizarre...

 

[vgulielmus]

I tried your code on a computer with a VFP6 license. The HIDDEN property remains HIDDEN.
Good to know.

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Olaf Doschke]

I remembered in regard to visibility there are some bugs, so I stopped using it and solved it partly by access/assign methods, partly by splitting a class into parts and composiing an instance.

Another topic, but quite similar: The control base class has the special feature to hide every subobject inside it, so it's a container with hidden sub objects. Still SETALL eg done at the form level effects all inner objects. Partly you can consider that nice, but it's breaking the same principle.

The effect of doevents with or without passing in the parameter is news for me. Never seen that as a reason to break hidden.

Bye, Olaf.

 

[nqramjets]

I feel justified if olaf hasn't seen it before!

 

[foxerdb]

It works for me:

-------------------------------------------------------------
CUSBASE.INIT
CUSCHILD.INIT - set to 5:
Error: Property INVALUE is not found.
[Child] Refer to hidden property from outside
Error: Property INVALUE is not found.
[Child] Call accessor method on class
CUSBASE.PRINTVALUE
Error: Operator/operand type mismatch.
CUSCHILD.PRINTVALUE
Error: Property INVALUE is not found.
-------------------------------------------------------------

I'm using VFP 9 SP2 (09.00.0000.5815)

Regards.-

 

[foxerdb]

Sorry, didn't read carefuly, actually I have the same results as you:

CUSBASE.INIT
CUSCHILD.INIT - set to 5:
	Error: Property INVALUE is not found.
[Child] Refer to hidden property from outside
	Error: Property INVALUE is not found.
[Child] Call accessor method on class
CUSBASE.PRINTVALUE
-1
CUSCHILD.PRINTVALUE
	Error: Property INVALUE is not found.

 

[foxerdb]

Hi, me again

CusBase showing the -1 value is the desired behaviour, I'm not sure what is the problem with that...

 

[Olaf Doschke]

If that's your output for case 2, then the bug would only be in VFP9 SP2 9.00.0000.7423.
Only case 2 - dodefault(tnValue) - is the one with the problem. For the latest hotfix version 7423 it outputs:

CUSBASE.INIT - set to 8:   
CUSCHILD.INIT - set to 5:   
[Child] Refer to hidden property from outside   
         5
[Child] Call accessor method on class     
CUSBASE.PRINTVALUE         
         5
CUSCHILD.PRINTVALUE         
         5

First unexpected behaviour: The cusChild init can set inValue to 5 and writes to a hidden property.
Second unexpected behaviour: ? loChild.inValue can access the inValue property
Third unexpected behaviour: The PRINTVALUE method can access the inValue property not only on the parent class level called by dodefault(), but also in the child.

So did you really test case 2 or case 1 and 3?

Bye, Olaf.

 

[Olaf Doschke]

Your output doesn't show the "set to 8" part in cusbase.init, so you didn't tested case2.

Change DODEFAULT() to DODEFAULT(tnValue) in the INIT method of cuschild, that is causing the unwanted behaviour.

Bye, Olaf.

 

[foxerdb]

You are right Olaf, now I can see that.

Thanks.-