MUI event handling kludge mystery (SOLVED)

	Bottom Previous Topic Next Topic
Register To Post

ChrisH

Posted on: 2011/8/22 21:15 #1

Home away from home

I've run into a problem trying to check for an additional (non-MUI) signal in my MUI event handling code, which is causing various crashes whatever I try. This is complicated by the fact that I have to kludge my event code a bit, as the MUI stuff is unavoidably handled in a separate procedure that cannot be modified.

If I simplify my code down to it's essence, and convert it to C (apologies in advance for any conversion errors!) the follow is the original MUI event code which WORKS:


sigs = 0;

while (TRUE) {

    //the following is in a separate procedure

    if (sigs) sigs = IExec->Wait(sigs);

    IIntuition->IDoMethod(object, MUIM_Application_NewInput, &sigs);

    //handle MUI event here

}

I then kludged it a little, such that I can Wait outside of the procedure, and then call the MUI event handling procedure, and this also APPEARS to work:


sigs = 0;

while (TRUE) {

    if (sigs) sigs = IExec->Wait(sigs);

    IExec->SetSignal(-1, sigs);

    

    //the following is in a separate procedure

    if (sigs) sigs = IExec->Wait(sigs);

    IIntuition->IDoMethod(object, MUIM_Application_NewInput, &sigs);

    //handle MUI event here

}

Finally I allocate a non-MUI signal, and get my code to wait for it as well as the MUI signal:


anotherSignalNum = IExec->AllocSignal(-1);

anotherSignal = 1 << anotherSignalNum;



sigs = 0;

while (TRUE) {

    sigs = sigs | anotherSignal;

    

    if (sigs) sigs = IExec->Wait(sigs);

    IExec->SetSignal(-1, sigs /*& ~anotherSignal*/);

    //handle AnotherSignal event here

    

    //the following is in a separate procedure

    if (sigs) sigs = IExec->Wait(sigs);

    IIntuition->IDoMethod(object, MUIM_Application_NewInput, &sigs);

    //handle MUI event here

}

This code SORT OF works, but it tends to crash

.

If I make it "more correct", by uncommenting the /**/ bit then MUI simply stops responding. (EDIT: That happens even if the second Wait() is only executed when "sigs & ~anotherSignal" is non-zero.) The only possible explanation I can think of is that MUI is using the signal that *I* allocated myself (anotherSignal) - but that should not be possible.

Edited by ChrisH on 2011/8/22 21:32:27
Edited by ChrisH on 2011/8/22 21:38:10
Edited by ChrisH on 2011/8/22 21:58:42
Edited by ChrisH on 2011/8/23 14:47:27

Author of the PortablE programming language.

thomas

Re: MUI event handling kludge mystery

Posted on: 2011/8/22 21:38 #2

Not too shy to talk

You should divide "sigs" into "signals_to_wait_for" and "signals_received". Otherwise you overwrite your variable and at some point sigs is 0 and Wait(0) will never return.

BTW, you should remove the Wait() from the "seperate procedure".

ChrisH

Re: MUI event handling kludge mystery

Posted on: 2011/8/22 21:43 #3

Home away from home

@thomas Quote:

BTW, you should remove the Wait() from the "seperate procedure".

That is simply not possible, which is why I do the rather kludgy SetSignal() business.

Quote:

You should divide "sigs" into "signals_to_wait_for" and "signals_received".

Are you objecting to how I do it in my first example code? That is the official MUI way to do AFAIR, and it works reliably.

Quote:

Otherwise you overwrite your variable and at some point sigs is 0 and Wait(0) will never return.

That cannot happen because of the if statement:
if (sigs) sigs = IExec->Wait(sigs);

Author of the PortablE programming language.

ChrisH

Re: MUI event handling kludge mystery

Posted on: 2011/8/23 0:50 #4

Home away from home

@all
Hmmm, I *may* have got it working, after fixing one bug. Will do more tests & report back later...

Author of the PortablE programming language.

tboeckel

Re: MUI event handling kludge mystery

Posted on: 2011/8/23 8:22 #5

Just popping in

Take a look at YAM's source. It uses lots of additional signals for different purposes. The Wait() call is located in line 2785 and the handling of the received signals follows directly after that. There is absolutely no need to "eliminate" certain signals using SetSignal().

ChrisH

Re: MUI event handling kludge mystery

Posted on: 2011/8/23 14:46 #6

Home away from home

Looks like I fixed my code, with a small tweak to how "anotherSignal" is handled:


anotherSignalNum = IExec->AllocSignal(-1); 

anotherSignal = 1 << anotherSignalNum; 



sigs = 0; 

while (TRUE) { 

   if (sigs) sigs = IExec->Wait(sigs | anotherSignal); 

    IExec->SetSignal(-1, sigs & ~anotherSignal); 

    //handle AnotherSignal event here 

     

    //the following is in a separate procedure 

    if (sigs) sigs = IExec->Wait(sigs); 

    IIntuition->IDoMethod(object, MUIM_Application_NewInput, &sigs); 

    //handle MUI event here 

}

Of course it would be better to avoiding SetSignal() altogether, but that's not really possible in my case, and anyway this seems to work satisfactorily

Now I just have to solve a separate bug (unrelated to the above code) which had been confusing my attempts to resolve the event-handling.

Author of the PortablE programming language.

Belxjander

Re: MUI event handling kludge mystery

Posted on: 2011/8/23 20:02 #7

Just popping in

Why ever are you using SetSignal() at all?

I'll have to dig out some very overloaded signal handling
and show that to you from a partial network stack I wrote.

this might help you with making MUI and other things work
nicely.

ChrisH

Re: MUI event handling kludge mystery

Posted on: 2011/8/23 21:33 #8

Home away from home

@Belxjander Quote:

Why ever are you using SetSignal() at all?

Please see my first post:
Quote:

This is complicated by the fact that I have to kludge my event code a bit, as the MUI stuff is unavoidably handled in a separate procedure that cannot be modified.

But I've got it working now... touch wood!

Author of the PortablE programming language.

tboeckel

Re: MUI event handling kludge mystery

Posted on: 2011/8/24 9:17 #9

Just popping in

If you really need to call SetSignal() then there is something very bad going on.

Furthermore, two Wait() calls before the MUIM_Application_NewInput is bound to cause a non-responding GUI, because you never know when the first Wait() will return. It may take an arbitrary long time and the GUI will not respond to any input during this time, because any input will be handled in MUIM_Application_NewInput only.

As I already said, take a look at how YAM handles this situation. YAM uses lots of non-GUI-related signals and handles all of them with one single Wait() right after MUIM_Application_NewInput. And YAM is definitely working stable without the need to call SetSignal().

ChrisH

Re: MUI event handling kludge mystery

Posted on: 2011/8/24 9:29 #10

Home away from home

I didn't think it was necessary to mention this since I got my code working, but I have replaced my MUI-handling procedure (which contains the second Wait) with another similar procedure that merely checks the state of the signals.

I still use SetSignal() though

as it is (a) truely unavoidable due to my unusual design constraint(s), and (b) perfectly harmless when used correctly.

Author of the PortablE programming language.

Deniil

Re: MUI event handling kludge mystery

Posted on: 2011/8/24 12:45 #11

Quite a regular

@ChrisH

I use "other" signals in many programs together with MUI (where MUI's input handling is in another procedure free from Wait and SetSignal) and I have never needed a second Wait nor SetSignal. I still think you have overcomplicated it a bit.

Have a look at this:


sigs = 0;

muisigs = 0;

main() {

    setupMUI();

    handleMUI(0);

    sigs = arexx_sig | other_sig | muisigs;

    while (TRUE) {

        sigs = IExec->Wait(sigs); //No if is needed in a correct input loop.

        if(sigs & arexx_sig) {

            handleARexx();

            sigs &= ~arexx_sig;

        }

        if(sigs & other_sig) {

            handleOther();

            sigs &= ~other_sig;

        }

        if(sigs & muisigs) handleMUI(sigs);

    }

}



handleMUI(sigs) {

    do {

        IIntuition->IDoMethod(object, MUIM_Application_NewInput, &sigs);

        //handle MUI event here

    } while(!sigs);

    //You never exit the MUI loop until it has finished all its events, i.e. returns !0 sigs.



    muisigs = sigs; //Remember the new set.

}

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++

ChrisH

Re: MUI event handling kludge mystery (SOLVED)

Posted on: 2011/8/26 12:57 #12

Home away from home

@Deniil
That is of course the way I'd do it, if my hands weren't tied...

Author of the PortablE programming language.

Deniil

Re: MUI event handling kludge mystery (SOLVED)

Posted on: 2011/8/26 13:48 #13

Quite a regular

Now I'm a bit curious what kind of wierdness you're dealing with here?

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++

Register To Post
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )