[Cuis-dev] minimum requirements for a BoxMorph subclass

Mark Volkmann r.mark.volkmann at gmail.com
Sun Dec 15 14:12:23 PST 2024


I did read that, in fact multiple times. I want to explain why I didn't
interpret that as meaning that I shouldn't subclass BoxMorph. My thinking
was that I DID want to implement a morph that can be displayed in a
rectangular area. I didn't interpret it to mean I have to actually draw a
rectangle. I assumed that I could just draw anything I want inside a
rectangular area. So I drew a diagonal line and it didn't render.

Mariano suggested that I needed to send "super drawOn: canvas" in my drawOn:
method. But I see now that what is really necessary to implement the
following methods in my subclass or BoxMorph. This works.

defaultExtent
    ^`200 at 200`.

drawOn: aCanvas
    aCanvas strokeWidth: 10 color: Color red do: [
        aCanvas
            moveTo: 0 @ 0;
            lineTo: extent x @ extent y
    ]

requiresVectorCanvas
    ^true

On Sun, Dec 15, 2024 at 1:37 PM Juan Vuletich <juan at cuis.st> wrote:

> II'm pastiing the BoxMorph class comment for reference:
>
> Hierarchy for morphs that are rectangle like, and that occupy an area that
> can be specified as a Rectangle. This means that, besides being of
> rectangular shape, sides are aligned with local coordinate axes. Including
> rectangles with rounded corners and such. The idea is that the 'extent'
> ivar is all that's needed to establish our dimensions and shape.
> Subclasses can add things like 'roundedCornerRadius' or such.
> Note: Answers false to #submorphsMightProtrude. If you need a box like
> morph that can hold submorphs that can protrude if (i.e. submorphs may
> extend beyond box bounds) DONT subclass from here.
>
> Hope this helps.
>
> On 12/15/2024 3:15 PM, Mark Volkmann via Cuis-dev wrote:
>
> Thanks! I didn't consider doing that because I didn't want the default
> light green background. And it seems "super drawOn: aCanvas" isn't
> necessary when the superclass is Morph or PlacedMorph.
>
> On Sun, Dec 15, 2024 at 11:51 AM Mariano Montone <marianomontone at gmail.com>
> wrote:
>
>> You are forgetting to call to super. Always consider that when you are
>> overriding a method.
>>
>> It works. Look at screenshot attached.
>> El 15/12/24 a las 13:41, Mark Volkmann escribió:
>>
>> On Sun, Dec 15, 2024 at 7:37 AM Mariano Montone via Cuis-dev <
>> cuis-dev at lists.cuis.st> wrote:
>>
>>> Hi Mark,
>>> El 14/12/24 a las 22:42, Mark Volkmann via Cuis-dev escribió:
>>>
>>> I'm trying to understand what is required to create a subclass of
>>> BoxMorph. I know I need to implement the drawOn: instance method. And I
>>> believe that depending on how I implement that, I need to implement the
>>> requiresVectorCanvas method to return true.
>>>
>>> Is anything else required? I think more must be required, because I
>>> can't get a basic example to work doing only those things.
>>>
>>> Have you tried browsing BoxMorph hierarchy and looking at its subclasses?
>>>
>>
>> Yes. In particular I looked at ColoredBoxMorph. That has no class
>> methods and 6 instance methods. The only method that does something not
>> directly related to color is color: which sends #redrawNeeded to self
>> when the color is changed. The initialize method sends #color: with the
>> default color, so I thought perhaps when subclassing BoxMorph, I need to
>> send #redrawNeeded. I added the following instance method, but that
>> didn't help.
>>
>> initialize
>>     super initialize.
>>     self redrawNeeded
>>
>>>
>>> I'd especially appreciate it if someone can tell me how I could have
>>> determined the answer on my own by looking at the source. I tried to do
>>> that and failed.
>>>
>>> How is it failing? Perhaps attach example of what you are trying to do
>>> ... it shouldn't be much more than implementing a #drawOn: method ...
>>>
>>
>> If I create the class Try1 as a subclass of Morph, add the following
>> drawOn: method, and evaluate Try1 new openInWorld in a workspace, it
>> works as expected.
>>
>> drawOn: aCanvas
>>     aCanvas class name print.
>>     aCanvas strokeWidth: 10 color: Color red do: [
>>         aCanvas
>>             moveTo: 100 @ 100;
>>             lineTo: 200 @ 200
>>     ].
>>
>> If I create the class Try2 ais a subclass or PlacedMorph, add the same
>> drawOn: method, and evaluate Try2 new openInWorld in a workspace, it
>> also works.
>>
>> But if I create the class Try3 as a subclass of BoxMorph, add the same
>> drawOn: method, and evaluate Try3 new openInWorld in a workspace, it
>> does not work. I get the error "MessageNotUnderstood:
>> HybridCanvas>>strokeWidth:color:do:". I understand that is because
>> BoxMorph uses HybridCanvas by default instead of VectorCanvas, so I
>> added the instance method requiresVectorCanvas which returns true. That
>> eliminates the eror, but doesn't result in rendering anything. So it's not
>> clear to me what I'm missing in my Try3 class.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
>
> --
> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>

-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241215/e16648f2/attachment-0001.htm>


More information about the Cuis-dev mailing list