realbasic-plugins
[Top] [All Lists]

Re: Treating a class as a control... bummer?

To: REALbasic Plugins <realbasic-plugins at lists dot realsoftware dot com>
Subject: Re: Treating a class as a control... bummer?
From: Jonathan Johnson <jonj at realsoftware dot com>
Date: Tue, 26 Apr 2005 09:54:34 -0500
Delivered-to: realbasic-plugins at lists dot realsoftware dot com
References: <BE93C46A dot C767%vanhoek at mac dot com>

On Apr 26, 2005, at 9:11 AM, Alfred Van Hoek wrote:
Thanks Jon, I haven't tracked it down though, and it is something that needs
to be fixed, because the plugin is clobbering memory:

The situation described with the class instance on the window with debugging messages turned of shows that the crash occurs in the destructor, because an
invalid pointer to a REALobject is mistakenly used to unlock the
non-existent object. (I had to add other debugging message apis to localize this). With debugging messages on, the destructor of the class isn't even been called. All this does not appear to happen when the class instance is
created in code.

Are you making sure to Lock the objects when you store them? Are your properties REALstandardGetter/REALstandardSetter or are they custom setters? What do you need to do to recreate the crash? Just put it on the window, run it, close the window? Does it matter if anything else is on the window? What all methods of yours are being called before the crash?

Recreating a sample plugin that does not have props or methods, but a
default constructor and destructor and a struct similar to the plugin under
investigation is ok. I am now wondering if it might be due to property
setters, which RB is calling after compilation of the sample app.

Are there any control property names that should be avoided even as they are declared as "REALinRuntimeOnly"?. Just wondering... I know that the custom default constructor (as well as the defaultConstructor) of the class is only called at runtime, explaining why pre-set properties are not displayed in
the properties window..

The only property names you should avoid are those that are in the class hierarchy already. For example, if your superclass is Control, then don't create a property called "Left", because you would be shadowing it.

-Jon


--
Jonathan Johnson
REAL Software, Inc.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>