Have you looked at the command “Value type” to test the value type of an object value?
Value type https://doc.4d.com/4Dv17R3/4D/17-R3/Value-type.301-3906446.en.html <https://doc.4d.com/4Dv17R3/4D/17-R3/Value-type.301-3906446.en.html> Remember that the “String” command simply returns a string when its parameter is **also** a string. So “Some_Method” might replace > ALERT(String($obj.val)) with If (Value type($obj.val)=Is longint) ALERT(String($obj.val)) else ALERT($obj.val) end if —— And “test_Calc” might replace > $obj.val:=$obj.val*3 with if (Value type($obj.val)=Is longint) $obj.val:=$obj.val*3 end if —— And the “Shift” assignment might replace > If (Shift down) > $v:="ward_a" > Else > $v:=30 > End if with simply If (Shift down) $obj.val:="ward_a" Else $obj.val:=30 End if > On Mar 12, 2019, at 4:18 PM, Keith Culotta via 4D_Tech <[email protected]> > wrote: > > This seems to be a really advantageous way to use objects. It compiles and > returns good results. I can see where caution would be advised, but is using > an object this way going to break eventually as the 4D language matures, or > is it an advantage of objects? > > // ---------------------------------------------------- > // Method: test_Calc > // INPUT1: Object > C_OBJECT($obj;$1) > $obj:=$1 > $obj.val:=$obj.val*3 > > > // ----------------------------------- > // Method: Some_Method > C_OBJECT($obj) > If (Shift down) > $obj:=New object("val";"ward_a") // Alert displays "ward_award_award_a" > Else > $obj:=New object("val";30) // Alert displays 90 > End if > test_Calc ($obj) > ALERT(String($obj.val)) > > > //------------------- > // this would not compile > // If (Shift down) > // $v:="ward_a" > // Else > // $v:=30 > // End if ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
