on 4/25/05 10:15 PM, Jonathan Johnson at jonj at realsoftware dot com wrote:
> On Apr 24, 2005, at 3:39 PM, Alfred Van Hoek wrote:
>> I know, but it is not an issue here. Both mac and windows show the same
>> problem with bytes 16-20 of a class' struct when the class instance
>> becomes
>> a control/rectControl. It is consistent. I wonder that is might be due
>> to
>> the different offsets classes and controls have. I have to investigate
>> this
>> further. The plug depends heavily on users "dropping", i.e.
>> "control-click
>> on the window and then choose your class" wanting to have an instance
>> on the
>> window.
>
> When you put a class on a window, it doesn't become a control. It still
> is your class, and your super does not change. In both cases, they are
> created with "New". On a window, if you have any properties set to be
> visible in the properties window, the properties will be set upon
> creation of that instance. That's really the only difference I can
> think of.
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.
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..
Perhaps I am on the wrong track, just venting some ideas..
Alfred
_______________________________________________
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>
|