Intuition window goes OOP(ish) - Revision history

Molly at 18:29, 13 September 2017

2017-09-13T18:29:27Z

Molly: /* Step 2: Classify the window */ Code update. Forgot to initialize private variables and other steps use AnsiString type for FTitle.

2017-04-15T05:29:22Z

Step 2: Classify the window: Code update. Forgot to initialize private variables and other steps use AnsiString type for FTitle.

Molly: /* Step 5: Implement event handlers */ Update source-code

2017-04-01T18:29:45Z

Step 5: Implement event handlers: Update source-code

Molly: /* What's next ? */ update

2017-04-01T18:28:28Z

What's next ?: update

Molly: /* Step 5: Implement event handlers */ Update accompanied text

2017-04-01T18:25:40Z

Step 5: Implement event handlers: Update accompanied text

Molly: /* Implement message handlers */ Change title and correct some of the accompanied text

2017-04-01T18:14:23Z

Implement message handlers: Change title and correct some of the accompanied text

Molly: /* Step 4: Dispatching messages */ updated accompanied text

2017-04-01T18:10:14Z

Step 4: Dispatching messages: updated accompanied text

Molly: /* Step 4: Dispatching messages */ update sources (they were wrong for this step). Still need to modify accompanied writing to match

2017-04-01T17:04:40Z

Step 4: Dispatching messages: update sources (they were wrong for this step). Still need to modify accompanied writing to match

Molly: /* Dispatching messages */ change title

2017-04-01T17:01:37Z

Dispatching messages: change title

Molly: /* Step 3: Moving around message handling */ update source-code

2017-04-01T17:00:05Z

Step 3: Moving around message handling: update source-code

← Older revision		Revision as of 18:29, 13 September 2017
Line 1:		Line 1:
		+	[[Category:Examples]]
		+
	A long while ago, someone on the aros-exec forums suggested/asked to use some (more) OOP to create f.i. native Intuition Windows.		A long while ago, someone on the aros-exec forums suggested/asked to use some (more) OOP to create f.i. native Intuition Windows.

@@ Line 137: / Line 137: @@
      FWidth  : LongInt;
      FHeight : LongInt;
-     FTitle  : String;
+     FTitle  : AnsiString;
    protected
    public
@@ Line 178: / Line 178: @@
 begin
    Inherited;
 end;

@@ Line 786: / Line 786: @@
 <source lang="pascal">
-unit IntWinClass;
+unit Step5_IntWinClass;
 {$MODE OBJFPC}{$H+}
@@ Line 794: / Line 794: @@
 uses
    Intuition;
 type
@@ Line 986: / Line 987: @@
    if Assigned(FOnMouseButtons) then FOnMouseButtons(msg.Imsg);
 end;
 </source>
@@ Line 1,000: / Line 1,003: @@
 <source lang="pascal">
-program ClassWindow;
+program Step5_ClassWindow;
 {$MODE OBJFPC}{$H+}
 uses
-   IntWinClass, Exec, AGraphics, Intuition, InputEvent;
+   Step5_IntWinClass, Exec, AGraphics, Intuition, InputEvent;
 procedure print_text(rp: PRastPort; x: LongInt; y: LongInt; txt: PChar);
@@ Line 1,020: / Line 1,027: @@
 //* Window1 events
 //*-------------------------------------------------------------------------*/
 procedure DoMouseMove(const IMsg: PIntuiMessage);
@@ Line 1,040: / Line 1,046: @@
    end;
 end;
 procedure DoCloseWindow(var DoClose: boolean);

← Older revision		Revision as of 18:28, 1 April 2017
Line 1,091:		Line 1,091:
	* Properties such as Left and Height currently retrieve their values from private variables. This is plain wrong as the user can move the window around and resize it. None of the current properties are actually containing real live values. Several approaches can be taken to improve this situation, f.e. by retrieving the actual values or for example by also implementing and reacting on RESIZEWINDOW and MOVEWINDOW messages.		* Properties such as Left and Height currently retrieve their values from private variables. This is plain wrong as the user can move the window around and resize it. None of the current properties are actually containing real live values. Several approaches can be taken to improve this situation, f.e. by retrieving the actual values or for example by also implementing and reacting on RESIZEWINDOW and MOVEWINDOW messages.
	* The current implementation only takes care of a single window. Calling HandleMessages would only work for this one window (and further message handing would be stalled). In order to add support for multiple windows a 'global' message-loop would have to implemented using a single messageport (that is used for all windows). Note that in that case the creation of the window can not have it's IDCMP_xxx flags set on creation, but needs to be done with function ModifyIDCMP()		* The current implementation only takes care of a single window. Calling HandleMessages would only work for this one window (and further message handing would be stalled). In order to add support for multiple windows a 'global' message-loop would have to implemented using a single messageport (that is used for all windows). Note that in that case the creation of the window can not have it's IDCMP_xxx flags set on creation, but needs to be done with function ModifyIDCMP()
		+
		+	The example codes are also kindly provided by magorium and can be found [https://github.com/magorium/fpc-aros-wiki/tree/master/Topics/Intuition_Window_OOP here] (with an additional small bonus for those who are able to locate it).

@@ Line 781: / Line 781: @@
 == Step 5: Implement event handlers ==
-In our last step we would like to call the event handlers instead of our class actually performing actions so, we start doing so (yes, we need to shuffle a large portion of the code around again):
+For this step, we're going to implement support for event-handlers, instead of our class actually performing actions.
 <source lang="pascal">
@@ Line 985: / Line 987: @@
 end;
 </source>
 Now that the event handling is actually implemented we can make use of it in our main program.
@@ Line 1,068: / Line 1,079: @@
 end.
 </source>
 Depending on which events are assigned our class is acting as desired. You can leave those events that you are not interested in or add new ones inside the class.

@@ Line 725: / Line 725: @@
 </source>
-Looks difficult perhaps but, it actually isn't.
+The changes perhaps look difficult but, it actually isn't.
-First we needed to add a new structure TIntuitionMessageRec that follows the Free Pascal Dispatch message, and at the same time can hold our intuition message information.
+First we've added a new structure TIntuitionMessageRec, that is compatible with a Free Pascal Dispatch message, and at the same time is able to hold our intuition message information.
-Then we've defined 3 new event procedures that act as type-casts for the events. The events FOnCloseWindow, FOnMouseMove
+In order to be able to keep track whether or not our window is closed we defined a new private variable named Stopped.
-We override the DefaultHandler that is standard part of TObject so that we can give some feedback to the suer in case none of our message is intercepted correctly (and the default handler is invoked)
+Next thing we've added, are the 3 IDCMP message procedures. These get 'automatically' invoked by the dispatcher.
 Finally we adjust our HandleMessages method to call the TObject dispatcher.
-It might be a surprise, but there is nothing changed inside our main program. For the sake of completeness we post the code.
 <source lang="pascal">

@@ Line 519: / Line 519: @@
 <source lang="pascal">
-unit IntWinClass;
+unit Step4_IntWinClass;
 {$MODE OBJFPC}{$H+}
@@ Line 527: / Line 527: @@
 uses
    Intuition;
 type
@@ Line 535: / Line 536: @@
 type
    TIntuitionWindowClass = class
    private
@@ Line 548: / Line 545: @@
      FTitle   : AnsiString;
      FStopped : boolean;
    protected
      procedure MsgCloseWindow(var msg: TIntuitionMessageRec); Message IDCMP_CLOSEWINDOW;
      procedure MsgMouseMove(var msg: TIntuitionMessageRec); Message IDCMP_MOUSEMOVE;
      procedure MsgMouseButtons(var msg: TIntuitionMessageRec); Message IDCMP_MOUSEBUTTONS;
-   public // creator/destructor
+   public
      constructor Create;
      destructor  Destroy; override;
-   public // methods
+   public
      procedure Open;
      procedure Close;
      procedure HandleMessages;
      procedure DefaultHandler(var message); override;
-   public // properties
+   public
      property Left   : LongInt read FLeft   write FLeft;
      property Top    : LongInt read FTop    write FTop;
@@ Line 570: / Line 564: @@
      property Title  : String  read FTitle  write FTitle;
      property Handle : PWindow read FHandle;
    end;
@@ Line 644: / Line 634: @@
    then Intuition.CloseWindow(FHandle)
    else Error('Unable to Close Window because the handle is invalid');
 end;
@@ Line 691: / Line 690: @@
 procedure TIntuitionWindowClass.DefaultHandler(var message);
 begin
-   WriteLn('invoked default handler');
+   Writeln('invoked default handler');
 end;
 procedure TIntuitionWindowClass.MsgCloseWindow(var msg: TIntuitionMessageRec);
 begin
    WriteLn('IDCMP_CLOSEWINDOW message received');
+   FStopped := true;
 end;
 procedure TIntuitionWindowClass.MsgMouseMove(var msg: TIntuitionMessageRec);
 begin
    WriteLn('IDCMP_MOUSEMOVE message received');
+   WriteStr(buffer, 'Mouseposition: x=', msg.IMsg^.MouseX, ' y=', msg.IMsg^.MouseY, #0);
-   if assigned(FOnMouseMove) then FOnMouseMove(msg.IMsg);
+  print_text(FHandle^.RPort, 10, 30, @buffer[1]);
 end;
@@ Line 717: / Line 714: @@
 begin
    WriteLn('IDCMP_MOUSEBUTTONS message received');
-   if Assigned(FOnMouseButtons) then FOnMouseButtons(msg.Imsg);
+   case msg.IMsg^.Code of
 end;
 end.
 </source>
@@ Line 738: / Line 739: @@
 <source lang="pascal">
 {$MODE OBJFPC}{$H+}
 uses
-   IntWinClass, Exec, AGraphics, Intuition, InputEvent;
+   Step4_IntWinClass, Exec, AGraphics, Intuition, InputEvent;
 //*-------------------------------------------------------------------------*/
@@ Line 767: / Line 770: @@
    result := (0);
 end;
 begin

@@ Line 514: / Line 514: @@
 Easy enough, and things still work. A bit awkward perhaps, but it works (for this one window).
-== Dispatching messages ==
+== Step 4: Dispatching messages ==
 Here is where things become a bit more interesting, as we're going to add a (IDCMP) message dispatcher to our class.