Beginning Wimp Programming in C (RESET)

Dear all

I am very glad to see how a “simple” question related to beginning programming in C turned into a frenetic discussion about licensing issues :)
Anyway, I would like to re-focus the discussion on learning Wimp programming in C.
So, if you don’t mind, I leave you the previous thread for licensing discussions, and restart a new thread focusing on Wimp programming in C for dummies :).

Let’s rewind a bit and set up the context.
I am reading the book “A Beginner’s Guide to Wimp Programming on RiscOS Computers”. My goal is to “translate” the examples in the book into C as I progress through the book. I do not want to use external libraries like !OSLib or !DeskLib. I want to stay close to the command as describe in the PRM. Note that I already have been through the tutorial “C The Wimp” written by Paul Johnson. And I am aware about the critics made by some C-purists :).

Voilà. My idea here is to post issues I encounter in this exercice in search for help and solutions. I hope this can help beginners like me in the future. I intend to post the code somewhere as I progress.

So, let’s start with my first issue.

Chapter 3 – Getting on the Icon Bar
I succesfully “translate” the example of chapter 3 into C, to one exception: I cannot get the application icon on the icon bar. In the book, a few lines are enough:

DEFPROCcreateicon 150 REM creates the application’s icon and puts it on the icon bar 160 !b%=-1:b%!4=0:b%!8=0:b%!12=68:b%!16=68:b%!20=&3002 170 $(b%+24)="!Test" 180 SYS "Wimp_CreateIcon",,b% TO i% 190 ENDPROC

Here is how I translated it:
typedef struct IconBlk IconBlk; struct IconBlk { int win_handle; int min_x; int min_y; int max_x; int max_y; int icon_flags; void *icon_data[3]; };

}

In the main function, I simply call the function:
create_icon();

The application run perfectly well. The application is on the icon bar, but the icon is not visible. Indeed, I can adjust click in the area where the icon should display and this cause the aplication to quit as expected!

Thank you for your help.

François

My god… I can I format properly the code??

Newlines are not taken into account, underscores are disappearing…

You do have an icon called “Test” in the wimp spritepool? (I note that in the BASIC example it’s called “!Test” and not “Test”… Is that intentional?)

I question your decision not to use OSLib. I understand not wanting to have a library with all kinds of magic in between, but OSLib is not like that. It is very close to the SWI API, and so you don’t need to define tedious structures and stuff like you are doing now. But it’s your call:)

When entering your code start the first line with ‘bc.. ’ without the quotes but including the space and start the first paragraph after your code with ’p. ’ Then textile won’t mess with your code.

Using your definition of IconBlk you need

icon_blk.icon_data[0] = “Test”;

replaced with

sprintf((void*)icon_blk.icon_data,"Test");

What is the name of the icon? It is “!Test” in the BASIC but “Test” in the C, unless the mangling has mangled something.

Wrapping the code <pre> and </pre> tags is the way to go.

Dear all,

Thank you for your help.
The solution is

sprintf((char*)icon_blk.icon_data,“!test”);

Now, chapter 4 😁

sprintf((char*)icon_blk.icon_data,“!test”);

What about bounds checking on the data block? How do you know that you haven’t written over the end of the available memory?

I’d use something like

strncpy(icon_bar.icon.data.sprite, "!test", osspriteop_NAME_LIMIT);

when using OSLib (which kindly defines osspriteop_NAME_LIMIT for me); you’ll need to define your own constants if you want to “stay close to the PRM”, but I’d strongly recommend not assuming.

And yes, strncpy() is correct here (I had to think about it when I copied that code, too). If the sprite name is 12 characters, you don’t need to terminate it.

ETA: Yes, in this case with an in-code constant, it probably doesn’t matter. Good habits are useful, though. :-)

I question your decision not to use OSLib.

Or any library for that matter. The point of a library is to abstract you away from the low-level stuff.

Here’s how it is done in DeskLib:

   iconbaricon = Icon_BarIconUser("!appname", iconbar_RIGHT, (unsigned int *)resource_sprites);
   Event_Claim(event_CLICK, -2, iconbaricon, iconbar_handler, NULL);

The first line will create an iconbar sprite from the “!appname” sprite (change as required) in the private sprite area previously created, referred to by “resource_sprites”.
The second line attaches an “event” to that icon, so that a mouse click on the icon will cause the “iconbar_handler()” function to be entered, to deal with the click.

It looks like this does the same thing, RISC_OSLib style:

  icon = baricon("!appname", (int)resspr_area(), iconbar_click);

I include the information about handling clicks on the icon, as that’s the next part and useful libraries will make this all much easier for you…

If the sprite name is 12 characters, you don’t need to terminate it.

Just out of interest – what happens if your app is called !MyMarvellousApp? Surely that cannot have a sprite? Or does the Wimp clip it and look for !mymarvellou and sm!mymarvell?

Just tried it. App name is “!MyMarvellousApp”. Sprite name is “!mymarvellou”. IconSpriting the sprites file gives the app a little icon.
:-)

Probably you would find out when you tried to register it.

According to the docs, app name allocations have no length restriction so long as the first nine characters are unique.

According to the docs, app name allocations have no length restriction so long as the first nine characters are unique.

This, of course, has serious implications for the naming of sequels! You’d get away with !Rocky2, but more complex sequels will require careful planning! !RockyApp2 for example!

What about bounds checking on the data block? How do you know that you haven’t written over the end of the available memory?

You are just being silly now – have I done something to upset you? The op didn’t want all this library evangelism he just wanted an answer to his question. Unfortunately he hasn’t got his wish.

My solution is perfectly adequate the string size is constant and the buffer size known. Your solution won’t work for him because he’s not using your library. I’ll say no more and leave it to you to help him.

You are just being silly now – have I done something to upset you? The op didn’t want all this library evangelism he just wanted an answer to his question. Unfortunately he hasn’t got his wish.

Apologies for not realising that every thread on this forum was about you, Colin. I’ll be more careful to stroke your ego the right way in future.

My solution is perfectly adequate the string size is constant and the buffer size known.

Sort of. In the exact example, yes (as I did, in fact, note).

However, I was under the impression that this was about helping the OP to write proper software, and in any real app the sprite name will almost certainly be used in more than just this one location. As such, unless you’re advocating duplicating string constants around the source code, the literal constant will eventually be replaced by either a #defined constant or a pointer to a string. You’ve then lost the visual link between constant and buffer, and the bounds check becomes useful.

It’s also, as I also noted, better practice in the general case to bounds check when writing stuff into icon blocks. Again, I thought we were trying to impart more general advice which might be useful.

Your solution won’t work for him because he’s not using your library.

strncpy() is part of the standard library, at least if you’re compiling to a recent¹ C standard; ditto snprintf(). Encouraging their (correct²) use in modern software is sensible. There’s usually no place for sprintf() and strcpy() in a modern desktop application.

I noted that the OP would need to supply their own constant giving the size of the buffer; that’s where using a library helps, as magic numbers are never good.

I’ll say no more and leave it to you to help him.

You’re welcome.

¹ In RISC OS terms.

² As noted, this is a rare case where ensuring there’s a terminator isn’t required.

The op didn’t want all this library evangelism he just wanted an answer to his question.

I didn’t reply to this yesterday as I thought it somewhat rude, so I went to bed instead. Today? Today I will calmly ask a question:
If we, as programmers, see somebody taking the hard way of doing something; would it not be remiss of us to fail to point out that there are easier ways?

It is common with BASIC to roll your own Wimp routines. You practically never have to do this in C with the libraries that exist. As such, when you are writing programs you can concentrate on your program and not worry about the intricacies of how the wimp does what it does.

If the original poster wants to perform low level wimp stuff by hand; yes, we can all help. However if he is looking at a book about BASIC to learn how to write programs in C, it’s a bit like learning about combustion in order to learn how to drive…

If the original poster wants to perform low level wimp stuff by hand; yes, we can all help. However if he is looking at a book about BASIC to learn how to write programs in C, it’s a bit like learning about combustion in order to learn how to drive…

That’s just you being condescending and rude.

You would rather somebody define their own structures and call SWIs in preference to a library where all this has already been done and provided?

The point about the low level stuff was not intended to be condescending. It depends upon why he is doing it this way – if to learn how the Wimp works, then that makes sense. I probably could have worded it better. If to actually write programs, then…it seems rather like reinventing the wheel…

I agree. I didn’t learn any of this stuff (other than a quick glance) because the Toolbox handles it all for me. It’s much easier to call toolbox_initialise and let it handle my icon bar icon, its menu, the opening of the window, etc.

Of course, as you point out, if the intention is to learn how it works at a low level then that’s fine. I found that perfectly clear in your earlier post and didn’t find it condescending or rude at all. It can be difficult to tell intent over text though.