Even when this happens in a simple user situation (i.e. a user has opened some AmigaGuide file directly from WB and subsequently pressed Help), it is confusing behaviour. It would work a lot better if the new AmigaGuide (amigaguide.guide) was opened in a new window, asynchronously, so the old one was still there and "alive" - that way it could also receive messages from a program in your scenario.chris wrote:That sounds like a bug too.trixie wrote:There is also one other thing I'll need to investigate further. When you open an asynchronous AG client and the user presses the "Help" button in the window, the system-provided AmigaGuide help file will get loaded, "taking over" of your client. This wouldn't be a problem but it seems that there's no way for you to resume control, apart from shutting down and restarting the client (or pressing "Retrace" manually to get back to your file). This is rather stupid, as commands sent to the client will now be executed upon the AG system help file, not the file with which you opened the client. But as I say, I'll need to give it some more testing.
trixie wrote:All in all, the AmigaGuide Library is another long-forgotten baby screaming for some developer love
trixie wrote:the prevailing popular opinion was that improving AmigaGuide would be a more achievable goal, compared to implementing something new from scratch.
(a) A delay is required between the SetAmigaGuideContext() and SendAmigaGuideContext() calls.
(b) No AmigaGuideMsg is sent back to the launching application when the user quits an AmigaGuide which was launched via the OpenAmigaGuideAsync() function.
I was hoping that baby would have been thrown out with the bathwater and we had moved on to HTML or similar by now..
If Amigaguide would have the ability to open and close chapters, sections, subsections in the "contents" page that would count as a big step forward imho.
Users browsing this forum: No registered users and 1 guest