A WIMP Hello World?

I don’t suppose you know how to get a nice ‘printf’ going? I can get it painting direct to the screen, but I’d rather output to a little console window or something.

Use Reporter: http://www.avisoft.force9.co.uk/Reporter.htm

As for printf(), you’ll find that debug_printf() from the Debug module in SFLib (see http://www.stevefryatt.org.uk/software/build/) does pretty much what its name would suggest but sends the data to Reporter.

Unless you’re working in the GCC Cross-Compiler, you might find it easier to borrow the code for debug_printf() (which is in the SFLib src archive) and stick it in your own code. You’ll need to be linking with OSLib for that, and you’ll need to be using an EUPL-compatible licence for your software (GPL 2 would be fine).

The other option is to write your output to stderr and redirect that to Reporter’s filing system (see the manual for details). I’ve done this for NetSurf’s log output on occasions, but it doesn’t always work quite as you would expect — as such, debug_printf() is probably easier…

Thanks Steve, that looks great, I’ll give that a try on Monday (my Raspberry Pi is at work, not home).

As for using OSLib and Toolbox, maybe I’ll see about getting that going once I’ve got my head around Toolbox itself. So far I quite like it, it seems quite simple.

My project is actually really basic, and I don’t need much from my UI, all the programming logic is in Lua, and just uses C to build native interfaces on whatever platform it’s running on. I started it on Solaris/SPARC, then got it working on Windows, so now I’d like to try RISC OS.

If you mean printf for debugging, fprintf(stderr,… and in !Run obey file where you run the program add ’>2 <yourprogname$dir>.log

so your !run file will

set yourprogname$dir <obey$dir>

RMload modules….

and the run file ends with

run <yourprogname$dir>.!Runimage 2> <yourprogname$dir>.log

Then your stderr output will appear in the log file.

To get real time output you can redirect to a pipefs file, something like 2> Pipe:$.mylog. Then in a taskobey file put:

type Pipe:$.mylog

and after running your program double click on the taskobey file.

However this can be flakey. It’s very easy to leave pipes open when quitting your program – there are closefile utilities that are a boon here.

Its a while since I used this technique but I think you need to quit your program first, then press escape in the debug window before finally closing the debug window.

you can check if a pipe file is still in operation with

filer_opendir pipe:$

Thanks Colin, I’d like real time output, which !Reporter can provide, so I expect I’ll go with that.

Cheers

Garry

Steve, I’ve now changed my program to use both Toolbox and OSLib. OSLib has some nice bits and bobs which made it easy for me to convert from pixel positions to OS Units, among other things.

OSLib and Toolbox actually feels like a fairly pleasant, modern programming environment, a nice surprise.

I’ve had a problem with the Wimp/OSLib example, the link to which was posted above. The problem is that no window is opened on the screen, and the task “WIMP” keeps running, not responding to the Task Manager or *KillTask (does RISC OS not have an equivalent of “kill -9”?)

I tried changing the obvious bug in the code (it refers to y1 twice in the …extent.y1 instead of a y0) but even changing each of the y1s in turn (NOT both together!) to y0 the same behavious occurs.

not responding to the Task Manager

Did you include (the mandatory) code to end the program when it received a Quit message?

Did you include (the mandatory) code to end the program when it received a Quit message?

If it was my code, no — as I said before, it was a direct line-for-line translation of something someone else had posted to show how OSLib made it clearer. I didn’t change anything or make it “correct”, as the intention was that it could be directly compared…

The following works OK (I’ve just tested it on RISC OS 5.18), opening a window bottom-left of the screen. It should respond to Quit from the Task Manager, as it now handles message_QUIT in the poll loop.

Note that the implementation still isn’t scalable: you would want to pull the message handling out of the main loop somehow.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "oslib/wimp.h"

#define task_name "WIMP"

wimp_w window_handle; /* Our window handle */
wimp_t task_handle;   /* Our task handle */

void register_task(void)
{
  int messages[] = {message_QUIT, 0}; /* Avoid complexity of message block initialisation. */

  task_handle = wimp_initialise(wimp_VERSION_RO2, task_name, (wimp_message_list *) &messages, NULL);
}

void event_poll(void)
{
  wimp_poll_flags mask;
  wimp_block      block;
  wimp_event_no   reason;
  osbool          done;

  done = FALSE;

  do
  {
    mask = 0;
    reason = wimp_poll(mask, &block, NULL);

    switch (reason)
    {
      case wimp_OPEN_WINDOW_REQUEST:
        wimp_open_window(&block.open);
        break;

      case wimp_CLOSE_WINDOW_REQUEST:
        wimp_close_window(block.close.w);
        done = TRUE;
        break;

      case wimp_USER_MESSAGE:
      case wimp_USER_MESSAGE_RECORDED:
        if (block.message.action == message_QUIT)
          done = TRUE;
        break;

      default:
        break;
    }
  }
  while (!done);
}

void open_window(void)
{
  wimp_window       new_window;
  wimp_window_state state;

  new_window.visible.x0 = 200;
  new_window.visible.y0 = 200;
  new_window.visible.x1 = 200 + 300;
  new_window.visible.y1 = 200 + 500;
  new_window.xscroll = 0;
  new_window.yscroll = 0;
  new_window.next = wimp_TOP;
  new_window.flags = wimp_WINDOW_NEW_FORMAT | wimp_WINDOW_MOVEABLE | wimp_WINDOW_AUTO_REDRAW |
             wimp_WINDOW_BACK_ICON | wimp_WINDOW_CLOSE_ICON | wimp_WINDOW_TITLE_ICON |
             wimp_WINDOW_TOGGLE_ICON | wimp_WINDOW_VSCROLL | wimp_WINDOW_HSCROLL | wimp_WINDOW_SIZE_ICON;
  new_window.title_fg = wimp_COLOUR_BLACK;
  new_window.title_bg = wimp_COLOUR_LIGHT_GREY;
  new_window.work_fg = wimp_COLOUR_BLACK;
  new_window.work_bg = wimp_COLOUR_VERY_LIGHT_GREY;
  new_window.scroll_outer = wimp_COLOUR_MID_LIGHT_GREY;
  new_window.scroll_inner = wimp_COLOUR_VERY_LIGHT_GREY;
  new_window.highlight_bg = wimp_COLOUR_CREAM;
  new_window.extra_flags = 0;
  new_window.extent.x0 = 0;
  new_window.extent.y0 = -500 - 200;
  new_window.extent.x1 = 300 + 200;
  new_window.extent.y1 = 0;
  new_window.title_flags = wimp_ICON_TEXT | wimp_ICON_HCENTRED | wimp_ICON_VCENTRED;
  new_window.work_flags = wimp_BUTTON_CLICK << wimp_ICON_BUTTON_TYPE_SHIFT;
  new_window.sprite_area = 0;
  new_window.xmin = 0;
  new_window.ymin = 0;
  strcpy(new_window.title_data.text, "H");
  new_window.icon_count = 0;

  window_handle = wimp_create_window(&new_window);

  state.w = window_handle;
  wimp_get_window_state(&state);
  wimp_open_window((wimp_open *) &state);
}

int main()
{
  register_task();
  open_window();
  event_poll();

  wimp_close_window(window_handle);
  wimp_delete_window(window_handle); /* Unnecessary! */

  wimp_close_down(task_handle);

  return(0);
}

Note that the implementation still isn’t scalable: you would want to pull the message handling out of the main loop somehow.

For completeness, here it is re-written to use SFLib’s event library (as that’s what I’m familiar with; other event libraries are available, etc). There’s still a switch() following the call to wimp_poll(), but it now contains only generic Open and Close Event handlers and would probably gain nothing else aside from a Null Event handler if one was required. Everything else is handled via event handlers, such as Click Events in the window’s work area. Even the generic Close Event handler isn’t used, as the window has its own event handler for that too: this allows it to quit the application when the window is closed (in something like a multi-file editor, you would use this to destroy the data associated with the window being closed, while leaving the generic handler for things like dialogue boxes with close icons).

It’s rather contrived for an “application” this size, but should scale a lot more pleasantly.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "oslib/wimp.h"

#include "sflib/event.h"

#define task_name "WIMP"

osbool main_quit_flag = FALSE;

/* Handle incoming Message_Quit events: registered against message_QUIT
 * in main().
 */

static osbool main_message_quit(wimp_message *message)
{
  main_quit_flag = TRUE;
  return TRUE;
}


/* Handle the window's close icon being clicked: registered against the
 * Close event in window_open().  If we didn't register this, close events would
 * be handled by wimp_close_window() in the poll loop as before, but we wouldn't
 * know about them.
 */

static void window_close_handler(wimp_close *close)
{
  wimp_close_window(close->w);
  main_quit_flag = TRUE;
}


/* Handle click events from the window's work area: registered against the
 * Click event in window_open().
 */

static void window_click_handler(wimp_pointer *pointer)
{
	os_error error;

	if (pointer == NULL)
		return;

	error.errnum = 255;
	sprintf(error.errmess, "Clicked button %d", pointer->buttons);

	wimp_report_error(&error, wimp_ERROR_BOX_OK_ICON, NULL);
}


/* Create and open the window, registering close and click event handlers for it.
 */

void window_open(void)
{
  wimp_w            window_handle;
  wimp_window       new_window;
  wimp_window_state state;

  new_window.visible.x0 = 200;
  new_window.visible.y0 = 200;
  new_window.visible.x1 = 200 + 300;
  new_window.visible.y1 = 200 + 500;
  new_window.xscroll = 0;
  new_window.yscroll = 0;
  new_window.next = wimp_TOP;
  new_window.flags = wimp_WINDOW_NEW_FORMAT | wimp_WINDOW_MOVEABLE | wimp_WINDOW_AUTO_REDRAW |
             wimp_WINDOW_BACK_ICON | wimp_WINDOW_CLOSE_ICON | wimp_WINDOW_TITLE_ICON |
             wimp_WINDOW_TOGGLE_ICON | wimp_WINDOW_VSCROLL | wimp_WINDOW_HSCROLL | wimp_WINDOW_SIZE_ICON;
  new_window.title_fg = wimp_COLOUR_BLACK;
  new_window.title_bg = wimp_COLOUR_LIGHT_GREY;
  new_window.work_fg = wimp_COLOUR_BLACK;
  new_window.work_bg = wimp_COLOUR_VERY_LIGHT_GREY;
  new_window.scroll_outer = wimp_COLOUR_MID_LIGHT_GREY;
  new_window.scroll_inner = wimp_COLOUR_VERY_LIGHT_GREY;
  new_window.highlight_bg = wimp_COLOUR_CREAM;
  new_window.extra_flags = 0;
  new_window.extent.x0 = 0;
  new_window.extent.y0 = -500 - 200;
  new_window.extent.x1 = 300 + 200;
  new_window.extent.y1 = 0;
  new_window.title_flags = wimp_ICON_TEXT | wimp_ICON_HCENTRED | wimp_ICON_VCENTRED;
  new_window.work_flags = wimp_BUTTON_CLICK << wimp_ICON_BUTTON_TYPE_SHIFT;
  new_window.sprite_area = 0;
  new_window.xmin = 0;
  new_window.ymin = 0;
  strcpy(new_window.title_data.text, "H");
  new_window.icon_count = 0;

  window_handle = wimp_create_window(&new_window);

  event_add_window_close_event(window_handle, window_close_handler);
  event_add_window_mouse_event(window_handle, window_click_handler);

  state.w = window_handle;
  wimp_get_window_state(&state);
  wimp_open_window((wimp_open *) &state);
}


/* Poll the Wimp, passing events on to EventLib and processing any that it
 * doesn't want to handle.
 */

void event_poll(void)
{
  wimp_poll_flags mask;
  wimp_block      block;
  wimp_event_no   reason;

  do
  {
    mask = 0;
    reason = wimp_poll(mask, &block, NULL);

    if (!event_process_event(reason, &block, 0)) {
      switch (reason)
      {
        case wimp_OPEN_WINDOW_REQUEST:
          wimp_open_window(&block.open);
          break;

        case wimp_CLOSE_WINDOW_REQUEST:
          wimp_close_window(block.close.w);
          break;
      }
    }
  }
  while (!main_quit_flag);
}


/* Main code entry point: register with the Wimp, add an event handler for
 * Message_Quit, open a window, then poll before closing down cleanly.
 */

int main()
{
  wimp_t task_handle;

  /* Pass NULL for the message list, as EventLib sorts out adding messages when
   * handlers are registered for them or it needs them for other reasons.
   */

  task_handle = wimp_initialise(wimp_VERSION_RO3, task_name, NULL, NULL);

  event_add_message_handler(message_QUIT, EVENT_MESSAGE_INCOMING, main_message_quit);

  window_open();

  event_poll();

  wimp_close_down(task_handle);

  return(0);
}

I’ll try it on my Raspberry Pi in due course and see what happens. When I tried it yesterday, not only did it not respond to being killed but no window was displayed either—so I couldn’t end the program by closing the window.

In it’s original form (without the event library) the code is pretty similar to a Windows API program—or what one might have looked like if Charles Simonyi hadn’t invented Hungarian Notation. The main difference is that the event polling routine in Win API programs is restricted to one window only—you pass its address to the window creation routine, and it’s called a “window procedure” (almost invariably it’s named WndProc).

so I couldn’t end the program by closing the window.

Just to clarify – RISC OS isn’t Windows; closing the last window won’t quit the app unless you specifically code this behaviour )but don’t, this isn’t the RISC OS way).

Well, I shot my bolt some days ago. Not counting comments and blank lines I make that 99 lines for the C and 7 lines for the RiscLua example. Number of lines is a dodgy metric, of course, especially when require or #include are used, but surely it has something to say about ease of programming for the beginner.

Not counting comments and blank lines I make that 99 lines for the C and 7 lines for the RiscLua example.

Does the RiscLua example open a window on screen? 55 lines of the second C example are concerned entirely with that, so if not then that narrows the difference somewhat.

In addition, creating windows programmatically is pretty long-winded in any language. In practice, an application using a Templates file would have a window_open() looking more like this (assuming some more bits from SFLib; again, other libraries are available):

void window_open(void)
{
  wimp_w            window_handle;

  templates_open("<HelloW$Dir>.Templates");
  window_handle = templates_create_window("NewWindow");
  templates_close();

  event_add_window_close_event(window_handle, window_close_handler);
  event_add_window_mouse_event(window_handle, window_click_handler);

  windows_open(window_handle);
}

RISC OS isn’t Windows; closing the last window won’t quit the app unless you specifically code this behaviour (but don’t, this isn’t the RISC OS way).

That’s what the example did; for small utilities that don’t install on the iconbar, it’s the correct thing to do!

I make that 99 lines for the C and 7 lines for the RiscLua example.

Does that include building a window on the fly? It looks like most of that C code is for setting up the CreateWindow data block.

Well, I’ve just tried the example code you posted above—the one without the event handling library, on a Raspberry Pi/RO 5.19 RC6/Norcroft compiler, and the results are the same as before:

• No window is visible on the screen;
• The task still doesn’t respond to being asked to quit via the Task Manager.

I tried inserting some printf statements and running the program from a TaskWindow. The results tend to vary depending on what editor is managing the teask window, but in the case of StrongEd, it is obvious that the application enters the poll loop and returns a lot of reason code 0s, as one would expect, but there’s still no window on the screen.

I’ve tried changing the resolution from the Pi’s FullHD default to 640×480, but that makes no difference either.

Don’t know whether the compiler has anything to do with it. I’ve installed GCC and got it (GCC) working; will look at getting the relevant version of OSLib for GCC and see if that makes a difference. But it won’t be for a while.

Well, I’ve just tried the example code you posted above—the one without the event handling library,

Can you post the code you used?

I tried inserting some printf statements and running the program from a TaskWindow.

You can’t run a multitasking program from a task window.

it is obvious that the application enters the poll loop and returns a lot of reason code 0s, as one would expect, but there’s still no window on the screen.

You are only getting that far because you are not checking for errors.

Here, I open a taskwindow and type…

*BASIC
>SYS "Wimp_Initialise",200,&4B534154,"Test" TO ver%, thdl%

Window Manager is currently in use
>

In other words, your returned poll codes are meaningless because your task was never initialised – it just doesn’t work like that within taskwindows.

I just wrote a short program to call Wimp_Poll in a taskwindow and it returned a lot of zeroes.

Interesting, it returned 17,17,18 and then froze the system when I tried it in the F12 command line! I think maybe Wimp_Poll needs to be tweaked to throw an error if it wasn’t called by a valid task and/or in the Desktop world!

Either way – you can’t run a multitasking program in a taskwindow. Sadly, nor can you easily printf(). You could use Wimp_ReportError (or whatever the library offers) to provide status messages but use them judiciously – a never-ending popup message in a poll loop isn’t a good way to start the day!

[no doubt others will suggest Reporter or somesuch, this is a better long-term solution for sure]

Interesting, it returned 17,17,18 and then froze the system when I tried it in the F12 command line! I think maybe Wimp_Poll needs to be tweaked to throw an error if it wasn’t called by a valid task and/or in the Desktop world!

I’ve entered this as a ticket – https://www.riscosopen.org/tracker/tickets/343

Nice to see Textile is so crap that the preview thingy at redcloth rendered the code part correctly when I tried a preview, but the entered ticket has <pre><code> … </code><pre> around the example code.

Although it’s a show stopper (total system hang), I’ve flagged it as normal severity because if nobody’s really noticed it in a quarter century of using RISC OS, then… (^_^)

Just to refer to my earlier post—this is a compiler issue. I had more time than expected (forgot about the Bank Holiday) and obtained the GCC version of OSLib. And I find:

• When the program is compiled with Norcroft and the Norcroft version of OSLib, the task appears in the list, but no window is shown and the task can’t be killed; but

• When the program is compiled with GCC and the GCC version of OSLib, a window DOES appear and the task CAN be killed correctly.

Looks like a bug in the Norcroft version of OSLib, or in Norcroft C itself…

Yes, I’ll look at Reporter (and possibly Steve’s debug_printf) in due course. As you might be able to guess, I’m more familiar with Linux where you can always start a program from the console and printf to it—the Geany IDE for instance creates a console to run a program. Can often be very useful.

Using Wimp_ReportError is equivalent to using a message box in Windows—I’ve used that in the past and it needs to be used very sparingly. Windows GUI programs do not have a console to write to, even though you can use printf the output is thrown away.

BTW: how do you do the block of code as in the last-bu-one post above?

Looks like a bug in the Norcroft version of OSLib, or in Norcroft C itself…

I have (an older version of) the Norcroft compiler. If you can zip up your project and makefile and the version of OSLib you used, I’ll give it a whirl and see what happens for me, if you like?
Did the Norcroft compiler throw any warnings or messages while building the code?

I’m more familiar with Linux where you can always start a program from the console and printf to it

Ah, yes – the Alt-plus-F-key thingy that switches between the GUI and multiple command lines, all different.

As you’re a Unix guy – I wondered (but never tried) – could you start the GUI in one of the other command lines and have it run independently of the GUI already started? Like Alt-F1 and Alt-F2 could switch between different window managers, each independent of the other?

Using Wimp_ReportError is equivalent to using a message box in Windows—I’ve used that in the past and it needs to be used very sparingly.

Oh yes! Making a mistake like a called-a-billion-times loop with a MsgBox in it is a mistake you only tend to do once. After some time coding, you learn to drop in a few brief popup messages, and change (not add to) them as you work to narrow down the problem.

Windows GUI programs do not have a console to write to,

Depends on the environment – VisualBasic has Debug.Print that does runtime output while the program is running in the IDE.

even though you can use printf the output is thrown away.

Another method I have used (under RISC OS no less) is to printf to a serial port. Originally I had a DEC VT110 terminal, but more recently (as the terminal is no longer with me thanks to moving and such) I used a PocketBook II (aka Psion 3a). Only good for 9600bps, but it is actually one of the most responsive debug setups I’ve used.

BTW: how do you do the block of code as in the last-but-one post above?

Leave a blank line (this is important).
Then use <pre><code> followed by your text/code/etc. Then close the code and pre tags, and finally another blank line. So essentially:

<pre><code>your program
or whatever
goes here...</ code></ pre>

note: space inserted into example closing </code> and </pre> so Textile doesn’t think they are the real thing]

Ah! Of course you can’t use &#60; instead of < to do this inside those tags!

As you’re a Unix guy – I wondered (but never tried) – could you start the GUI in one of the other command lines and have it run independently of the GUI already started?

Ever wondered why VNC has a :0 and :1 and :2 (etc) element in the command?

X-windows sessions (plural)

Actually by “console” I meant a GUI terminal window (e.g. LXTerminal). But X is of course a networked protocol, so you can run it from one of the alternate consoles I would guess, provided DISPLAY is set correctly. You can even run a window on a different (physical) machine.

Debug.Print disappeared from VB about 10 years ago (i.e. it’s not in VB .NET). Of course Visual Studio has a full graphical debugger but you really need two displays to make the most of this.

As for the code: it’s exactly the same as in the EARLIER of Steve Fryatt’s two posts on this page (assuming this appears on page 2, anyway), there was no makefile—I just used the GUI interface to compile the single file involved (code dragged and dropped from Netsurf), and OSLib is the current version (7.00).

The norcroft compiler is the one included in the NutPi suite.

Maybe the problem with Norcroft is caused by using the wrong libraries?
Since you are using the FrontEnd application PlingCC have a look at the library list (menu entry). You only need the libraries C:o.Stubs and OSLib:o.oslib32.
The default library list contains C:o.wimplib which will cause problems because it implements the same functions like OSLib (e.g. wimp_initialise)
but with a complete other function signature: the wimplib version returns an error pointer whereas the OSLib one returns a task handle.

Never thought about that. I removed C:o.risc_oslib, but not wimplib. When I get time I’ll try reducing the list of libraries as you suggest and see if that makes a difference.