Finding and manipulating a menu

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Finding and manipulating a menu

Steve Cline
Assuming a suitable subclass of ApplicationWindow with an InputField named #InputField1

this works but seems horribly wrong - what is a better way to reach the (default) menu of #InputField1?

setUp

        window := SwcTestWindow1 open window.
        window unmap

test1

        | i m |
        self assert: window model class = SwcTestWindow1.
        i := window model builder componentAt: #InputField1.
        m := i component component component controller menuHolder value .
        self deny: i class = InputFieldView.
        self assert: m class = Menu.
Reply | Threaded
Open this post in threaded view
|

Re: Finding and manipulating a menu

Holger Guhl
You'll like this one

| aWindow anApplicationModel |
aWindow :=<an arbitrary window>.
anApplicationModel := aWindow model.
aController := anApplicationModel controllerAt: #InputField1.
aMenu := aController menu.

The verbose code helps to understand the steps. The compact form for your test example is simply

    m := (window model controllerAt: #InputField1) menu

The best recipe to find better code is learning from VisualWorks. You want to access a certain GUI
element. Using #componentAt: is straightforward. The first thing I do is checking senders in the
hierarchy of the implementor. In our example its UIBuilder which implements #componentAt:. If this
does not help for good ideas, I check the owner of the object that implements the basic service. In
our example we would find ApplicationModel #wrapperAt:. Your first piece of code would become smaller

    i := window model wrapperAt: #InputField1.

instead of

    i := window model builder componentAt: #InputField1.

With the hierarchy senders approach you'll find ApplicationModel #widgetAt: and then #controllerAt:
which is the true winner method. It abstracts all the access through the component hierarchy and
returns the desired Controller in an elegant way. In the same way you'll find ControllerWithMenu
#menu (as sender of #menuHolder) which abstracts the menu access.
Some might ask "so much search for so few gains?". But half the life in VisualWorks development is
learning how to do it right and create reusable, well maintainable code. In the long run you'll
benefit from systematically learning.

Cheers
Holger

Am 22.02.2013 16:39, schrieb Steve Cline:

> Assuming a suitable subclass of ApplicationWindow with an InputField named
> #InputField1
>
> this works but seems horribly wrong - what is a better way to reach the
> (default) menu of #InputField1?
>
> setUp
>
> window := SwcTestWindow1 open window.
> window unmap
>
> test1
>
> | i m |
> self assert: window model class = SwcTestWindow1.
> i := window model builder componentAt: #InputField1.
> m := i component component component controller menuHolder value .
> self deny: i class = InputFieldView.
> self assert: m class = Menu.
>
>
>
> --
> View this message in context: http://forum.world.st/Finding-and-manipulating-a-menu-tp4671497.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>


Holger Guhl
--
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc