PEB wrote:The main part of my program does not use RapaGUI;
That's only possible on AmigaOS. On all other systems, saying @REQUIRE "RapaGUI" will switch your complete script to RapaGUI's display adapter which means that even normal displays will essentially be windows managed by RapaGUI which means that they won't be 100% compatible to displays managed by Hollywood's inbuilt display adapter because not all features are currently routed through the plugin API, e.g. the "NoClose" flag isn't routed through. Menus aren't routed through either.
The reason why RapaGUI can't coexist with Hollywood's inbuilt display adapter on Win32/Mac/Linux is that RapaGUI uses an entirely different toolkit which can't be integrated with Hollywood's inbuilt display adapter. This is only possible with MUI on AmigaOS which integrates nicely with Hollywood's inbuilt display adapter because of AmigaOS' clean design in which additional toolkits just add their own wait signals which can then be handled through exec.library. On all other systems, however, things are much more complicated so that RapaGUI has to kill Hollywood's default event handler completely and substitute it with a custom one. That's why RapaGUI will replace almost everything on non-AmigaOS systems.
but depending on what the user might want to adjust, different configuration windows can be opened (that's where I wanted to use RapaGUI). So I was thinking that I could create the GUI window when needed, free it after it was closed, and then have the possibility to recreate a different GUI window (based on what the user chooses to do).
It's possible to do this (once I've fixed the bug in moai.CreateApp()) but it won't make any sense because, as I said above, once you require RapaGUI in your script, all your displays will be RapaGUI windows, even without an application object.