Get the Toolbox event code in OSLib

Hello,
I’m using OSLib and Toolbox, things seem OK, but I can’t seem to find the event code, with which I can identify what’s actually happened, i.e. which button was pressed. I’ve made a button in the resource editor, and in ‘Deliver Event’, I’ve put ‘&33’.

I use wimp_poll() to wait for an event, which delivers reason code ‘toolbox_EVENT’ on clicking the button, i.e. 0×200, 512 in decimal.

The Toolbox manual says the event code will be in the wimp_block + 8, so isn’t that just a matter of adding 8 to the address of the wimp_block, and casting to int? Only ever seems to return 0 for me.

Help much appreciated, my will to live has diminished just a little.

Cheers

Garry

Ah, toolbox and the will to live….It’s sure to test you!
The thing to remember here are there two types of events. The first are wimp events, the second are toolbox events.
(This isn’t strictly true, but from a toolbox view point it is. I think what happens is that the toolbox code traps all toolbox events, so they never get passed on as a wimp event to wimp_poll)
There is a function something like wimp_event_register (can’t remember it exactly), there is also a toolbox_event_register or something like this.
For toolbox events you need to use toolbox_event_register to say if this window get’s toolbox event no. XXX then call procedure deal_with_my_event()
Trying to trap the toolbox events in wimp_poll will only make you lose the will to live. I went through the same depression a month ago, it was only when I was searching the header files I found toolbox_event_register that it clicked.
You maybe able to trap it in wimp_poll, but don’t go down this road of pain!
I’ll email you details on what to do when I get home later tonight.
As is the case with most of this, it’s really easy, and if your like me you’ll think your an idiot for not working it out. So I’m glad I’m not the only idiot around ;-)
I really need to do some tutorials on this, as toolbox is great (IMHO) and makes life easy, but it’s a real bugger to work out the first time.

Very kind of you, thanks Malcolm.

For toolbox events you need to use toolbox_event_register to say if this window get’s toolbox event no. XXX then call procedure deal_with_my_event()

This is not going to be directly helpful, but a list of Toolbox events that you want to receive is passed to Toolbox_Initialise in R3. Its form is identical to the list of Wimp messages passed in R2. I imagine that the list is constructed by the library from the registered events; that is what Basalt does. I suspect that there is no straightforward method of passing an empty list, to allow all events, so you that can decode them yourself from the wimp poll.

toolbox is great (IMHO) and makes life easy, but it’s a real bugger to work out the first time.

I do agree. I first worked it out a long time ago, but I appreciate how unfamiliar it can seem at first. I think you have to get into the object-oriented mindset, even if you progam with it in a more functional way. The Toolbox manual, like the PRMs, is scattered with excellent advice, but you have to read it through to see it all.

The best thing to do, as you are using oslib is to download OSLib_Support. That has a full event handler support for both the wimp events and the toolbox events. It makes life much easier!

The best thing to do, as you are using oslib is to download OSLib_Support

But be aware that I think there are issues with using OSLib_Support and Norcroft. In particular, I don’t think the X (exception) library is working at the moment. (Or rather, I think you would have to build OSLib_Support yourself using Norcroft if you wanted to get it to work.)

In particular, I don’t think the X (exception) library is working at the moment.

I don’t make much use of the X library, but I was unaware there was a problem. On reflection though, when I first upgraded oslib to v.7 I think I kept the support library at v.6.9, because there were some issues at the time. I must check to see what version I am using at the moment! Right – it seems I am still on version 6.90 for the support lib, but version 7.0 for oslib itself. Maybe I had better see about doing my own compile of the support lib.

Thank you to Malcolm, Steve, Chris, and WPB. I now have my events exactly as I want them, using ‘event_register_toolbox_handler()’ to connect event numbers to functions, it works perfectly.

Unfortunately for all concerned, I have more questions, starting off with redraw…

I can paint a sprite to the screen using ‘wimpspriteop_put_sprite_user_coords()’ This paints directly to the screen, not my window. So I assume it’s a matter of working out the position of my window, but more importantly, being able to redraw the sprite if required. At the moment, I can just ‘wipe’ it away with another window, and I’d have expected that. So, how can I get the WIMP event that my window needs repainting?

I’ll get there in the end and stop hassling you soon, I promise.

Garry

It’s OK, worked it out.

Just need to sort out clipping paths now, and make my image show up in the window, and only in the window!

Also, I have read that the sprite format can now support an alpha channel, which is wonderful. How can I make one of these sprites and draw it? Assuming it’s different to drawing a regular sprite?

Thanks for all the great help so far.

Here are some quick pointers:

In the res file for the template for the window in question – make sure that ‘auto-redraw’ is unticked in the other props dialogue, otherwise the wimp will not send you any redraw events.

Register a wimp_redraw handler for the window in question. When you receive a redraw event, the wimp block (cast to a redraw block) will tell you all you need to know – coordinates of the visible extent, scroll bar positions etc, so you can work out where the sprite needs to be drawn. As far as clipping goes, the wimp will clip to the redraw rectangle anyway, so the easy way is to redraw the whole sprite, and leave it to the wimp to clip as required. However, if it is a big image and a small window, the redraw block will contain the info needed to work out which bit of the sprite actually need plotting.

Hope that helps.

Hi Chris,
Thanks for the help. Right here is what I have so far:

I have turned off auto redraw and set up a redraw handler, so if I ‘wipe’ a different window over mine, mine redraws. However, it redraws outside of it’s own window. I can plot the sprite in the correct place now, but if the sprite is larger than the window, it’ll go outside. Furthermore, if another window is on top of mine, my sprite will plot over the top of that too.

I call ‘wimp_redraw_window()’ with the wimp_draw struct I get via the redraw handler, and that does not seem to want to clip for me. So two problems:

1) The sprite can draw outside of the confines of the window.
2) The sprite can draw on top of another window in front of my window.

Any ideas what I’m missing here? I’m using the wimp_draw struct as it comes to me, do I need to meddle with the ‘clip’ member of that struct?

Thanks

Garry

It’s OK, sorted that one out! Hadn’t worked out the whole ‘wimp_get_rectangle’ thing. Now it redraws in it’s bounds and does not write over other windows. Excellent. Now it’s just looking a but messed up on resizing the window. I will now take a look why that’s happening.

Thanks for the excellent help though, I think I’m finally beginning to ‘get’ the WIMP.

Glad you are getting there. It takes a while to get all the subtleties, but once you have some working code it can be recycled with ease.

Now it’s just looking a but messed up on resizing the window.

I assume that you are simply resizing the visible extent rather than changing the full window extent, and that the sprite is remaining the same size and not being resized as well.

I am not sure how you are doing things in terms of window creation, showing, etc, but resizing or scroll bar movements should give open_window events. If you have the auto-open flag ticked in the res window main properties, then I think the redraw_handler should be called to deal with it, without you having to do anything extra. If you do not have auto-open ticked, then you may need to call wimp_open_window yourself when you resize.

If you get really stuck, I could send you the source to one of my apps for you to have a look at. It would obviously have to be one with user redraw functions.

Hi Chris,
Thank you for the help. I am getting somewhere now…

Just one more thing…

If I plot some sprites in the redraw process, and then ‘wipe’ over the top of my window with a another, everything is where it should be. However, in code, if I move one of those sprites, then call ‘wimp_force_redraw’ with the affected area, the sprite does not appear in it’s new position until I wipe over the window again.

I thought wimp_force_redraw would put a rectangle to redraw into the WIMP (my terminology is probably a bit iffy here), and then the app would get a redraw event. This event does not seem to come, so I expect I’m missing something obvious.

Is wimp_force_redraw the right thing to use?

Thanks

Garry

Is wimp_force_redraw the right thing to use?

Yes – when you change things in your window then you need to force a redraw of the window. It may be the signs of the coordinates that are making things go awry.

Here is a simple force_redraw function I use which seems to work ok.

/******************************************
*
* function:    force_redraw_raw
*
* description: forces a redraw of the visible area
*
* input:       win - wimp window handle
*
*******************************************/

void  CJL_ForceWindowRedraw ( wimp_w win )

{
  wimp_window_state state;
  int x0, x1, y0, y1;

  state.w = win;
  wimp_get_window_state ( &state );
  x0 = state.xscroll;
  y0 = state.visible.y0 - state.visible.y1 + state.yscroll;
  x1 = state.visible.x1 - state.visible.x0 + state.xscroll;
  y1 = - state.yscroll;
  wimp_force_redraw ( win, x0, y0, x1, y1 );

  return;
}

Hi Chris,
Hmm, OK, I’m calling wimp_force_redraw, but my redraw event is not getting called. It does get called if I wipe a window over my window. I don’t have to do anything else to ‘poke’ the redraw handler?

Cheers

Garry

I don’t have to do anything else to ‘poke’ the redraw handler?

I don’t think so. When a force redraw has gone wrong for me, it is usually due to the redraw coordinates being incorrect. I assume the wimp simply quietly ignores a redraw request with invalid coordinates. It is usually the y0 and y1 coords being either transposed (y1 is the top coord) or of wrong sign (-ve going down the window). Either y1 will be 0 or -ve, y0 will be ‘more negative’ by the height of visible area.

That is all that comes to mind at the moment. The coordinates are ‘window’ coordinates, not absolute screen coordinates.

ps. Have you tried a ‘generic’ force redraw of all the window visible area, similar to the function I posted above? That way you do not have to worry about doing any calculations. Once the whole window is being redrawn correctly, you can then worry about forcing a redraw of only part of the visible area.

Hi Chris,
You’re quite right, your function to redraw the whole window works fine, so I’d say it’s clear I’ve got my window coordinates wrong.

Thanks a lot for the help.