Diary of an Amiga fanatic

Tag Archives: Trixie

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 already ran into my first problem. Well not so much a problem but more of a query. It has to do with checking if something was successfully opened. We do it when we open a library and also the interface of it. You might still remember it from The Bucket Programming Corner but for reference I will place the source code below.

(Note: the code is not complete since we use a if statement to make a check but we need to use the else statement to complement it. Of course in the example code of the article it is complete.)

struct Library *IntuitionBase = NULL;

struct IntuitionIFace *IIntuition = NULL;

/* Opening the Intuition Library */
IntuitionBase = IExec->OpenLibrary(“intuition.library”, 50L);

/* Did we manage to open the Intuition Library? */
if (IntuitionBase != NULL)
{

printf (“We opened the Intuition Library!!\n”);

/* Open the Intuition Interface */
IIntuition = (struct IntuitionIFace *) IExec->GetInterface (IntuitionBase, “main”, 1, NULL);

/* Did we get the Intuition Interface? */
if (IIntuition != NULL)
{

printf (“We did get the Intuition Interface!!\n”);

The most important thing you need to do is to make sure you set both *IntuitionBase and *IIntuition to zero (NULL). If we set it to NULL and we open the library and get the interface the value of both *IntuitionBase and *IIntuition should be NOT (hence the !=NULL) zero. If they are it would mean that we failed to open the library or did not get the interface. If we do not set both *IntuitionBase and IIntuition to NULL we cannot do a proper check. Even worse we could and almost surely would crash the system.

All of the above bring me to the issue I ran into. If you read Trixie’s article over at OS4Coding.net you know that 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. Have a look at the below code.

struct ClassLibrary *WindowBase = NULL;

Class *WindowClass;

WindowBase = IIntuition->OpenClass(“window.class”, 50, &WindowClass);

if (WindowBase != NULL)
{

printf (“We opened the Window Class Library!!\n”);

}
else

printf (“We failed opening the Window Class Library!!\n”);

As you can see we open the Window class and with it the class pointer. 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? I assume the last is the case. If we successfully opened the Window class we will also have successfully got the class pointer. Let’s say the system is not capable of storing the class pointer in &WindowClass for whatever reason it will mark it as failing to open the Window class and the WindowBase value would be NULL. I am not 100% sure about this but for now I will assume this is the case. I am still trying to figure this out by speaking to some OS4 programmers and once I got the final answer I will let you all know.


The subject says it all about my new project; what it is and what the name is. For some time already I am thinking about what my next project should be. I started on a file manager project some months ago but stopped with it after running into some issues with ReAction. I got that stuck I just left it for what it was. But after reading Trixie’s articles about how to proper use ReAction over at OS4Coding I got a burst of new energy to attack ReAction again. When trying to come up with a new project I kept coming back to the file manager and since I got a better understanding of ReAction thanks to Trixie I concluded to give it another try. Why the name Redhouse? I tribute to Alan Redhouse because without him I would not be programming on OS4 or even having this blog.

DiskMaster has always been my favourite file manager. Even now on OS4 I still use it a lot. I always wanted to develop a file manager myself which is now actually going to happen. I am going to provide regular updates about the progress of it but that is not all. I will also show how I do certain things which means I will also show some programming code and explain it. If there is demand for it I might actually go into great details but at first I will do a sort of global explanation. I have to say that I have no clue on how to put it all together but that is also the fun of it. Learning along the way and getting others to experience the same. I will also create the file manager my way which means I might not follow the “correct” way of handling such a project. Planning everything on paper first before even writing a single line of code is not for me. When you follow my articles you will see what I mean. Let the fun begin!


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>
03
04 #include <proto/intuition.h>
05 #include <proto/exec.h>
06
07 struct Library *IntuitionBase = NULL;
08
09 struct IntuitionIFace *IIntuition = NULL;
10
11  int main (void)
12
13 {
14
15  /* Opening the Intuition Library */
16  IntuitionBase = IExec->OpenLibrary(“intuition.library”, 50L);
17
18   /* Did we manage to open the Intuition Library? */
19   if (IntuitionBase != NULL)
20   {
21
22     printf (“We opened the Intuition Library!!\n”);
23
24     /* Open the Intuition Interface */
25     IIntuition = (struct IntuitionIFace *) IExec->GetInterface (IntuitionBase, “main”, 1, NULL);
26
27     /* Did we get the Intuition Interface? */
28      if (IIntuition != NULL)
29      {
30
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       }
36
37     /* We could not open the Intuition Library Interface */
38     else
39    {
40
41    printf (“Unable to open the Intuition Library Interface!\n”);
42    }
43
44   /* If the Intuition Library is open, close it */
45   IExec->CloseLibrary(IntuitionBase);
46   }
47
48     /* We could not open the Intuition Library */
49    else
50   {
51
52  printf (“Unable to open the Intuition Library!\n”);
53  }
54
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>
03
04 #include <proto/intuition.h>
05 #include <proto/exec.h>
06
07 struct Library *IntuitionBase = NULL;
08
09 struct IntuitionIFace *IIntuition = NULL;
10
11  int main (void)
12
13 {
14
15        — Display a small window with some text —
16
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.