Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

class extensions (was Re: FSRef support in plugin API) (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: DX midi plugin back in town?
Next thread: FSRef support in plugin API


Re: FSRef support in plugin API   -   Thomas Tempelmann
  class extensions (was Re: FSRef support in plugin API)   -   Joseph J. Strout
    Re: class extensions (was Re: FSRef support in plugin API)   -   François Menneteau <
     Re: class extensions (was Re: FSRef support in plugin API)   -   Alfred Van Hoek
    Re: class extensions (was Re: FSRef support in plugin API)   -   Joseph J. Strout
    Re: class extensions (was Re: FSRef support in plugin API)   -   François Menneteau <
    Re: class extensions (was Re: FSRef support in plugin API)   -   Joseph J. Strout

class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:07 (Wed, 5 Jun 2002 09:07:20 -0700)
From: Joseph J. Strout
At 5:45 PM +0200 6/5/02, François Menneteau wrote:

> > That's right, and in fact, it may be difficult to support class
>> extensions at all in future versions of RB. The next release of the
>> SDK will probably include some verbiage warning you to avoid class
> > extensions, and to use subclassing instead wherever possible.
>
>But this is not always the case.
>Typically, I have extended the graphic class. Unless there is a way to
>tell RB to use a subclass of the graphic class to all object that have a
>graphic property (mainly canvas and picture) there is no other solution
>that to use a class extension.

Right, but we're trying to make classes that historically have not
been subclassable, subclassable (e.g. Picture, MemoryBlock, and
FolderItem). Graphics is one that still isn't usefully subclassable
-- but it could be, if it had a copy constructor (like FolderItem now
does). So when you run into one of these cases that affects, please
let us know.

And I'm not saying for sure that class extensions are going away --
it's possible we'll find some way to continue supporting them. I'm
only saying that it's a bit iffy at this point.

Best,
- Joe

-

Re: class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:20 (Wed, 05 Jun 2002 18:20:57 +0200)
From: François Menneteau <


"Joseph J. Strout" wrote:

> At 5:45 PM +0200 6/5/02, François Menneteau wrote:
>
> > > That's right, and in fact, it may be difficult to support class
> >> extensions at all in future versions of RB. The next release of the
> >> SDK will probably include some verbiage warning you to avoid class
> > > extensions, and to use subclassing instead wherever possible.
> >
> >But this is not always the case.
> >Typically, I have extended the graphic class. Unless there is a way to
> >tell RB to use a subclass of the graphic class to all object that have a
> >graphic property (mainly canvas and picture) there is no other solution
> >that to use a class extension.
>
> Right, but we're trying to make classes that historically have not
> been subclassable, subclassable (e.g. Picture, MemoryBlock, and
> FolderItem). Graphics is one that still isn't usefully subclassable
> -- but it could be, if it had a copy constructor (like FolderItem now
> does). So when you run into one of these cases that affects, please
> let us know.
>

But, as I said, subclassing is of no use, if you cannot tell a standard
object to use the subclass instead of the default class.

>
> And I'm not saying for sure that class extensions are going away --
> it's possible we'll find some way to continue supporting them. I'm
> only saying that it's a bit iffy at this point.

Well, if class extension is not longer supported, I can throw away nearly
two years of development.... :-(

-

Re: class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:45 (Wed, 05 Jun 2002 12:45:21 -0400)
From: Alfred Van Hoek
on 6/5/02 12:20 PM, François Menneteau at <email address removed> wrote:

> But, as I said, subclassing is of no use, if you cannot tell a standard
> object to use the subclass instead of the default class.
>

Very good point, if RS would drop that kind of support... Unless they
provide ways to the plugin author to replace the graphics property of a
canvas or a picture to a subclass.

When a picture is instantiated with newPicture it automatically instantiates
an instance of the graphics class. This behavior asks for support of the
classExtension. However, if RS would make available:

dim p as picture
p = new picture
p.graphics = new graphics

and

canvas1.graphics = new graphics

the problem would not exist, because any sublass of graphics could be
instantiated and assigned to the canvas.graphics and picture.graphics
properties. It even allows for:

canvas1.graphics = new mySubClassGraphics(object, integer)

giving even more variety of development.

So my opinion is: Go for it Joe..

Alfred


- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:29 (Wed, 5 Jun 2002 09:29:17 -0700)
From: Joseph J. Strout
At 6:20 PM +0200 6/5/02, François Menneteau wrote:

>But, as I said, subclassing is of no use, if you cannot tell a standard
>object to use the subclass instead of the default class.

I heard you, which is why I said:

> > Graphics is one that still isn't usefully subclassable
> > -- but it could be, if it had a copy constructor

Maybe this wasn't clear. You would do:

Dim g as MyGraphicsSubclass

g = New MyGraphicsSubclass(myPic.graphics)

and now you'd have something that can draw into "myPic", with all the
extra methods and properties of MyGraphicsSubclass. Not currently
possible, but it could be.

> > And I'm not saying for sure that class extensions are going away --
>> it's possible we'll find some way to continue supporting them. I'm
>> only saying that it's a bit iffy at this point.
>
>Well, if class extension is not longer supported, I can throw away nearly
>two years of development.... :-(

Not if you tell us what classes you're extending, and why subclasses
won't work, so that we can make them work (as in the example above).

Best,
- Joe

-

Re: class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:49 (Wed, 05 Jun 2002 18:49:01 +0200)
From: François Menneteau <


"Joseph J. Strout" wrote:

> At 6:20 PM +0200 6/5/02, François Menneteau wrote:
>
> >But, as I said, subclassing is of no use, if you cannot tell a standard
> >object to use the subclass instead of the default class.
>
> I heard you, which is why I said:
>
> > > Graphics is one that still isn't usefully subclassable
> > > -- but it could be, if it had a copy constructor
>
> Maybe this wasn't clear. You would do:
>
> Dim g as MyGraphicsSubclass
>
> g = New MyGraphicsSubclass(myPic.graphics)
>
> and now you'd have something that can draw into "myPic", with all the
> extra methods and properties of MyGraphicsSubclass. Not currently
> possible, but it could be.
>

but in that case, you would have to manipulate two entities: myPic and g?
or myPic.graphics is replaced by g and I only need to access myPic.graphics?

>
> > > And I'm not saying for sure that class extensions are going away --
> >> it's possible we'll find some way to continue supporting them. I'm
> >> only saying that it's a bit iffy at this point.
> >
> >Well, if class extension is not longer supported, I can throw away nearly
> >two years of development.... :-(
>
> Not if you tell us what classes you're extending, and why subclasses
> won't work, so that we can make them work (as in the example above).
>

Fortunately, I have extended only the graphic class.

-

Re: class extensions (was Re: FSRef support in plugin API)
Date: 05.06.02 17:59 (Wed, 5 Jun 2002 09:59:27 -0700)
From: Joseph J. Strout
At 6:49 PM +0200 6/5/02, François Menneteau wrote:

> > Maybe this wasn't clear. You would do:
>>
>> Dim g as MyGraphicsSubclass
>>
>> g = New MyGraphicsSubclass(myPic.graphics)
>>
>> and now you'd have something that can draw into "myPic", with all the
>> extra methods and properties of MyGraphicsSubclass. Not currently
> > possible, but it could be.
>
>but in that case, you would have to manipulate two entities: myPic and g?

No...

>or myPic.graphics is replaced by g and I only need to access myPic.graphics?

No, there's no replacement going on. We're talking here about two
graphics objects that access the same drawing area. Just like you
can have two FolderItems that refer to the same file.

> > Not if you tell us what classes you're extending, and why subclasses
> > won't work, so that we can make them work (as in the example above).
>
>Fortunately, I have extended only the graphic class.

OK. Then I would recommend you put in a request with REALbugs to
make the Graphics class usefully subclassable (and explain why).

Thanks,
- Joe

-