Hi,

so... So many years (more than 15 for sure) since last time I switched my peg on; it means I actually forgot everything about amiga/mos.

In RxMUI, let's suppose you created two radio objects, r1 and r2 and set up a couple of notifications as
r1 -> r2 everytime active changes triggervalue
r2 -> r1 everytime active changes nottriggervalue

to avoid the "notifications storm" that the above starts, I simply check if the stack is less than a specific value in OM_SET; if so, 0 is immediately returned

this worked fine in 68k, but it doesn't work in ppc, the system simply freezes and that's it

why?

what can I do about it?

note that rxmui is 68k

MUI has a concept of NoNotifySet which needs to be used to avoid circular notifications.

Quote:

Sorry for being offtopic.. it would be great if you consider updating AmRSS with SSL support.

@jaca
yes, but I am talking about a context where we are in an arexx macro, so users should be free to do whatever they want and so they could make errors without freezing the system. I can't understand why what I can do to replicate the stack check under mos.

@analogkid
Ohhhh, I wish I had time and mental resources to do that; I remember htmlview was obsolete 20 years ago... Is there some other mcc to use as html view?


[ Edited by alfie 17.05.2024 - 18:24 ]

Quote:


I think jaca capsulated WebKit for Iris into a mcc, but I'm really no expert in those things. I don't know how much time and effort it is to integrate it into AmRSS. From a users' POV I greatly miss AmRSS.

Quote:

MUI has always required notifications to be set up so that they don't trigger each other. No check can reliably workaround that.

Quote:

WebKit could be embedded in other apps, but only if they're written in ObjectiveC-MUI.

Quote:

Sorry If I am pedantic:

Code:

Worked for ages on classic. So what may I do to replicate that on mos?

Quote:
Arg, that's a pity.

@alfie: Maybe you could try Hollywood with the external plugin named RapaGui.

Easy to realise a GUI in MUI with an XML file.

@alfie

Code:

Not sure what this is supposed to do exactly, but you could simply have a counter variable in your instance data and check that rather than make assumptions on stack layout.

Quote:

Not really. There's a lot of code/programs which rely on not really documented TAG_IGNORE poking in internal MUI classes (but also some external ones) where in OM_SET they do "if (new_value == old_value) tag->ti_Tag = TAG_IGNORE).

Quote:

AROS MUI (Zune) internally detects notification loops in very simple way. The notfication nodes (each object has a list of notifications set up on it) has an "active" flag. When a notification is fired:

Code:

But before doing that, it checks if active is already TRUE. If so, it has detected notification loops and aborts.

I wonder what would break if MUI did that internally, too? As last resort notification-loop-prevention. One issue is that if a new program would rely on that, it would break in an older version of MUI that did not yet do that. Also it is not 100 % alternative to stupid TAG_IGNORE poking, because behaviour can still be slightly different, so it would still not allow you to get rid of stupid TAG_IGNORE poking in internal or external classes.

The problem is that in the example above the TAG_IGNORE trick can't be used, because the two objects notify between themselves via triggervalue and nottriggervalue, so the value always changes.

Ages ago I tried a lot of different approaches to the problem and none actually worked, but the stack check: if the used stack is less than a peculiar value than return 0 and everything should stop, because the OM_SET doesn't reach superclass so a new notification is not triggered.

It worked fine on 68k, but it doesn't work on MOS: as the available stack goes under 28k (!!!) the loop is unstoppable and I can't see why.

Now, because for other reasons (mainly to kill all notifications from and to an object when it is dropped) I maintain a notifications list for each object, I could check at notification setup if a loop is introduced, but it would only work if the triggered method is OM_SET. If the triggered method is a generic external class MUIM_DoSomething, I have no way to know if MUIM_DoSomething sets some attribute on the object, so stack check is again the only way.

If there is something undocumented in MUI so that I could do a
case attr:
if (DoMethod(obj,MUIM_IsNotifying,attr)) return 0:
break;

where MUIM_IsNotifying returns TRUE if obj is notifying attr, false otherwise

I would be vary happy :P


[ Edited by alfie 19.05.2024 - 10:41 ]

Well the stack attempt "worked" on 68k only by accident as just changing the compiler on any of the involved binaries could have given different results.

Don't know much about RxMUI but a general workaround would be to create a 3rd object (MUIC_Notify) and have both radios notify only to that.
The notify object would then set the radios with "MUIA_NoNotify,TRUE".

Quote:

The loop notification is avoided by using a NoNotifySet method. That's the official way to handle such situation as Jaca hinted earlier.

If this is problematic, subclass a group object and implement an improved logic for updating object states.

Quote:

It was not by accident, it is just how the stack works on amiga 68k. Because of different types of binaries are involved it doesn't work anymore, hence the question.




[ Edited by alfie 19.05.2024 - 11:43 ]

Are all classes subclassed by RxMUI (to do that stack check, and maybe other stuff)?

If so maybe just create your own notification system (similiar to https://github.com/aros-development-team/AROS/blob/master/workbench/libs/muimaster/classes/notify.c) and bypass the MUI one.

@alfie
Welcome back! We still are looking for innovative developers

Quote:

That's brilliant! Thanks.

Alas, I could not do that, but your suggestion inspired a very simple solution I can't believe I didn't found before.

Quote:

Thanks, but after your twenties the probability to be innovative is 0 :P


P.S.
In the last years many asked me to release the source of RxMUI. When I tried to create a sane archive, I deleted a lot of files :P

Anyway, here they are http://alfie.altervista.org/rxmui/index.html .