Here’s another error that I see quite a lot of times, but never quite pin down what causes it (or at least I’ve forgotten what I did to fix it last time).
.The obvious would be trying to call a protected method - but the message is not indicating a method visible to me.
If you click on the error will it go to the code?
Perhaps look inside a ccPageView you have your probably calling a non-existent method or protected method somewhere there
It just goes to the ccPageView1 which is a container control embedded in ccMain. But doesn’t go to any method within ccPageView. This is the only error being flagged by the IDE. It seems to point to the Name of the ccPageView - but nothing is calling that.
Ah, now I found it. Constructor was local! Duh! At least I now have a record for next time.
I experienced this error right now, and thought my project was corrupted. IMO Xojo should really throw a clearer message in this case.
To clarify, whenever there’s a compile error message like that which refers to the name of an object, the error is occurring in the code that gets rendered by the IDE to attach certain objects to the binary.
Now, that doesn’t mean that the error is in the rendered code, just that it’s encountered something that it didn’t expect or wasn’t planned for.
If you’re ever really stuck, you can send the project to Xojo and they can tell you what the actual error is.
I guessed so, but it’s still hard to track the issue.
Good to know, but I’d rather prefer that the IDE tells us the problem.
As it is, it feels like there’s missing feature.
Thanks for your answer.
It really can’t. That code only exists while compiling, so when it goes to show an error, the only info it has that lines up with anything is the object itself and it shows the first defined element which is the name property. It sucks, but it’s better than “An error occurred” with no information about what object was having trouble.
A “This method is protected. It can only be called from within its class” should be a warning, as methods like that could be allowed. The only exception I know in Xojo is a constructor(), that Xojo seems to demand being public (some languages not, like C# when classes contains only static components)
So the high-level compiler got such message from the low-level, and got the status “Is Error”, and know the object presenting it, then probably it could infer a better message as “Class ‘Whatever’ contains a private/protected constructor”.
Am I missing something?
Edit: same content, better redacted, emphasized some words
Presumably you either reorganise where the method lives, or change its scope.
We are not discussing how to fix such case, but how the compiler can present a better message to the user, so they don’t need to scratch their heads to know where the problem is.
As you did not read the case, the user got a message pointing to a property, the name property, and a cryptic message about a protected method. Clueless about the real error.
He found it, he fixed it.
Edit: head → heads now->know
Well, there it is - too many notes.
Given what you’re saying about the compiler, wouldn’t it be possible for a private Constructor to be detected “one level up” in the compilation process? Xojo is such a strictly typed language that it should be possible to detect all cases where such a class is being instantiated outside of a class method.
This would certainly be more useful than the existing error. It’s one of the advantages of a strictly typed language that it can be usefully subjected to this kind of analysis.
Whatever. See if you can get Xojo to fix it.
You can also get this error message by trying to call any private class method, so the different cases need to be differentiated. They’re not all private Constructors.
From the outside the compiler should point-out correctly the offending method line as:
myObj.MyFunc(1) // This method is protected. It can only be called from within its class
And if possible the autocomplete should not expose MyFunc() out of the correct context too.
Both are true currently. I’m pointing out that contrary to your previous comment that it is possible to get that message with a conventional method, not a private Constructor.
Well, the second case is ok. I was referring to call from the context not outside the context.
I mean, a self.MyFunc(1) does not fire errors for a MyObj Private Myfunc(num As Integer)
But just the presence of MyObj Private Constructor() probably causes stir in Xojo and I guess they can find the distinction at compile time and emit a better message.
