Relaunching program

There are a lot of excellent suggestions in this thread, but are these methods documented anywhere, or did most of us just come up with these ideas independently based on observation of other applications?

Druck et al suggested variations of

If only one copy of an application can be run, it’s because it’s specifically written to listen out for a wimp message indicating a new instance has started, and then immediately sending it a quit message.

As others have said, this is inflexible and destructive (consider Run <Obey$Dir>.!RunImage %*0), and is not necessarily compatible with localisation (at least it’s easy to get that wrong). There’s a more flexible way that I’ve been using for twenty years:

This allows various things to be negotiated among instances including Dynamic Area names, hot keys and Scrap directories, and I commend it to the House.

In particular, this allows instances to decide which should continue (the new one if it has command-line params such as a file to load; the old one if it’s still editing something; both if both these things are true) and the new instance could choose to hide its icon until the previous instance quits, masquerading as a multi-file program.

Getting back to the original question, assuming it’s still relevant:

I need to launch the second copy after a delay, so that the launching program has time to quit before the second copy does its check.

Would Filer_Run fit the bill?

The first copy issues a Filer_Run to start a new copy of itself and then calls Wimp_CloseDown. The Filer_Run won’t be executed until control is returned to the Wimp by which time the first copy must have finished closing down.

Good answer. The -noshift switch is recommended, which has been available since RO4.1 in 2001.

[Monitor task starting messages and sent quit to new task]

As others have said, this is inflexible and destructive (consider Run <Obey$Dir>.!RunImage %*0),

That’s not very likely unless your your data load message handling is broken so the filer has to drop back using the filetype alias.

and is not necessarily compatible with localisation (at least it’s easy to get that wrong).

That wont be an issue unless you change your locale between running each copy.

There’s a more flexible way that I’ve been using for twenty years:

That is a good solution, but wasn’t around when I was writing most of my RISC OS stuff, more like 30 years ago now.

I think that I put commit-suicide-if-one-is-already-loaded into PipeDream 3 back when most of our users had floppies and impatiently double-clicked the application again.

Perhaps I shall now remove the single-instance nonsense from PipeDream 4…

That’s not very likely unless your your data load message handling is broken so the filer has to drop back using the filetype alias.

It’s absolutely common for single-file editors.

I have an ancient single-file editor that works the way I was describing – if it’s already on the Iconbar doing nothing when I double click on its App Dir, I don’t need another instance. But if it’s already editing something, then clearly I do need a new one.

And @RunTypes are not only used by the Filer. They are a FileCore concept, so equally apply to Wimp_StartTask which does not bother with DTP niceties.

wasn’t around when I was writing most of my RISC OS stuff, more like 30 years ago now.

No criticism implied. We stand on the shoulders of giants, etc.

Stuart surmised

Perhaps I shall now remove

The principle of least surprise is often forgotten. Also consider the American Customer Service Mantra – “Find a way to say ‘yes’”.

when I was writing most of my RISC OS stuff, more like 30 years ago now.

I looked at Fireworkz’ window handling code t’other day and pondered for a few seconds why it wasn’t using the Nested Window Manager to handle all the stacked document sub-windows, list boxes in dialogue boxes etc. Before I realised we didn’t have that back then, which is why Fireworkz has its own implementation.

Find a way to say ‘yes’”

Indeed, or JFDI

Peeps forget that !Madness existed for a serious reason – testing your pane handling.

These kids with their Nested Wimp don’t know they’re born! <climbs back into hole in road>

Peeps forget that !Madness existed for a serious reason – testing your pane handling.

And moving windows that happen to be positioned outside the visible area back into it. Such a useful tool :-)

Interesting use! I wrote this in 1993 for similar reasons:

AAsm on the Desktop is a bit of a tease… always invoked it with Obey files!

Was that not standard? It’s just FrontEnd.

However, behind it is my patched AAsm that treats LEADR as a filetype if <=&FFF, so source can instruct it to make the right file. (why didn’t it always work like that)