[Cuis-dev] minimum requirements for a BoxMorph subclass

[Juan Vuletich]

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 <mailto: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 <mailto: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 ofBoxMorph. I know I need to implement
>>>         thedrawOn:instance method. And I believe that depending on
>>>         how I implement that, I need to implement
>>>         therequiresVectorCanvasmethod 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 Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241215/708a7f2b/attachment-0001.htm>