In rare circumstances, you may run into an assertion with REALbasic 2008r2 and higher that deals with something called "object definitions." These assertions all look very similar, like this:
failed assertion in commonruntime.cpp:XXXXSomeone called ObjectIsa, passing in an ObjectDefinition that we could not lookup. The object we're looking for is: YYYYY
For instance, you may run into this assertion on the Mac if you have a menubar for the application which does not contain an item whose super is QuitMenuItem. In that case, it'll say the object we're looking for is QuitMenuItem.
Thankfully, these assertions are trivial to work around -- but remember, you should always file a bug report so that we can fix these assertions for you! But in the mean time, you don't want to wait for us to fix them. Whenever you run into one of these assertions, you can fix it with the following block of code:
dim o as Object
if false and _
o IsA XXXX then
end if
Where "XXXX" is the item being looked for. It's a strange looking piece of code, to be sure -- but it will solve the problem for you.
So why do these assertions happen in the first place? Well, for the past few years, we've had a technology to transition from C++ object definitions to REALbasic object definitions. This technology is called the object definition converter, and it was responsible for converting from one object model into the other. However, the down side to having this was that it made adding new functionality to the object model very painful -- you had to remember to hit up this strange converter thing and force it to behave properly. So for the past year, we've been trying to ween our internal technologies from relying on this converter -- and finally, we've "removed" it. It's this removal that is causing pain for people in rare instances (and by rare, we've only found two cases that have been overlooked).
(I put removed in quotes above because it's not quite true. The converter does still exist, and will have to exist for as long as we have a C++ plugin SDK, since the plugin object model still needs to be converted to the REALbasic object model.)
So why do you get those assertions in the first place? Simple -- the linker is doing its job and dead stripping out references to things your project doesn't use. So if your project doesn't make use of a TCPSocket, then there's no sense to carrying around data about the TCPSocket at runtime. However, the C++ code might make use of the TCPSocket class -- and unless we tell the linker to please not dead strip TCPSocket somehow, the C++ code will throw that assertion. The code above accomplished that nicely because of the IsA clause. The code doesn't actually perform any work, but it does cause the compiler to take note of the dependency, which in turn solves the problem.
Plugin authors have to be extra careful of this problem. If your plugin relies on an object internally (via calls to REALnewInstance, for example), then you have to design your plugin in such a way that it alerts the IDE of the internal reliance. The way you do this is by using calls to REALGetClassRef within your PluginEntry method. By doing this, the IDE can be sure to generate code (like above) to ensure that the linker doesn't dead strip the class. For instance, let's say your plugin makes use of the MD5Digest class internally. You'd do something like this:
static REALclassRef md5DigestRef = NULL;
void PluginEntry( void )
{
md5DigestRef = REALGetClassRef( "MD5Digest" );
}
void SomeMethod( void )
{
REALobject obj = REALnewInstance( md5DigestRef );
}
Finally, I'd like to point out that unless you're dealing with C++ code that relies on REALbasic code, there's no need to worry about any of this. The only people that really have to worry about it are REAL Software and plugin authors. If you deal with only REALbasic code, then you're already covered. :-)
In closing, you probably won't ever run into one of these object definition converter assertions. But if you do, be certain to report it (telling us how you get the assertion is especially helpful), and work around it with the code found at the top of the post.
I'm glad to hear that rickety old contraption has finally been retired.
@Mars -- mostly retired. We won't be able to get rid of it for the plugin architecture until a certain secret plugin format v3.0 is implemented. ;-) But until then, we're stuck having to limp the thing along for plugin usage, alas.