Relaunching program

I’m not sure if this is possible. I have a number of programs (in BASIC) that work together. At one point I need one of them to re-initialise itself. Because the Init code includes DIMs as well as setting up variables, I can’t just re-run the INIT. Instead I thought I would arrange for the program to launch a copy of itself and then quit.

While I got this to work, there is a problem in that these programs are coded so that two copies are not allowed to run simultaneously. The second copy will quit if there’s another copy running. So in this case the second copy quits, then the first one also quits. It does the check before the first Wimp_Poll.

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.

Options I’ve thought about are to delay the check until after polling loop starts – though I don’t know whether that is sufficient, or to create a relauncher application, that is given the name of the program to launch, and waits before doing so, either waiting until the original is no longer present, or for a time delay, or just until polling starts.

Any suggestions (apart from re-writing the init code to separate the DIMs from the rest)? I’m trying to avoid that option, because the system uses a number of libraries, and they also have init routines, that set up DIMs. Changing those to have two separate inits, means changing all the programs that share the libraries, not just the one I need to re-init.

At one point I need one of them to re-initialise itself. Because the Init code includes DIMs as well as setting up variables, I can’t just re-run the INIT. Instead I thought I would arrange for the program to launch a copy of itself and then quit.

Maybe I have missed soomething, but my approach to this is ….

SYS "Wimp_CloseDown",our_task%,!taskid%: CHAIN("!RunImage")

If you Wimp_Initialise a task with the same name as an existing task, the previous one is automatically replaced. Simples.

The Wimp looks after it all for you. If I run a second copy of !MultiTask or !Cat, it replaces the previous incarnation.

The two solutions above are probably much better than the one I thought of:
First program before launching second copy sets a system variable, the second program checks for it before checking for another copy it then just clears the variable (A delay in clearing it might be needed) this should allow for a third or more replacement.

At one point I need one of them to re-initialise itself. Because the Init code includes DIMs as well as setting up variables, I can’t just re-run the INIT

Make the DIM’s LOCAL inside a PROC/FN so they’re released when it exits back to your main loop:

REPEAT UNTIL FNquit
END

DEF FNquit
  LOCAL array1%(), array2%(), memblock% ...
  DIM array1%(5)
  DIM memblock% LOCAL 512

  PROCmain_code
  IF quit% THEN =TRUE
=FALSE

If you Wimp_Initialise a task with the same name as an existing task, the previous one is automatically replaced. Simples.

<shrugs>

D’you really want me to post a screenshot with the iconbar full of copies of Edit?

Each Wimp Initialise starts a new task. It doesn’t matter what the task is called.

Furthermore, the idea of simply replacing tasks with the same name doesn’t make sense (unsaved data, etc).

I think you’re mixing up task behaviour with module behaviour (which does replace, because There Can Be Only One in the RMA).

I think my comment was accurate. Some applications take special steps to have more than one icon bar icon when re-initialised.

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.

I think my comment was accurate. Some applications take special steps to have more than one icon bar icon when re-initialised.

I think it’s the other way round, some applications don’t take steps to ensure there is only one instance.
In some cases, it will depend on how the application is called as to whether it opens a sub window or a new instance. StrongED behaviour is a case in point.

Instead of launching and quitting one of them, it seems you can use the RUN command in a BASIC program. That clears most variables and restarts.

So DEF PROCrestart:RUN:ENDPROC may do the trick. Make sure you have finished everything before calling this. Also note that A% to Z% are not cleared by the RUN command so you can clear these yourself or use them to pass to the newly restarted program if needed.

The CLEAR command can also be used. Again this does not clear A%-Z% but you would need to be careful where this is used.

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.

That’s pretty much what I’m doing.

it seems you can use the RUN command in a BASIC program. That clears most variables and restarts.

I’ll check that one out – it sounds ideal.

I think my comment was accurate.

It wasn’t, though. ;)

I think it’s the other way round

Fixed that for you.

As I said, Wimp Initialise starts a new task. It doesn’t matter what the task is called.

Any task for which only one copy can run is specifically doing that behaviour for itself.

If anybody doubts this, feel free to throw together a dead simple Wimp program (or pick something simple like Edit or Calc ¹) and just keep double clicking on the icon to load it…until all doubt is removed.

¹ Does Calc still exist or is it just SciCalc these days?

it seems you can use the RUN command in a BASIC program. That clears most variables and restarts.

I prefer CHAIN because it specifies the program by name allowing the program to be replaced by a new one (to fix bugs for example).

I also use …

SYS "Wimp_CloseDown",our_task%,!taskid%:
PROCupgrade_data
CHAIN("!RunImage")

where I want the program to restart with upgraded facilities. A live HTTP server with new facities for example.

I copied the idea from BT who use the same concept to upgrade telephone exchange software, whilst keeping calls going etc.

Any task for which only one copy can run is specifically doing that behaviour for itself.

Indeed… most likely something like this (via this).

Oops! I thought it was a standard part of a multi-tasking program to listen out for message &400C2 and to quit if a task with the same name was being initialised but did not have the same task handle (i.e. it wasn’t being notified by itself).

Example:

     240 : Nameoftask$="Cat"
     250 : :
     260 : DIM tem% 40
     270 : !tem%=1
     280 : tem%!4=2
     290 : tem%!8=3
     300 : tem%!12=4
     310 : tem%!16=5
     320 : tem%!20=8
     330 : tem%!24=&502
     340 : tem%!28=&400C2
     350 : tem%!32=0
     360 : SYS "Wimp_Initialise",310,&4B534154,Nameoftask$,tem% TO ,ourtask
         :
     660 : :
     670 : REM Now the main loop
     680 : REM
     690 : WHILE NOT(quit%)
     700 :   SYS "Wimp_Poll",mask%,block% TO reason%
     710 :   CASE reason% OF
     720 :   WHEN 0
     730 :     PROCsvise
     740 :   WHEN 1:
     750 :     IF lk_open% THEN PROCredraw
     760 :   WHEN 2:
     770 :     SYS "Wimp_OpenWindow",,block%
     780 :     lk_open%=TRUE
     790 :   WHEN 3:
     800 :     SYS "Wimp_CloseWindow",,block%
     810 :     lk_open%=FALSE
     820 :   WHEN 6:PROCbuttons(block%)
     830 :   WHEN 7:PROCboxdragend
     840 :   WHEN 8:PROCkeypress(block%)
     850 :   WHEN 9:PROCmenuselect(block%)
     860 :   WHEN 17,18:PROCreceive(block%)
     870 :   ENDCASE
     880 : ENDWHILE
     890 : SYS "Wimp_CloseDown"
     900 : END
         :
    9700 : :
    9710 : REM .... Message discrimination
    9720 : REM
    9730 : DEF PROCreceive(b%)
    9740 : myr%=b%!8
    9750 : :
    9760 : CASE b%!16 OF
    9770 : WHEN 0:quit%=TRUE
    9780 : WHEN 1:PROCdatasave(b%)
    9790 : WHEN 2:PROCdatasaveack(b%)
    9800 : WHEN 3:PROCdataload(b%)
    9810 : WHEN 4:PROCdataloadack(b%)
    9820 : WHEN 5:PROCdoubleclick(b%)
    9830 : WHEN 8:PROCprequit(b%)
    9840 : WHEN &502:PROChelprequest(b%)
    9850 : WHEN &400C0
    9860 : WHEN &400C2:IF FNdup(b%+28) AND b%!4<>ourtask THEN quit%=TRUE
    9870 : ENDCASE
    9880 : :
    9890 : ENDPROC
    9900 : :
         :
   22700 : REM .... Zero terminated string read and duplication check
   22710 : REM
   22720 : DEF FNdup(ptr%)
   22730 : t$=""
   22740 : REPEAT
   22750 : t$=t$ + CHR$?ptr%:ptr% +=1
   22760 : UNTIL ?ptr%=0
   22770 : IF t$=Nameoftask$ THEN =TRUE ELSE =FALSE

I thought it was a standard part of a multi-tasking program to listen out for message &400C2 and to quit if a task with the same name was being initialised but did not have the same task handle (i.e. it wasn’t being notified by itself).

Not as far as I know.

It’s also backwards, because with the exception of developers who are testing software, users will generally expect the new instance that they unintentionally started up to back out from loading itself, and not the existing one that might have unsaved work, settings, calculations or whatever in it to exit without warning.

this !! doesn’t let me delete a post.

this !! doesn’t let me delete a post.

but you can still edit it to delete the text and substitute the word “Deleted”.

Still shameful, but to a lesser extent!

But don’t delete anything anyone has replied to, or it’ll look very silly!

It’s also backwards

This. It’s the newly started one that ought to be looking to see if something is already there, and if so, quitting itself.

Optional bonus, send some sort of message to the existing task to get it to show itself. Then the user rubbing the program will see it appear and not have to worry about what went on behind the scenes.

Then the user rubbing the program will see it appear

The sheer genie-us of it all?

;)

Just automangle again.

Going back to the original question, setting a system variable has been suggested. Another option is to use a command-line option, which avoids the need to delete the system variable. In this scenario the logic would work like this:

1. On starting, check special command-line option. If present, take no further action.
2. Otherwise, application checks to see if another task with the same name is running, and if found, will quit itself.
3. Before quitting, it could send a message to the previously-running task which could prompt that task to open its main window, appear on the iconbar (if hidden) etc.

I think we implemented something like this in Nominatim, which can be used in a hidden manner, not appearing on the iconbar. If the user runs a second copy, the first task will reveal itself.

Before quitting, it could send a message to the previously-running task which could prompt that task to open its main window, appear on the iconbar (if hidden) etc.

This can also be done without task-specific messages. PrintPDF does two things:

1. On loading, it does the same search through running tasks as described above for Launcher to see if there’s already an instance of PrintPDF present. If there is, then the copy that is in the process of loading quietly exits.

2. Once installed as a task, it listens for Message_TaskInitialise and on receipt, it checks to see if the initialising task is PrintPDF. If it is, it assumes that the initialising copy will correctly do as in point 1, and exit immediately. The installed task then opens its Choices dialogue.

Taken together, this ensures that there is only ever one copy of PrintPDF running. It also ensures that if that copy is running without an iconbar icon, then the Choices dialogue can be opened by running PrintPDF a second time from a Filer window.

setting a system variable has been suggested

Using system variables for this is generally a very bad idea. It’s easy for something to go wrong and for the variable to remain in a state which no longer reflects the state of the associated application. The Task Manager’s state should always be in step with what applications are actually running.

Using system variables for this is generally a very bad idea

I think this is suggested in the PRM but I can’t find it (haven’t looked too hard) but, as you say, it’s surely better to do as you describe for single-instance applications.

This. It’s the newly started one that ought to be looking to see if something is already there, and if so, quitting itself.

Ensuring that the something hasn’t been left around from a failed run is tricky, you need to make sure an instance is actually still running, which would require looking through a task enumeration.

Far, far easier is for the app to listen for task started messages which contains the name of the new task, and if it is the same, sent it a quit.

Optional bonus, send some sort of message to the existing task to get it to show itself. Then the user rubbing the program will see it appear and not have to worry about what went on behind the scenes.

The advantage of my method is the existing task then knows what has happened immediately and can decide to bring itself to the front if appropriate.