Its all new to me

OK so I’ve programmed computers before but now that I have my Pi Zero up and running properly and a fresh copy of the DDE installed coupled with a desire to write a graphical program—now what?

I have the “Beginners Guide to Wimp” and “First Steps Programming” books as well as all the PRMs. The first two books seem to concentrate on BASIC which I haven’t really touched since writing stuff in Amiga BASIC in the mid 1990s.

Ideally I would like to write the program in C/C++. Are there any good beginners guides to graphical programming in C/C++ for RISC OS? I don’t mind buying a book if one is for sale. (also I’ve got quite a few books for other platforms so it really needs to be a RISC OS specific one).

So what do you all reckon? Stick to C and find a book or (re)learn BASIC and use the books I have?

Glen, could you prefix your subject line with a relevant title to the content? It would be much more helpful to people.

Glen, could you prefix your subject line with a relevant title to the content? It would be much more helpful to people.

Sure thing—any admins out there care to edit?

Whilst I agree that you’ll probably want to end up programming in C, the advantage of the books is that they give a great “first principles” approach to desktop programming, that you may not get through C libraries etc. That solid grounding can be really helpful.

It is worth remembering that BASIC on RISC OS is a very well-rounded language, and there’s very little you can’t do in it. Sure, there are reasons why you might choose something else for a big project, but there’s no real functional reason to avoid BASIC. Also, it is very fast on StrongARM CPUs onwards as it fits in the CPU cache. This gives a ridiculous level of performance scaling with clock speed etc.

It should be pretty simple to re-write the BASIC example code in C, since it is well explained/commented in those books. Also, the code builds up gradually through the chapters, so you don’t have to re-write vast swathes in one go. Indeed, one might even suggest that converting code to C would be a really good learning exercise!

Edit – I may be getting confused – I rather assumed you were talking about the Wimp Programming for All book which is part of our “Wimp Programmer’s Suite” product on !Store (amongst other places). I can’t comment on the other books as I haven’t read them.

Thanks Andrew I will email to discuss options…I had to desolder the Zero again but will put it all back together again soon I’m sure!

You will probably end up programming with C because it is nicer to have a lot of error checking done at compile time instead of “when the program is running”, and the modularity aids in code reuse (with the ability to hide functions and variables from global scope). Not to mention proper typed variables and a memory system where you can free and resize memory allocations. There are several libraries available to aid in making allocations. I would recommend DeskLib but I’m biased. ;-) The DDE guides will introduce you to RISC_OSLib which is used by Edit, Paint, Draw, and… practically nothing else ’cos it is kind of icky and badly designed.

That said, BASIC is a very capable language and the inline assembler means that it is quite feasible to write entire “big” applications in BASIC. There are also libraries available to gloss over the nastier bits of the Wimp (which usually means building data blocks manually without the pleasantries of named structures like in C, instead it is lots of wimp!this = wimp!that.

I would absolutely recommend learning how to use the Wimp from BASIC first. I learned that way and even while I no longer need to remember any of those obscure things (I write in C), doing so years ago has given me a grounding of how the Wimp operates and behaves.
By contrast I needed to know nothing whatsoever about Windows to churn out programs using VisuslBasic (the real one, not that .Net rubbish). Problem was, when I came to doing anything out of the remit of plain VB, that’s when one needs to dabble in the Win32 API and realise what a deranged mess it is, and some things are just way more difficult than they really ought to be (hello GDI+). I also find it amusing that it is simpler to put a cut-out bullet hole in a window (that you can see through) than to put an icon into the system tray (sorry, “notification area”) and then change said icon’s appearance.

The ground work sucks, but understanding the nuts and bolts makes things much simpler later on.

For what it is worth, when I was a newbie at C, I would “prototype” my applications in BASIC and then port them to C. The hardest part was writing the initial code. The putting wasn’t difficult, even when going from a personal custom library to DeskLib. In both cases I could pretty much black-box the Wimp routines and arrive at “here’s a function that deals with clicks in the xyzzy window”.

it is very fast on StrongARM CPUs onwards as it fits in the CPU cache.

I see this pop up from time to time and I have two observations:

• What do you suppose is the likelihood of this being even remotely true on a multitasking system? I cannot imagine that the machine is going to be loading the entire interpreter into the cache from one poll to the next. It’ll be loading those instructions that are actually executed (plus a few extra for technical reasons).
• Don’t forget, there are many many activities happening behind the scenes. A scary huge amount of code is being executed when the machine is “doing nothing”. If somehow the entire BASIC interpreter is loaded into the cache, you’d need that much again to cater for the interrupt/event/callback handlers.

Maybe, maybe, Acorn got ChangeFSI running super-fast in stand-alone mode on a StrongARM by virtue of the entire BASIC module residing in cache. But in the Wimp world? There is no exclusivity over cache for BASIC alone…

I can recommend this reference http://www.stevefryatt.org.uk/docs/wimp/

Installing OSLib alongside the DDE is straightforward. You can also embrace the shared makefiles, and easily get a shell Toolbox application going. If you want, you can skip the Toolbox and hit the Wimp directly.

As other’s have said, Martyn Fox’s book, although it is is in BASIC, is a great reference source for understanding the WIMP environment in RISC OS and his programs are available for downloading. With your graphics program, you may want to save the graphics as a Draw file and I found Chris Dewhurst’s booklet “The Book of Draw Stuff” helped me to understand the process. For C programming, you may also like to consider http://www.drwimpc.co.uk/ as a starter. I have found CJE Micros http://www.cjemicros.co.uk/ to be a great source for books on RISC OS programming (and software in general). Good luck with your endeavours

Thanks everyone!

All very useful information and I have just got my first C WIMP program up and running nicely (even if it doesn’t actually do anything yet!)

I might re-consider BASIC (and its another feather in my cap so definitely worth-while) but for now I’m going to stick with the language I know best and learn about WIMP that way.

OK so I got to the end of Steve’s excellent tutorial and have dug around in a load of documentation (PRMs and the other BASIC manuals I have as well as on the Internet), I have also been rooting around in some EUPL/GPL source code for various RISC OS projects and I cannot get my head around how to use/deploy my own icon on the iconbar instead of using one from the sprite pool.

So what I have right now is:

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

And I can change “user1” to get different things from the sprite pool but how do I use my own super-fancy-new sprite?

OK I worked it out for myself (and it made me insanely chuffed!)

If anyone else is interested in the obvious solution this what I did:

changed the “user1” to “!myicon”

Then created a !Run file with the following contents:

IconSprites <Obey$Dir>.!Sprites

Set Test$Dir <Obey$Dir>
Run <Test$Dir>.Test

And put !myicon into the !Sprites file.

OK…now I need to create a window…

1. You need your sprite in a sprite file called !Sprites (also !Sprites22 etc). THis file is in the app directory.

2. In the app !run file you need the command to load your sprite(s) into the sprite pool
IconSprites <MyApp$Dir>.!Sprites

3. Once the app is running and registered as a wimp task you need to create the iconbar icon. The method obviously depends upon the language and libraries you are using. Look at some example code.

In Basic you may just use SYS"Wimp_CreateIcon" with appropriate flags etc. The window handle for the iconbar is -1

Oh, and some menus…

and there is the niggling issue of actually making the program do something useful…

In Basic you may just use SYS"Wimp_CreateIcon" with appropriate flags etc. The window handle for the iconbar is -1

Thanks Chris, I think thats the problem I was having because of all the BASIC code I was looking at and reading that line then thinking “Huh, what now?”

Also the other C examples I downloaded were all very complex and while the information was in there somewhere I couldn’t easily find it.

It wasn’t until I stumbled on an example from DeskLib that was sufficiently simple for my small brain to cope with that I worked out what to do!

Another option to learning WIMP programming on RISC OS is to watch the 10 part tutorial on Youtube bya James Hobson. It’s a really easy to follow series, and worth watching them all.

https://www.youtube.com/watch?v=ALiMp-GHIX4&list=PLNLIbsKl8RYn29SXrHanOhFc7HkbdBCkM

It will be more than 10 parts when I get the time and motivation (lacking in both areas). If you watch the tutorials, be sure to ask questions or suggest improvements where nessassary. If you watch them you will see I have more to learn about making videos than actually programming risc os!