eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'View':

Home

Documentation
www.exept.de
Everywhere
for:
 [back]

Class: View

Inheritance:

   Object
   |
   +--GraphicsMedium
      |
      +--DisplaySurface
         |
         +--SimpleView
            |
            +--View
               |
               +--ActiveHelpView
               |
               +--ApplicationSubView
               |
               +--BarChartWidget
               |
               +--CharacterSetView
               |
               +--ChartDescription
               |
               +--CodeCompletionHelpView
               |
               +--ComboView
               |
               +--CompositeView
               |
               +--DSVColumnView
               |
               +--DigitalLedDisplay
               |
               +--DisplayObjectView
               |
               +--EventMonitor::EventMonitorView
               |
               +--ExtendedComboBox
               |
               +--GraphColumnView
               |
               +--HTMLDocumentFrame
               |
               +--ImageView
               |
               +--Label
               |
               +--LabelledEnterField
               |
               +--ListModelView
               |
               +--ListView
               |
               +--MemoryMonitorView
               |
               +--MenuPanel
               |
               +--MeterClackCounter
               |
               +--MeterWidget
               |
               +--NoteBookView
               |
               +--ObjectView
               |
               +--PieChartWidget
               |
               +--PluggableDropView
               |
               +--ProgressIndicator
               |
               +--PullDownMenu
               |
               +--Scroller
               |
               +--SimpleFunctionGraphView
               |
               +--ThumbWheel
               |
               +--TopView
               |
               +--TransparentBox
               |
               +--UpDownButton
               |
               +--V::GraphPane
               |
               +--VUMeter
Package:
stx:libview
Category:
Views-Basic
Version:
rev: 1.105 date: 2023/10/26 09:59:10
user: stefan
file: View.st directory: libview
module: stx stc-classLibrary: libview

Description:


this class adds provisions for views which show or work on a model.
This functionality used to be in View, but has been extracted into SimpleView and
this new View class, to take some of the stuff out of views which do not need
this functionality (i.e. all views which do only geometry management).
Instances of View are seldom used, most views in the system inherit 
from this class. 

[Instance variables:]
    model           <nil | any>         the model (if any)

    aspectMsg       <nil | Symbol>      the aspect; typically
                                        dependentViews react on changes
                                        of this aspect and update their contents.

    changeMsg       <nil | Symbol>      the changeMessage; typically
                                        dependentViews send this message to
                                        the model to tell it about changes.

    menuMsg         <nil | Symbol>      the menuMessage; typically
                                        dependentViews send this message to
                                        the model to ask for a popup menu.


    menuHolder      <any>               who has a menu 
                                        (default: nil i.e. model has menu)

    menuPerformer   <any>               who performs menu actions
                                        (default: nil i.e. model has menu)

    


copyright
COPYRIGHT (c) 1989 by Claus Gittinger
             All Rights Reserved

This software is furnished under a license and may be used
only in accordance with the terms of that license and with the
inclusion of the above copyright notice.   This software may not
be provided or otherwise made available to, or used by, any
other person.  No title to or ownership of the software is
hereby transferred.

Class protocol:

defaults
o  defaultAspectMessage
subclasses which by default do NOT want to be informed about changed
models should redefine this to return nil

o  defaultChangeMessage
subclasses which by default do NOT want to inform the model
should redefine this to return nil

o  defaultMenuMessage
subclasses which by default do NOT want to send menu messages
should return nil

instance creation
o  on: aModel aspect: aspectMsg
st-80 style view creation: create a new view, set its model
and selectors for aspect

o  on: aModel aspect: aspectMsg change: changeMsg
st-80 style view creation: create a new view, set its model
and selectors for aspect and change

o  on: aModel aspect: aspectMsg change: changeMsg menu: menuMsg
st-80 style view creation: create a new view, set its model
and selectors for aspect, change and menu

o  on: aModel aspect: aspectMsg menu: menuMsg
st-80 style view creation: create a new view, set its model
and selectors for aspect and menu

Instance protocol:

accessing-bg & border
o  allViewBackground: aColorOrImageOrForm if: condition
set the viewBackground to aColorOrImageOrForm, a color, image or form,
in myself and recursively in all of my subviews.
However, if I have a backgroundChannel, don't change my own bg.

accessing-channels
o  backgroundChannel
return a valueHolder for background color

o  backgroundChannel: aValueHolder
set the backgroundChannel - a valueHolder holding a color

o  enableChannel
return a valueHolder for enable/disable

o  enableChannel: aValueHolder
set the valueHolder, which holds the enable boolean value

o  foregroundChannel
return a valueHolder for foreground color

o  foregroundChannel: aValueHolder
set the foregroundChannel - a valueHolder holding a color

accessing-menus
o  defaultMenuPerformer
the stuff below tries to make for a reasonable
default, in case the menuPerformer was NOT set explicitely
(you should not depend on this in your application)

o  menuHolder
who has the menu ?
If no explicit menuHolder was defined, its the model if I have one.
Otherwise, its the menuHolder (if nonNil) or mySelf.
The menuHolder is supposed to return a popUpMenu when asked via the
menuMessage.

o  menuHolder: anObject
change the one that provides the menu (via menuMsg).
Unless already set, the menuMessage is set to #value
(i.e. the menuHolder can be a valueHolder or block or constant)

o  menuHolder: anObject menuMessage: aSelector
change the one that provides the menu and the message to get it.

o  menuMessage
Return the symbol sent to the model to acquire the menu

o  menuMessage: aSymbol
ST-80 style menus: If a view's menuSymbol is nonNil, it
will send it to its model when the middleButton is pressed.
That method should return nil or the menu to be shown.
This is useful for very dynamic menus, where it does not
make sense to define an initial menu.
This is the same as #menu: which was added for ST-80 compatibility.

o  menuPerformer
who should perform the menu actions?
If no menuPerformer was defined, it is the model if I have one.
Otherwise it is the menuPerformer (if nonNil), or myself.
The menuPerformer gets messages from the menu

o  menuPerformer: anObject
change the one that does the menu actions.
See the comment in SimpleView>>activateMenu on who gets the menu's
message.

Usage example(s): 

     |top textV plug|

     plug := Plug new.
     plug respondTo:#textMenu
               with:[ |m|
                        m := PopUpMenu
                                  labels:#('copy' 'foo' '-' 'others')
                                  selectors:#(copySelection foo nil others).
                        m subMenuAt:#others
                                put:(PopUpMenu 
                                        labels:#('bar' 'goto')
                                        selectors:#(bar gotoLine))        
                    ].

     top := StandardSystemView new.
     top extent:300@300.

     textV := TextView origin:0.0@0.0 corner:1.0@1.0 in:top.
     textV menuHolder:plug; menuMessage:#textMenu; menuPerformer:plug.
     textV contents:'hello world'.
     top open.

o  performer: anObject
same as #menuPerformer - ST80 compatibility

accessing-mvc
o  addModelInterfaceTo: aDictionary
this adds entries for all messages sent to my model
to aDictionary

o  aspect
Return the aspect used with changes from/to the model

o  aspect: aspectSymbol
ST-80 style updating: If a view's aspectSymbol is nonNil,
it will respond to changes of this aspect from the model.
Alias for aspectMessage: for ST-80 compatibility.

o  aspectMessage
Return the aspect used with changes from/to the model

o  aspectMessage: aspectSymbol
ST-80 style updating: If a view's aspectSymbol is nonNil,
it will respond to changes of this aspect from the model.

o  change: changeSymbol
ST-80 style change notification: If a view's changeSymbol is nonNil,
it will send it to its model when something changes.
Alias for changeMessage: for ST-80 compatibility.

o  changeMessage
Return the symbol sent to the model if nonNil when something changes.

o  changeMessage: aSymbol
ST-80 style change notification: If a view's changeSymbol is nonNil,
it will send it to its model when something changes.
This is the same as change: which was added for ST-80 compatibility.

o  controller: aController
set the controller

o  menu: menuSymbol
ST-80 style menus: If a view's menuSymbol is nonNil, it
will send it to its model when the middleButton is pressed.
That method should return nil or the menu to be shown.
This is useful for very dynamic menus, where it does not
make sense to define an initial menu.
Alias for #menuMessage:, for ST-80 compatibility.

o  model
return the model, for non-MVC views,
this is nil or the receiver

o  model: aModel
Set the model.
Here, if I am my own menuPerformer/menuHolder,
set the menuHolder and menuPerformer to the model.
This is a compatibility kludge,
since typically, ST-80 code expects the model to provide a menu
and perform it. If the model does not support a menu message,
it will be forwarded to the view.
Those apps which want the view to provide the (default) menu have to reset
this by sending #menuHolder: message (again)

o  modelInterface
this returns a dictionary of messages sent to my model.
It can be used for builders and wrappers to get information
about the messages sent to my model.
The returned dictionary contains one entry for each get-Msg,
and the receiver will implement corresponding messages (with a colon)
to set the message symbol.

Usage example(s): 

     Button new modelInterface
     Label new modelInterface

Usage example(s): 

     does the view support setting the menuMessage ?

     SelectionInListView new modelInterface includesKey:#menuMessage

o  on: aModel aspect: aspectSymbol
ST-80 compatibility: set model and aspect
messages - needs a view which uses these

o  on: aModel aspect: aspectSymbol change: changeSymbol
ST-80 compatibility: set model, aspect and change
messages - needs a view which uses these

o  on: aModel aspect: aspectSymbol change: changeSymbol menu: menuSymbol
ST-80 compatibility: set model, aspect, change and menu
messages - needs a view which uses these

o  on: aModel aspect: aspectSymbol menu: menuSymbol
ST-80 compatibility: set model, aspect and menu
messages - needs a view which uses these

o  sendChangeMessage: aSelector with: arg
tell the model about a change

o  sendChangeMessageWith: arg
tell the model about a change

change & update
o  update: something with: aParameter from: changedObject
(comment from inherited method)
an update request

o  updateFromModel
to be redefined in subclasses

event handling
o  backgroundColorChanged
called to update the background color

o  enableStateChanged
called to update enable/disable state

o  foregroundColorChanged
called to update the foreground color

focus handling
o  wantsFocusWithButtonPress
views which do not like to take the keyboard focus
with buttonPress can do so by redefining this
to return false

initialization & release
o  initialize
must be called if redefined

o  release
(comment from inherited method)
remove all dependencies from the receiver

redrawing
o  redraw
redraw myself
if there is a model, this one shall redraw itself,
otherwise we cannot do much here - has to be redefined in subclasses

Examples:


a subView in a topView: 
    |top v|

    top := StandardSystemView new.
    v := View new.
    v origin:0.25 @ 0.25 corner:0.75 @ 0.75.
    top addSubView:v.
    top open
the same, a bit more compact: 
    |top v|

    top := StandardSystemView new.
    v := View origin:0.25 @ 0.25 corner:0.75 @ 0.75 in:top.
    top open
menuHolder 
    |top mh|

    mh := (PopUpMenu itemList:#( ('foo' foo) (#'bar' bar)) resources:nil) asValue.

    top := StandardSystemView extent:200@200.
    top menuHolder:mh.
    top open
menuHolder 
    |top mh|

    mh := (PopUpMenu itemList:#( ('foo' foo) (#'bar' bar)) resources:nil) asValue.
    [
        Delay waitForSeconds:5.
        mh value: (PopUpMenu itemList:#( ('waboo' foo) (#'baz' bar)) resources:nil)
    ] fork.

    top := StandardSystemView extent:200@200.
    top menuHolder:mh.
    top open

ST/X 7.7.0.0; WebServer 1.702 at 20f6060372b9.unknown:8081; Tue, 03 Dec 2024 17:20:05 GMT