Hijack v270 is now released.

The only changes from v269 are ones that deal with the menu programming interface of Hijack, so if you don't use that, then you don't need this upgrade from v269.

-- the WAITMENU call now properly (I think) cleans up the menu on exit.

-- one can now invoke WAITMENU with a NULL argument to completely release the menu/buttons prior to application exit.

As usual, 100% untested, since I never use this stuff.

Cheers

-ml

oops, we broke some of the functionality of the way WAITMENU works, so that all current hijack programs cannot return control to the player when they finish executing. ya'll might want to wait to upgrade to v271, until this bug gets worked out. Mark, I'm sending you another PM that shows where the problem is.

John

Yup, more holes in the WAITMENU stuff in v270 than there were in France's play today. Trying again now with v271, available shortly.

Cheers

Perfect. All the pre271 bugs I was tracking in the WAITMENU interface have been fixed. (Not to say there couldn't be more, but it looks good.)

To all the programmer types out there, hijack basically keeps better track of menu titles of a running program. It is now possible for a program to dynamically change its menus during its execution. A program can also be selected from the list, run once, do something, then close itself. Previously, once a program was bound to the menu it could not be unbound. If anyone would like to see an example of some type of menu usage, let me know.

Finally, a question to Mark. I'm unclear about what the NULL call to WAITMENU actually does in 271. The menu item are already unbound between WAITMENU calls (which is great!), so is this neccessary? Perhaps it informs hijack to make sure every thing is cleaned up?

Thanks,

John

Normally, when a user app is selected from the menu, then on exit from WAITMENU the userland application "owns" the screen.

If I implemented it correctly, then passing NULL to WAITMENU tells hijack to return control of the screen to the player/hijack. If a player app were to just exit(0) after being selected on a menu, it would still own the screen, and the player/hijack would not be responding.

Cheers

Ah, of course! I was having it do this before, without realizing what it was doing and looking for it's effect on the menus. Yes, this appears to work as advertised. Thanks for the clarification.

Okay John/Mark, a coupla questions, since I haven't tried any of the new Hijack versions yet (I'm on 269 or so):

1) Am I going to have to rewrite how my apps are binding to Hijack? It looks like things have changed a lot and I'm wondering if it's backward-compatible, so to speak.

2) A few people (myself included) are interested in having the ability for user apps to run *without* having to be selected from the Hijack menu. Generally that's more interesting for overlay-type apps that could, say, provide a customizable info mode that would sit on top of the player app. The kind of apps you would want to just always be running, maybe have the ability to write to the display, but without having to select it from the menu. Is that possible yet?

Thanks for all your work, guys.

1) The type of apps that worked earlier (namely the while loop WAITMENU call) such as emptriv will continue to still work. Basically the things that can be done with WAITMENU have just been extended to do things like be able to change menus within an app and have apps be able to smoothly start and close themselves. So, yes, everything should be backwards compatible.

2) I'll leave this to Mark, I have no clue.

BTW, Mark deserves all the credit for implementing this stuff, I just tested it. Hopefully my contributions will be released in a few days. (Namely, job control for userland apps and another app I just started on.)

Hi Tony!

No, what you're looking for is not there.

I'm just in a bug-fix mode for now .. too busy with the seasonal work and climbing stuff. Maybe next winter.

Cheers

I hear ya, Mark. I just thought you might have thrown something like that in, as you've been known to do in the past!