on 4/26/05 10:54 AM, Jonathan Johnson at jonj at realsoftware dot com wrote:
> Are you making sure to Lock the objects when you store them?
Yes, they are.
> Are your properties REALstandardGetter/REALstandardSetter or are they custom
> setters?
Custom.
> What do you need to do to recreate the crash? Just put it on
> the window, run it, close the window?
Yes, nothing fancy, unless the code under the hood is to be regarded, and
categorized as, fancy.
> Does it matter if anything else
> is on the window? What all methods of yours are being called before
> the crash?
That's a good question, but just to repeat for clearness: When the class is
instantiated in code, i.e., choose a new class1 and make it the subclass of
the class under investigation, running it and then closing it shows that the
destructor is called (whether or not debugging messages were enabled), no
crashing (everything is fine and behaves as it should) contrary to the class
instance on the window. So to answer the above, the class is a widget and in
essence the same calls are being executed, apart from the fact that setters
are being called when the class instance lives already on the window.
>
>> 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.
I understand. The point though is that the class' super is an object and the
only properties it could then shadow are left and top. There are runtime
only properties of the class, which resemble those of a rectControl,
including left and top. These two were changed to leftPos and topPos, while
other properties remain to mimic those of a rectControl. Since your answers
were very clear, "the class remains a class and does not become a
rectControl", it seems then that the idea that setters are involved is a
dead end. I'll have to do some final test-changes (change all those property
names to other names) to corroborate your statement.
All I can say is that all methods and properties do the right thing, and
this is substantiated by the flawless instantiation of the class in code, as
well as its destruction.
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>
|