[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Fwd: Re: marathon,was:Egale
Am 15.02.2012, 00:35 Uhr, schrieb m0n0 <ole@monochrom.net>:
Am Mittwoch, den 15.02.2012, 00:15 +0100 schrieb "Helmut Karlowski"
<helmut.karlowski@ish.de>:
msg[1] = gl_apid; // <-- HERE IT IS
This must be the one of the caller!
One could say that the SLB IS the caller of the appl_write.
Yes, but the status of the slb is STOP, and it's not an XaAES-client - I
don't know how this all works. I don't know why XaAES freezes after the
appl_init, maybe the slb should wait until it's completely initialized by
MiNT.
The caller should inform the slb about it's apid (different for every
user of the slb),
As I said, it's only used for the appl_write used to show some bubble.
However, I don't know
if it's only about the app id. I though appl_init maybe does something
more than returning an
app id. I thought of dracdlg as a single process, which is required to
Sure - it fills the global-array etc.
call appl_init
before it does any GEM / AES stuff.
Don't know if this could work, maybe try a simple test-app to see.
or better the slb should not use the AES at all.
Dracdlg.slb purpose is: provide GEM Dialogs and draw special objects.
That's where it crashes under EmuTOS and what does not work in MyAES (in
case the options-dialog is done by the slb).
I don't see any problem with that in general. But I see that the GEM
stuff is mixed with GEM stuff within
the application, and that's why I thought it's maybe worth to try to
link the SLB statically. If that works fine -
there is no need for further bug fixing / searching.
Sure, don't hazzle with the slb-mess :-)
I wonder what apid it uses now when XaAES just returns in my patched
version when the slb does appl_init ...
there is no error checking after appl_init().
I think it needs inout[0]=pid (=apid?), that's what my XaAES does.
--
Helmut Karlowski