Hyperion Entertainment Message Boards

Is there any way to find out when my AmigaGuide document (opened with OpenAmigaGuideASync) has been closed by the user?

I can see some relevant-looking things in libraries/amigaguide.h: I'm waiting and processing AmigaGuide messages, but only getting ToolCmdReplyID, not any of the Shutdown messages.
The callbacks I can find no reference to in the documentation - I'm quite happy to add a callback for when the document is closed (in fact, it's preferable), but can't see how to do this.

A quick look doesn't make me any the wiser. The doc says that OpenAmigaguideAsync() spawns an instance of OpenAmigaguide(), as you already know.

I can see no reference in the code to sending any sort of message on exit. Those commands you quoted (ShutdownMsgID and ShutdownToolID) are commands to the amigaguide process, not return values.

I don't profess to be an expert, but I think you can only use the non-sync version and wait for it to return on exit. That may require that you spawn your own Process to call OpenAmigaguide(), wait for it and exit with a Death Message when it returns.

@chris

Out of curiosity - why do you need to know if the document was closed?

trixie wrote:@chris

Out of curiosity - why do you need to know if the document was closed?

To tidy up, of course! You can't free all the resources until the AmigaGuide process has closed. It seems very strange that you can't tell when the user has finished with it. Specifically, it is allocating signals that I'm a bit fidgety about, as I'm running out.

@tonyw
Is this a feature request then? It shouldn't be very difficult to make the process that spawns OpenAmigaGuide send a message to the message port after it returns.

@chris

To tidy up, of course! You can't free all the resources until the AmigaGuide process has closed.

I'm using asynchronous AmigaGuide help in my software (I did send you my amigaguide.class code, didn't I?), and I never really needed the system to tell me when the database was closed. This is how it works basically:

- OM_NEW calls OpenAmigaGuideAsync() and allocates the database resources (the document window doesn't get opened in async mode).
- When the user requests help, the opening method (AGM_OPEN) is called. The method calls SendAmigaGuideCmd() to actually display the document. Should the document window be already opened, the command brings it to front (i.e. just one asynchronously-opened instance of the help file is allowed).
- The help file stays open as long as the user wishes.
- When you quit your program, you call OM_DISPOSE upon your help file object, which first calls AGM_CLOSE to close the document window (if it is still opened) and deallocates all resources.

So it's one help file, one allocation, one deallocation. What other tidying-up do you need?

Yes, that's what I'm using

It's fine if you want the resources allocated for the entire duration that the program is running, but that's what I'm trying to avoid. So, I allocate when help is requested, and want to deallocate when the user has finished with it.

Btw, there seems to be a bug in your class, where if you click "help" any subsequent accesses will try to open nodes in help.guide instead of the original AmigaGuide. Re-initialising also fixes that problem.

@chris

It's fine if you want the resources allocated for the entire duration that the program is running, but that's what I'm trying to avoid. So, I allocate when help is requested, and want to deallocate when the user has finished with it.

Ah, I see. Never thought of a dynamic allocation like that, doesn't make all too much sense to me - there's usually one help file for one program, and the help should be accessible throughout program runtime. That's why my help allocation and deallocation coincides with program startup and exit, respectively.

Btw, there seems to be a bug in your class, where if you click "help" any subsequent accesses will try to open nodes in help.guide instead of the original AmigaGuide.

I'm not sure I understand - what do you mean by "help.guide" and "the original AmigaGuide" exactly? Also, do you set any context array through the AMIGAGUIDE_ContextArray tag? The help invocation call differs internally in the presence of a context array, so I need to know if you use one or not.

Re-initialising also fixes that problem.

Re-initialising how exactly, what do you do precisely? More specific info will greatly help me locate the bug (which I'll be only too glad to fix of course). Thanks!

trixie wrote:Ah, I see. Never thought of a dynamic allocation like that, doesn't make all too much sense to me - there's usually one help file for one program, and the help should be accessible throughout program runtime. That's why my help allocation and deallocation coincides with program startup and exit, respectively.

It is accessible throughout program runtime, it just isn't using resources whilst it's not open.

Btw, there seems to be a bug in your class, where if you click "help" any subsequent accesses will try to open nodes in help.guide instead of the original AmigaGuide.

I'm not sure I understand - what do you mean by "help.guide" and "the original AmigaGuide" exactly? Also, do you set any context array through the AMIGAGUIDE_ContextArray tag? The help invocation call differs internally in the presence of a context array, so I need to know if you use one or not.

help.guide is the guide which opens when you click "Help" from within AmigaGuide.
The original AmigaGuide is the one specified using AMIGAUIDE_Name
Yes, I'm using a context array.

Re-initialising how exactly, what do you do precisely?

I don't, because I can't, but freeing and re-initialising the class would fix it because it will think it is a brand new session.

@chris

It is accessible throughout program runtime, it just isn't using resources whilst it's not open.

AmigaGuide may not be designed for that, it has all sorts of shortages here and there.

help.guide is the guide which opens when you click "Help" from within AmigaGuide.

I see. Never tested this one to be honest - will look into it as soon as I get my loaned Sam up and running (hopefully later this week; looks like I'll need to buy a new monitor because the one I got doesn't accept the Sam's video signal, no matter what I try).

trixie wrote: AmigaGuide may not be designed for that, it has all sorts of shortages here and there.

No reason why not; ALL it needs to do is send a message to the existing msgport when the async OpenAmigaGuide call returns.