Excellent. That’ll narrow it even further for the engineers. Great thinking.
You don’t need the identifier property either.
The arguments for the Rect Constructor don’t appear to be optional, either. In this test example they are missing so how come that doesn’t give a compiler error?
The constructor parameters are not optional, but there is apparently a Constructor override with no parameters (documentation error, but one thing at a time). You can test this yourself with:
var r as new rect
I didn’t implement the full constructor to simplify (x as Double, y as Double, width as Double, height as Double). When I do, the result is the same. I can re-upload the modified test project if you really need me to.
I just opened the project, clicked Run and got the compile errors.
Switching the super to REALBASIC.Rect and then back to Rect like what Mike D did still gives me compile errors.
Yeah, I don’t know why you’re seeing the expected behavior and some of us aren’t. I’ll be adding that to the report.
No need, I did that too and also no change.
<https://xojo.com/issue/68583>
Please, everyone, feel free to add any info you believe to be relevant that I may have missed.
Yes.
Its not a version I actually use / have a build license for so I launched it just to test this.
More weirdness:
Trying the same technique in 2019R1.1, which does not have a “Rect” class at all, the compile fails as expected.
However, it also gives this weird error message:
“TestClass.Super: Multiple Inheritance is not allowed: Rect”
If I create a new class : cRect, set the supers of the class to cRect, then delete cRect from the project, I get compile errors (as expected) but the “Multiple Inheritance is not allowed” error no longer shows up.
So this seems like something is specifically weird with the keyword “Rect” that happens in 2019R1.1 even though that version lacks the “Rect” class…
Can you add that to the Feedback Case? Might help them further narrow the scope of the issue.
I think this is not a bug. Just you guys are unaware of the Operator_Convert called in the assignment.
1 Like
It is, at the very least, a change in behavior of the Rect classes which Xojo has had for a very long time. What used to cause a compiler error no longer does, and can lead to users writing code that results in issues they may have trouble determining the cause of or correcting.
Not to mention the fact that, according to the above discussion, the behavior may not be consistent among users.
If you take the sample project, and create a new class cRect, and change the supers to cRect:
Class cRect
Public Function Operator_Convert() As cRect
break
End Function
it fails to compile, which is as expected.
However, if you add Operator_Convert as variant (which seems like a bad idea, but hey):
Class cRect
Public Function Operator_Convert() As Variant
return me
End Function
Now it will compile (which is legal, since the compiler can do the conversion to variant) but then it fails at runtime with an illegalCastException (as expected) “TestClass cannot be cast to OtherTestClass.”
The same setup, but using Rect instead of cRect compiles AND runs without error, which I don’t think should be possible.
@Christian_Schmitz : I’m not understanding how Operator_Convert could be to blame here…
Possible smoking gun?
Looking at the object using Introspection, I see it has 14 methods:
2 of these are Operator_Convert.
The first one converts to REALbasic.Rect
The second converts to Nil - that’s not good, is it?
What could did you run to do this and i’ll try it on mine.
I also see that the Operator_Convert which converts to REALbasic.Rect has a different Name and FullName, and the Name is “Rect” - I wonder if this could also be confusing the compiler?
Use this code inside Window.Opening:
var obj as new TestClass
var otherObj as OtherTestClass = obj
var backAgain as TestClass = otherObj
dim ti as Introspection.TypeInfo = Introspection.GetType(OtherObj)
dim mi() as Introspection.MethodInfo = ti.GetMethods
break
Thanks. That won’t run for me since the compiler is doing the right thing
(I thought you might have been checking obj).