Here is what I got:

App_1 is a big MUI-app that creates a library at runtime.
Functions of that library perform various actions on MUI-objects of that app with MUIM_Application_PushMethod

App_2 calls those library functions.

If those calls happen from inside the MUI eventloop all is fine, but when the app_2 calls them at start up or isn't MUI at all it still kinda works but I get plenty of hits.

Documentation say nothing about having to call MUIM_Application_PushMethod form a MUI object so I'm a bit at a loss right now. Or do I need to have certain libs opened in app_2 for it work ? (opening muimaster made no difference).


Alternative routes I see so far:
- turn those library commands into AReex commands
- add a signal/msgport to App_1 (or a MUIC_Proccess associated with it) and recreate what MUIM_Application_PushMethod does when getting triggered.

Quote:

I dont remember any reason why PushMethod would not work from another app. But PushMethod has some design flaws and for example limits how many methods you can have in queue.

Please also keep in mind that PushMethod is always asynchronous. If you are passing pointers they must remain valid until your PushMethod is processed.

Quote:

There is better way: use methodstack. This also allows sync'ing your methods (i.e. dont return until processed). You find examples from Ambient source code.

Quote:

A bit of testing resulted in SameLock() being called inside the library code as the culprit, still don't see why MUI or not on the calling app would matter.


Quote:

Well I'm allready inside Ambient here so that shouldn't be a problem ;)
It's just that the docs suggest MUIM_Application_PushMethod as the only legal method of calling MUI-methods from another task.

Quote:

Correct. However, you can ask GUI task to call DoMethod() with specific parameters

In methodstack approach you just pass copy of methods to GUI task and it does DoMethod() calling for you and optionally returning result.

It is almost same what your brainstormed already:

Quote:

It would be "add a signal/msgport to App_1 and call DoMethodA() with Msg from your IPC message".

Will try later as I first want to if moving that stuff into method of an object belonging to app_1 (thereby making it run in app_1's task) will avoid the troubles with SameLock().

PushMethod is actually, rarely safe at all. You cannot safely pass any managed resources (that you'd have to free once the method is processed), because there's no guarantee that the method will actually be invoked. This has been addressed in Slave.mui. Still, all this stuff can only be used between task of one application. You cannot really pushmethod from one application to another.