"

 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.

"

Label subclass:#Button

	 instanceVariableNames:'activeLogo passiveLogo disabledLogo focusLogo onLevel offLevel

		disabledFgColor activeFgColor activeBgColor enteredFgColor

		enteredBgColor isReturnButton shadowForm lightForm formColor

		formShadowColor formLightColor edgeStyle halfShadowColor

		halfLightColor'

	 classVariableNames:'ReturnForm ReturnLightForm ReturnShadowForm DefaultFont

		DefaultActiveLevel DefaultPassiveLevel DefaultEdgeStyle

		DefaultBorderWidth DefaultForegroundColor DefaultBackgroundColor

		DefaultDisabledForegroundColor DefaultDisabledBackgroundColor

		DefaultEnteredForegroundColor DefaultEnteredBackgroundColor

		DefaultActiveForegroundColor DefaultActiveBackgroundColor

		DefaultReturnButtonHasImage DefaultReturnButtonHasBorder

		DefaultShadowColor DefaultLightColor DefaultHalfShadowColor

		DefaultHalfLightColor'

	 poolDictionaries:''

	 category:'Views-Interactors'

!

!Button class methodsFor:'documentation'!

actionBlocksVersusModelChanges 

"

    You may ask yourself, why ST/X supports two different ways

    to trigger a buttons action (also true for sliders, selectionInListViews,

    toggles etc.) and when to use which mechanism.

    There are two reasons:

	1) history - historically, ST/X used only actionBlocks

	   Basically, these provide the most general functionality

	   (you can of course send change-messages from those blocks)

	   Change-message notification was added later, to make porting

	   of existing applications easier.

	2) for many (simple) applications, it is often easier, to simply

	   define an action block. This is especially true, if the button

	   triggers some action (such as ok-/abort-buttons) and does NOT

	   change some models internal value.

	   (other smalltalks provide extra adapter-models for this,

	    in which you can set actionBlocks in much the same way).

    In general:

	use model-change-messages, iff multiple views are possibly open

	on the same domain model, and changes can occur from multiple

	places. Or if a change has to be forwarded to multiple other objects

	(possible not foreseen).

	For simplicity, better use actionBlocks for trigger-like actions

	(such as closing a view, ok/abort etc.) iff there is only a single

	entity which is interrested in that button press.

"

!

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.

"

!

documentation

"

    Buttons are Labels which do something when pressed/released.

    Since they inherit from Label, read the documentation on Labels to 

    see how color, layout, font, image or labelString are changed.

    Buttons (and also instances of subclasses, such as toggles, checkToggles

    and radioButtons) perform some action when pressed, and optionally when

    released. Due to historic reasons, ST/X buttons support two mechanisms:

    Actionblock operation:

      the button has an actionBlock (actually, it has two: a pressAction and

      a releaseAction) which is evaluated, when the button is pressed.

      The user of a button can set these action blocks via the #action:,

      #pressAction: or #releaseAction: messages.

    Model-View interaction:

      buttons with a model will send change-messages to the model and also react 

      to changes in the model.

      You have to define the buttons labelMessage and an aspectSymbol.

      When changed, the model should send 'self changed:<aspect>' if it wants the

      label to change and return a string from the labelSymbol-message.

      By default, the labelMsg is nil, therefore no update of the label is done.

      (this behavior is inherited from label, see documentation there)

      When pressed, the button sends a changeMessage to the model.

      If the changeMsg is for a one-argument message, the current

      press-state is passed as argument (i.e. true if pressed, false if released).

      By default, the change-Message is #value: (for ST-80 compatibility).

	button model:aModel.

	button aspect:aspectSymbol.

	button change:changeSymbol.

	button labelMessage:labelSymbol.

	model sends #changed:aspectSymbol

	---> button will redraw its label from value returned by model>>labelSymbol

	button changes state:

	---> button sends changeSymbol / changeSymbol:state to the model

      By default (as inherited), the labelMsg is nil; therefore, buttons

      do not try to aquire a new labelString from the model.

      If you want this behavior, you must set labelMsg and aspectMsg

      as appropriate.

    See examples.

    Instance variables:

      activeLogo              <StringOrImage> logo to show when active (pressed)

      passiveLogo             <StringOrImage> logo to show when passive (released)

					      default is nil for both, so the normal logo is used

					      (see superclass: Label)

      onLevel                 <Integer>       level when pressed (3D only) (default: depends on style)

      offLevel                <Integer>       level when released (3D only) (default: depends on style)

      disabledFgColor         <Color>         color used to draw logo when disabled (default: depends on style)

      activeFgColor           <Color>         color to draw logo when pressed (default: depends on style)

      activeBgColor           <Color>         bg color when pressed (default: depends on style)

      enteredFgColor          <Color>         fg color to draw logo when cursor entered (default: depends on style)

      enteredBgColor          <Color>         bg color when cursor entered (default: depends on style)

      isReturnButton          <Boolean>       true if this button is also activated by the

					      return key - if true, it will draw a return-bitmap 

					      in addition to the logo (default: false)

      shadowForm              <Form>          form to display in addition to buttons label (returnbutton only)

      lightForm               <Form>          light part of shadowForm (returnbutton only)

      formColor               <Color>         color to draw form with (returnbutton only)

      formShadowColor         <Color>         color for shadowing the form (3D only & return)

      formLightColor          <Color>         color for lighting the form (3D only)

    styleSheet parameters:

      buttonActiveLevel       <Integer>       level when on (ignored in 2D styles)

      buttonPassiveLevel      <Integer>       level when off (ignored in 2D styles)

      buttonBorderWidth       <Integer>       default borderwidth

      buttonEdgeStyle         <Symbol>        style of edges (currently #soft or nil)

      buttonFont              <Font>          font to use for textual labels

      buttonForegroundColor   <Color>         color to draw foreground pixels (i.e. the string)

      buttonBackgroundColor   <Color>         color to draw background pixels

      buttonDisabledForegroundColor <Color>   same when disabled

      buttonDisabledBackgroundColor <Color>   same when disabled

      buttonEnteredForegroundColor  <Color>   same when mouse pointer is in

      buttonEnteredBackgroundColor  <Color>   same when mouse pointer is in

      buttonActiveForegroundColor   <Color>   same when button is active

      buttonActiveBackgroundColor   <Color>   same when button is active

      buttonShadowColor             <Color>   shadow color for edgaes (ignored in 2D styles)

      buttonLightColor              <Color>   light color for edgaes (ignored in 2D styles)

      buttonHalfShadowColor         <Color>   half shadow color; for soft edges only

      buttonHalfLightColor          <Color>   half light color; for soft edges only

      buttonReturnButtonHasImage    <Boolean> if true, return-buttons draw a return-key image

      buttonReturnButtonHasBorder   <Boolean> if true, return-buttons show a border

    See also: Toggle  CheckToggle  CheckBox

"

!

examples 

"

    You dont have to normally care for all the internals 

    (they allow many variations though). The typical use is:

	b := Button label:'some logo' in:aView.

	b action:[ .. things to do, when pressed ... ]

    for buttons with a string-label,

    and:

	b := Button label:someImage in:aView.

	b action:[ .. things to do, when pressed ... ]

    for buttons with a bitmap label.

    Of course, you can also setup things the ST-80 way, in first

    creating the button and later add it to some superview:

	b := Button new.

	b label:someImage.

	b action:[ .. things to do, when pressed ... ]

	...

	aSuperView add:b in:<frameRectangle>.

    Although you can specify a lot in a button,

    you should use the defaults in most applications.

    As you specify more things in your program, 

    the styleSheet settings are more and more ignored.

    Also, even though it might look fancy, colorful

    button panels are usually not a good GUI design;

    they will attract the users attention - possibly to things

    which are not worth it.

    Finally, if you use fancy colors, always thing of those poor users

    without color displays - the styleSheet allows those people to adjust things,

    while hard-coded colors cannot be fixed without changing the code.

    a button with default settings 

    (you may want to try it with different viewStyle settings in effect):

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b label:'hello'.

      b action:[Transcript flash].

      top open.

    there is also a combined instance creation message:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button label:'hello' action:[Transcript flash] in:top.

      top open.

    a return button

    (in dialogs, you should setup things to have the return-key perform

     the ok action, and mark the corresponding button as being a returnButton):

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button label:'hello' action:[Transcript flash] in:top.

      b beReturnButton.

      top open.

    enabling/disabling buttons via explicit messages:

      |top panel b1 b2 b3|

      top := StandardSystemView new.

      top extent:300@100.

      panel := HorizontalPanelView origin:0.0@0.0 corner:1.0@1.0 in:top.

      b1 := Button label:'enable'  action:[b3 enable] in:panel.

      b2 := Button label:'disable' action:[b3 disable] in:panel.

      b3 := Button label:'flash'   action:[Transcript flash] in:panel.

      top open.

    enabling/disabling buttons via implicit value change of a valueHolder:

      |top panel ena t b1 b2 b3 check|

      top := StandardSystemView new.

      top extent:300@100.

      panel := HorizontalPanelView origin:0.0 @ 0.0 corner:1.0 @ 1.0 in:top.

      ena := false asValue.

      t := Toggle label:'enable' in:panel.

      t model:ena.

      b1 := Button label:'button1' in:panel.

      b1 controller enableChannel:ena.

      b2 := Button label:'button2' in:panel.

      b2 controller enableChannel:ena.

      b3 := Button label:'button3' in:panel.

      b3 controller enableChannel:ena.

      top open.

      check := CheckBox model:ena.

      check label:'also enable'.

      check extent:(check preferredExtent + (5@5)).

      check open

    changing colors:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button label:'hello' in:top.

      b action:[Transcript flash].

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      top open.

    changing more colors:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button label:'hello' in:top.

      b action:[Transcript flash].

      b enteredForegroundColor:(Color red).

      b enteredBackgroundColor:(b backgroundColor).

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      top open.

    button with an image and different colors:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b label:(Image fromFile:'bitmaps/SBrowser.xbm').

      b action:[Transcript flash].

      b enteredForegroundColor:(Color green darkened).

      b enteredBackgroundColor:(b backgroundColor).

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      top open.

    changing the image when pressed:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b passiveLogo:(Image fromFile:'bitmaps/SBrowser.xbm').

      b activeLogo:(Image fromFile:'bitmaps/CBrowser.xbm').

      b action:[Transcript flash].

      b enteredForegroundColor:(Color red).

      b enteredBackgroundColor:(b backgroundColor).

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      top open.

    well, even that is possible (but you should NEVER do it):

    (notice the changing size and the resulting problem when

     pressed near the bottom, since the button thinks the pointer

     leaves the view and changes back and forth ...)

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b passiveLogo:(Image fromFile:'bitmaps/SmalltalkX.xbm').

      b activeLogo:#('start') asStringCollection.

      b action:[Transcript flash].

      b enteredForegroundColor:(Color red).

      b enteredBackgroundColor:(b backgroundColor).

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      top open.

    same as above, with frozen size to avoid the problem. 

    (make certain, that the size is ok for all possible logos):

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b passiveLogo:(Image fromFile:'bitmaps/SmalltalkX.xbm').

      b activeLogo:#('go') asStringCollection.

      b action:[Transcript flash].

      b enteredForegroundColor:(Color red).

      b enteredBackgroundColor:(b backgroundColor).

      b activeForegroundColor:(Color white).

      b activeBackgroundColor:(Color red).

      b sizeFixed:true.

      top open.

    more playing with colors:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b logo:(Image fromFile:'bitmaps/SmalltalkX.xbm').

      b action:[Transcript flash].

      b foregroundColor:(Color red:0 green:80 blue:20) darkened.

      b backgroundColor:(Color grey:10).

      b enteredForegroundColor:(Color red).

      b activeForegroundColor:(Color red).

      b activeBackgroundColor:(Color grey:10).

      top open.

    more playing with colors:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button in:top.

      b logo:(Image fromFile:'bitmaps/SmalltalkX.xbm').

      b action:[Transcript flash].

      b foregroundColor:(Color red:0 green:80 blue:20) darkened.

      b backgroundColor:(Color grey:10).

      b enteredBackgroundColor:(Color grey:20).

      b activeForegroundColor:(Color red).

      b activeBackgroundColor:(Color grey:20).

      top open.

    fire on press (buttons in scrollbars do this, while normal buttons

    fire on release).

    To give the user a chance to change her mind

    and leave the button without action, you should not change the default 

    behavior and NOT use triggerOnDown-buttons in most applications:

      |top b|

      top := StandardSystemView new.

      top extent:100@100.

      b := Button label:'hello' in:top.

      b controller beTriggerOnDown.

      b action:[Transcript flash].

      top open.

    To implement fun buttons (for games, show-demos etc.), you can

    access all internal parameters (and not take the viewStyle defaults)

    as in:

	|b granite light shadow|

	b := Button label:'a nice one ?'.

	granite := Image fromFile:'bitmaps/granite_small.tiff'.

	light := granite lightened.

	shadow := granite darkened darkened.

	b backgroundColor:granite.

	b foregroundColor:Color white.

	b shadowColor:shadow.

	b lightColor:light.

	b enteredBackgroundColor:light.

	b enteredForegroundColor:Color black.

	b activeLevel:-3; passiveLevel:5.

	b extent:(200 @ 50).

	b open

    However, in your application, you may want to read those bitmaps only once

    during startup and cache them for later reuse in some class variable

    (reading, lightning & darkening of images is a bit slow)

    ST/X Buttons allow simulation of the ST-80 MVC way of interacting.

    To do so, instead (or in addition) to defining actionBlocks, set the