ARexx or PIPE: ?

7 posts / 0 new
Last post
mritter0
mritter0's picture
Offline
Last seen: 2 years 7 months ago
Joined: 2014-04-21 21:15
ARexx or PIPE: ?

My project consists of 2 parts: the main program and an external preferences editor.

When the prefs editor is opened, it has to send a signal to 1 or multiple running copies of the main program to block the window input. (busy the mouse)

When the prefs editors is closed, it has to signal the main program to reload the prefs. (I also have some other things planned for it, but this is what I will build around.)

If the prefs were not changed (cancel button) then signal all the main programs to unblock the window and continue on.

Would it be best to use ARexx from the prefs editor to signal the main program to "REXX_RELOAD_PREFS" or send a message through PIPE:MainProgram? Or some other sort of inter-process communication? I would probably need both programs to talk to each both directions for some complicated stuff down the road.

I have not seen an example of ARexx or PIPE: used in inter-process communication. The examples I have seen all run from the Shell.

Any examples online for ARexx and PIPE: for this kind of use? Thoughts?

Massi
Massi's picture
Offline
Last seen: 4 years 7 months ago
Joined: 2012-03-28 17:16
@mritter0 I would also

@mritter0

I would also investigate the "shared memory" concept as another form of IPC.

OldFart
OldFart's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: 2010-11-30 14:09
@mritter0 4 Different

@mritter0

4 Different situations can be distinguished here:
1 - 'Prefs' is started with NO 'Program' running
2 - 'Program' is started with NO 'Prefs' running
3 - 'Prefs' is started while 1 or more of 'Program' is running
4 - 'Program' is started while 'Prefs' is running

Situation 1 requires NO any particular attention, but at any point may turn into situation 4
Situation 2 requires NO any particular attention, but at any point may turn into situation 3
Situation 3 requires 'Prefs' to notify ALL of 'Program' to turn their GUI in 'Busy' state
Situation 4 requires 'Program' to open its GUI, but in 'Busy' state AND to put 'Prefs' in front

'Program':
Create a named port for communication with 'Prefs'
Try to find the named port created by 'Prefs'. If found make note that the GUI should be opened in 'Busy' state and notify 'Prefs' to come to the fore.

When running, listen for messages to arrive at its relevant port, the PrefsPort. Depending on the payload of the message either:
- turn the GUI in 'Busy' state
- apply the new prefs
- turn the GUI in 'Normal' state

'Prefs':
Create a named port for communication with 'Program'
Build a list of ALL occurrences of 'Program', based on their named ports, as well as a list of messages sent to those ports. Such a message has a payload telling 'Program' to put its GUI in 'Busy' state. You MIGHT wait for return of all those messages before commencing.
N.b.: for every occurrence of 'Program' a NEW message has to be allocated! This message is used for communication with only ONE occurrence of 'Program', but may be used and reused for ALL communication with it.

When done setting prefs resend the messages to those ports now with a payload maybe telling to update their GUI's contents according to the prefs, but anyway to put their GUI in 'Normal' state again.

It is tricky, but can be done. Things to think about are the possibillity of disappearing ports and how to handle that. List arbitration may be required. As I said; it is tricky.

Maybe someone laughs his/her ass off and comes up with a much simpler approach.

Addendum: Payload could be a simple enumeration:
0 - turn GUI in 'Busy' state
1 - turn GUI in 'Normal' state
2 - apply new settings

OldFart

gazelle
gazelle's picture
Offline
Last seen: 1 year 10 months ago
Joined: 2011-04-13 12:52
@mritter0: Do you really

@mritter0:

Do you really need to block the main programm?

I have something similar and do it this way:

The main-program has a DOS notification for the prefs file. So everytime the prefs-programm touches the prefs file, the main-programm gets notified about it and adapt accordingly.

mritter0
mritter0's picture
Offline
Last seen: 2 years 7 months ago
Joined: 2014-04-21 21:15
@OldFart: Yes, I know I would

@OldFart: Yes, I know I would I have to do all the checking for what is/isn't running and run through a loop for all the instances. I am looking more for what is the best way to do it. ARexx is what I have decided on. I just haven't come across some code that shows both ends of things.

@gazelle: I actually use that in my code to monitor a drawer. I thought about that, simple enough. But I do still want more functionality, actual ARexx scripts to control the program externally.

I started with ARexx using arexx.class and want to stick with that. (Example based on AmigaOS WIKI)

I can find plenty of example scripts run from Shell signalling a program. I just haven't found a true inter-process ARexx commumication example. The example on Thomas Rapp's site
rexx.c
shows how to send a signal, but nothing about receiving one, and doesn't use arexx.class. The example on amigaos wiki (link not handy) shows how to receive messages with arexx.class but not how to send messages. I only have half of what I need.

I will keep searching for some examples. I think the NetSurf browser may have some of what I need.

Thanks guys!

PJS
PJS's picture
Offline
Last seen: 4 years 11 months ago
Joined: 2012-12-09 18:38
@mritter0 We did a class and

@mritter0

We did a class and written tutorial on sending and receiving
ARexx messages (as well as Macros) at the AmiWest
programming days a few years back. You can see the
tutorial page on the Hyperion wiki here:

http://wiki.amigaos.net/wiki/AmiWest_Lesson_8

Thanks,

PJS

mritter0
mritter0's picture
Offline
Last seen: 2 years 7 months ago
Joined: 2014-04-21 21:15
Thanks, PJS. That is exactly

Thanks, PJS. That is exactly what I needed.

Log in or register to post comments