Diary of an Amiga fanatic

Tag Archives: ReAction

I knew I had not done anything on the File Manager for some time but that the last post was almost a year ago even surprised me. That is probably also the last time I did any programming on it. I even had to read back to see what I was up to at that moment. I decided to continue on Aros using Zune which is an object-oriented GUI toolkit. It is nearly a clone (at both API and Look&Feel level) of MUI, a well-known Amiga shareware product by Stefan Stuntz. I am going to switch back to OS4.1 using ReAction. At the time I was still programming using ReAction the wrong way. Since I am doing it the correct way with my Redhouse Editor project I decided to ditch all the current code and use the Redhouse Editor code for which I program ReAction the correct way. So what I have at the moment is a window that is being opened and already has a small menu system in place.

Redhouse File Manager - Starting Window

The above Window is what I have at the moment. Simple but proper ReAction code so a good start if you ask me. What I plant to do next is to play around a bit with the layout. Getting myself a bit familiar with the Layout Class to make it look like a bit more like a File Manager. When you talk about a File Manager look you instantly think about the two column look like you can see below from Directory Opus.

Directory Opus 4.18.29

For this I will have to use the List Browser Class. I remember how difficult it was last time I tried to have a go at it. I better be prepared this time and get the job done.

One of my plans for this year was to start programming something on OS4.1 and actually finish it with the purpose if documenting every step so people could learn something from it. I tried it with the Redhouse File Manager but at the moment I am not as excited about it as I was before so I want to start with something new and exciting. I will continue with the Redhouse File Manager at some stage but for now I decided on something new. I decided to start programming, at first, a simple editor.

Amiga EditorAbove you can see the start of my Amiga Editor project. Just a simple window with the title “Amiga Editor”. I started a series of articles called “ReAction – Opening a Window” before and with three published already and one pending I decided to take them off-line and use them for this project. I will write about every step I take and provide the code and explain it as well. This will really benefit the people that want to program on OS4.x.

Amiga Editor - Window infoThe above picture shows the lines of code that will setup the window that you see in the beginning of this post. It’s not difficult to understand and even without any background info on ReAction/Intuition you somehow can make some sense out of this. The biggest hurdle will be to understand ReAction/Intuition in order to get your stuff working. Over time you will understand more parts of it and things will suddenly make sense but it can be very frustrating at times. It is not uncommon to use code in your program that you don’t fully understand but it gets the job done. But overtime you start to understand it, major ego boost, which is one of the best feelings you can have as a programmer. Next time I will discuss some snippets of code.

It was going to be a series of 4 articles explaining how to open a ReAction window in C on OS4.x. I had 3 released already with the fourth on pending. Instead of writing the fourth article I decided to take the three articles off-line and use them in my new Amiga Editor project.

Since Aros uses Zune which is a MUI clone I had to get myself familiar with MUI. I know a bit about ReAction which is being used by OS4.x which does come in handy when using MUI. Since I knew nothing about MUI I probably will use up most of the coming time on getting myself familiar with it.

As you might know I prefer opening my own libraries instead of having it done by the compiler. I know it is extra work but it will teach you more about libraries. You can use libraries without even having to open and close them or even worry about the error handling (check if you manage to open them or not and what to do). I learned a lot from doing it myself and that kind of knowledge can be useful for other coding parts as well.  When it comes to MUI we have to open the MUI library. Below are the code fragments we need to get this done. First the includes, setting up the pointer and finally opening the library.

#include <libraries/mui.h>
#include <proto/muimaster.h>

struct MUIMasterBase *MUIMasterBase;

MUIMasterBase = (struct MUIMasterBase *)OpenLibrary(“muimaster.library”, 39);

But when I compile it I get the error “Conflicting types for MUI MasterBase”. I am not sure but to me it seems to be the <proto/muimaster.h> include that is the culprit. I posted about this on the Aros-Exec forums in the hope of getting this resolved soon. I am taking a short break from it so maybe the solution might come to me.

I left my Redhouse file manager project on hold for some time already. Started out on OS4.x I thought it was a good time to continue with it on Aros for now. I am getting myself familiar with Aros so what better way better than to involve Aros in to it. One thing I really miss, and “highlighted” already several times is a editor that supports C syntax highlights. Being used to CodeBench and Cubic IDE it is a big must for me. I really hope someone will create this. For now I am using the NoWinED editor. When the code is not that large yet it is fine but once it grows you just loose that great ability of oversight.


Programming on Aros is somewhat different compared to OS4.x. The approach to libraries and the GUI toolkit of choice are different. When it comes to libraries we will switch back to the old classic way of opening them. I actually like this since it is true to the classic way of doing things and since I invested a lot of time in Amiga OS libraries the classic way and new OS4.x way it is not really a problem to switch back to this way of opening libraries.

Instead of ReAction which is used on OS4.x we are using Zune on Aros. Zune is an object-oriented GUI toolkit. It is nearly a clone (at both API and Look&Feel level) of MUI, a well-known Amiga shareware product by Stefan Stuntz. I have no experience with MUI so for me this will be a bit of a hurdle. I always got the idea that there are more and better MUI classes one can use giving you a more easier way of getting your code done. So far I already have small example of a window that is being displayed with some control code that will close it again. That will be the basis from which I will continue. First I will start with a split window look which is the basis for each Amiga file manager if you ask me.


The decision has been made; I am going to purchase OS4.1 for my A1SE! The main reason for this is that when I am programming some stuff does not work the way it should be and what works in one example does not in the other. I am getting some real strange results which I am contributing to the OS4 Pre-Release I am using. For example with some ReAction stuff I had to use code that is not really recommended any more to get it to work. When I follow the guideline for ReAction it just does not work and gives me the Grim Reaper. Since I was going to start with ReAction for The Bucket Programming Corner I really did not want to teach you all the incorrect ways of programming. Plus there are so many other benefits when it comes to Amiga OS4.1 and the updates. The plan is to purchase it within the next two weeks or so.

I really have to DeC myself at the moment since I started to program in Amos again. I need start thinking basic again instead of C. Work on the disk magazine is going rather slow at the moment. On top of that I also want to do a few tutorials on Amos. It is really strange but as soon as you start Amos you start getting these happy feelings from the past. Just seeing some code on the screen makes me smile. Amos still has this great nostalgic wow factor which says something about Amos. This week it is a short column but I felt like sharing my OS4.1 purchase urge. Till next time!

Finally I managed to fix the crashing issue when another issue surfaced.

After solving this one I ran into another one that seems to be even worse. My window displays but when I click to close it nothing happens.

After spending a lot of time on it and not getting really any further I decided to move back to my previous “older” code. I was following Trixie’s article over at OS4Coding.net regarding the proper way of programming with ReAction. One of part of the proper way of using ReAction was:

Instead of using OpenLibrary() to open ReAction Classes we should use OpenClass() to open the ReAction Classes. Besides returning the class library base (which we store in WindowBase) it will also return something called the class pointer.

Instead of using the OpenClass() function I am now (again) using OpenLibrary() and GetInterface() to open ReAction Classes. You might remember that in a previous article I was talking about how can you check if the class pointer is also being opened when you use the OpenClass() function.

My question about this is that when we check if we opened the Window class do we also need to check if we got the pointer and if so how? Or can we assume that if we succeed in opening the Window class we also have successfully got the class pointer?

Maybe it did not really open (class pointer) which is the reason my code for closing the window is not working. Besides this part there is another part for which I switched back to my “older” code. Don’t use RA_OpenWindow()  to open a window but instead use  WM_OPEN which would look something like this:

window = (struct Window *)IIntuition->IDoMethod(objects[OID_WINDOW], WM_OPEN, NULL);

I moved back to using RA_OpenWindow() which would look something like this:

window = RA_OpenWindow (winobj);

Just ignore all the parts of the code it is just for reference. The third and last part I moved away from is WM_HANDLEINPUT. This is part of the code that will loop (keeping our window open till we do something like clicking something) and would look like something like this:

while ( (result = IIntuition->IDoMethod(winObj, WM_HANDLEINPUT, &code)) != WMHI_LASTMSG )


I moved back to using the RA_HandleInput() macro which would look something like this:

while ( (result = RA_HandleInput(winObj, &code)))


As a result my code works now and clicking on the close button actually closes my window. I could not keep spending time on this issue so I had to move back in order for my code to work and move on. At a later stage I might do some further testing so that eventually I can move back. If you go through the ReAction examples for OS4 you do get rather confused since every example seems to differ from the other. But since I now got it to work I am moving on to the next part which is the layout. At first I want to start with having buttons on top of the window. See example screenshot below which is from the utility Filer from Bjorn Hagstrom.

Filer 53.27 from Bjorn Hagstrom

I will discuss the layout and buttons in the next article. Till next time!

I did manage to locate the bug that made my code crash. If you remember my previous posting you know how much that bug haunted me. The declaration “Object *winObj” was the one that caused it. By changing it to  “Object *winObj = NULL” I solved it. If you follow The Bucket Programming Corner you might remember me talking about setting pointers to NULL. I see a lot of ReAction examples which do not set this to NULL. Since it solved it for me and I can’t find any other info on this I will just leave the statement as it is.

Home free right? Not exactly. After solving this one I ran into another one that seems to be even worse. My window displays but when I click to close it nothing happens. After running some tests it seems the code never reaches the part that checks if the window needs to be closed. After staring at it till my eyes hurt and compare it to several examples I still have not found the bug and I decided I need some outside help. So I posted my problem over at OS4Coding for some outside help. Let’s hope I find it soon so I can continue.

In the previous article I mentioned how you can skip all that opening and checking of libraries and interfaces. Let’s say we want to display a window displaying some text. Instead of writing the code I just write that we are going to open a window and display some text at the correct place in our code. Let’s have a look at the code.

01 #include <stdio.h>
02 #include <intuition/intuition.h>
04 #include <proto/intuition.h>
05 #include <proto/exec.h>
07 struct Library *IntuitionBase = NULL;
09 struct IntuitionIFace *IIntuition = NULL;
11  int main (void)
13 {
15  /* Opening the Intuition Library */
16  IntuitionBase = IExec->OpenLibrary(“intuition.library”, 50L);
18   /* Did we manage to open the Intuition Library? */
19   if (IntuitionBase != NULL)
20   {
22     printf (“We opened the Intuition Library!!\n”);
24     /* Open the Intuition Interface */
25     IIntuition = (struct IntuitionIFace *) IExec->GetInterface (IntuitionBase, “main”, 1, NULL);
27     /* Did we get the Intuition Interface? */
28      if (IIntuition != NULL)
29      {
31        printf (“We did get the Intuition Interface!!\n”);

32        — Display a small window with some text —

33       /* If the Intuition Library Interface is open, close it */

34       IExec->DropInterface((struct Interface *)IIntuition);
35       }
37     /* We could not open the Intuition Library Interface */
38     else
39    {
41    printf (“Unable to open the Intuition Library Interface!\n”);
42    }
44   /* If the Intuition Library is open, close it */
45   IExec->CloseLibrary(IntuitionBase);
46   }
48     /* We could not open the Intuition Library */
49    else
50   {
52  printf (“Unable to open the Intuition Library!\n”);
53  }
55 return 0;
56 }

The code is the same as in the previous article with the exception of line 32 which mentions our window that will display some text. Now we are going to rewrite the code leaving all the opening checking of libraries and interfaces out.

01 #include <stdio.h>
02 #include <intuition/intuition.h>
04 #include <proto/intuition.h>
05 #include <proto/exec.h>
07 struct Library *IntuitionBase = NULL;
09 struct IntuitionIFace *IIntuition = NULL;
11  int main (void)
13 {
15        — Display a small window with some text —
17 return 0;
18 }

Wow! What a difference, right? You might ask yourself how will this work? Skipping the checking if the libraries and interfaces if they are opened successfully might work but we can’t use the functions without opening the libraries and interfaces, right? Correct. The way this is going to work is how we will compile this code. With our previous example we compiled it with  typing “gcc openlibraryos4.c”. For our new example to work we are going to add something to this. To compile this example successfully we type  typing “gcc openlibraryos4.c -lauto”. By adding “-lauto” we are going to make use of the libauto library who can automatically open a number of system libraries and also set up their interface pointers.

I always did everything myself till recently when I started to use libauto. But just a short while ago I found out it is not the best way to go. If you read Trixie’s article Recommended Practice in OS4 ReAction Programming at OS4Coding he is talking about not using libauto.

2.3 The Autoinit
Quite a few ReAction examples are linked agains libauto, which performs automatic initialization of system libraries, including ReAction classes. The autoinit is comfortable in that it saves time and makes the code shorter. However, you should not rely on libauto in developing your own software. First, you have much better control over things when opening the resources yourself. Second, libauto opens ReAction classes using OpenLibrary(), which is another Don’t to be mentioned:

2.4 OpenLibrary() for classes
ReAction classes are implemented as system libraries so traditionally they were supposed to be opened using the Exec function OpenLibrary(). This is not the case any more. OS4 has introduced a new function in Intuition, OpenClass(), which returns the class library base as well as something called the class pointer. The class pointer has actually been around since the beginning of BOOPSI but if you have been using the ReAction macros (see above), chances are you have not even noticed that there is such a thing. As the class pointer is highly relevant for OS4-compliant ReAction programming, it will be dealt with later on.

Since ReAction is going to be part of our coding almost every time we better follow Trixie’s advise. I have not heard anyone else comment on this who favours libauto in combination with ReAction. Trixie’s article about ReAction was the first one of it’s kind. I would love to see some more feedback on this. Till next time and happy coding!

What I set out to do this week I actually did. Both articles Libraries (part1) and 1084 got posted. I might actually start working on Libraries part 2 this weekend. At least it was a very productive week which I hope to continue in the week to come.

This week I came across some really interesting programming information about Amiga ReAction. Trixie created two articles namely Recommended Practice in OS4 ReAction Programming and ReAction, AppWindows and AppMessages over at OS4Coding. He explains how to use ReAction the proper way and not the wrong way. Seems I did it the wrong way. Not only is it useful on how to use ReAction the correct way but it also explains in a very easy to understand way how to program with ReAction. If I had access to this information some time ago it would have saved me a lot of time and aggravation to get started with ReAction. These two articles got me fired up again to get more active again with programming.

There was another update on AmigaOS 4.1 Update 3. According to Steven Solie it is nearing completion. In the previous update they did say it should work on the  AmigaOne-SE and MicroA1-C Mark 2 but they would not test it. In one of my previous columns I talked about that if this would be the sign of dropping support for these boards. It would not be difficult to find people with these boards that are willing to do some testing. The early adopters should not be forgotten.

Due to the very limited time I have I have put any large projects on hold for the time being. At the moment I am looking into doing a small project that would not take me more than a couple months. With a couple of months I mean tops three months. Maybe I will start dabbling with some code till it hits me what I should create as a small program / utility.