Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1983 > unrolled thread

Wimp_StartTask

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-06 09:32 +0100
    Re: Wimp_StartTask Martin Wuerthner <spamtrap@mw-software.com> - 2012-08-06 12:59 +0200
      Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-06 13:00 +0100
        Re: Wimp_StartTask Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-06 13:16 +0100
          Re: Wimp_StartTask Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-06 13:55 +0100
            Re: Wimp_StartTask Ian <Ian.Hamilton@AAUG.net> - 2012-08-06 14:05 +0100
          Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-06 14:38 +0100
            Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-07 19:02 +0100
          Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-06 14:57 +0100
            Re: Wimp_StartTask "David Holden" <SpamBin@apdl.co.uk> - 2012-08-06 14:23 +0000
              Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-06 15:48 +0100
                Re: Wimp_StartTask Ian <Ian.Hamilton@AAUG.net> - 2012-08-06 15:54 +0100
                Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-06 16:05 +0100
                Re: Wimp_StartTask Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-06 18:59 +0100
          Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-06 15:54 +0100
    Re: Wimp_StartTask "David Holden" <SpamBin@apdl.co.uk> - 2012-08-06 11:37 +0000
    Re: Wimp_StartTask Justin Fletcher <gerph@gerph.org> - 2012-08-07 22:09 +0100
      Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-08 08:49 +0100
        Re: Wimp_StartTask "David Holden" <SpamBin@apdl.co.uk> - 2012-08-08 09:49 +0000
          Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-08 11:04 +0100
          Re: Wimp_StartTask Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-08-08 11:39 +0100
          Re: Wimp_StartTask Justin Fletcher <gerph@gerph.org> - 2012-08-08 22:32 +0100
            Re: Wimp_StartTask "David Holden" <SpamBin@apdl.co.uk> - 2012-08-09 06:20 +0000
            Re: Wimp_StartTask druck <news@druck.org.uk> - 2012-08-12 09:18 +0100
        Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-08 11:32 +0100
          Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-08 11:57 +0100
            Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-08 13:07 +0100
              Re: Wimp_StartTask Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-08-08 14:31 +0100
                Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-08 15:53 +0100
                  Re: Wimp_StartTask "David Holden" <SpamBin@apdl.co.uk> - 2012-08-08 15:32 +0000
                    Re: Wimp_StartTask Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-08-08 17:35 +0100
                    Re: Wimp_StartTask Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-08 23:12 +0100
                  Re: Wimp_StartTask jgh@arcade.demon.co.uk (Jonathan Graham Harston) - 2012-08-08 23:15 +0100

Page 1 of 2  [1] 2  Next page →

#1983 — Wimp_StartTask

Can Wimp_StartTask start up a second instance of the app that calls it?

Alan


-- 
RISC OS - you know it makes cents

[toc] | [next] | [standalone]

#1986

In message <gemini.m8brqw003wvyv01qs.spamhater@keepyourfilthyspamtoyou 
rself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> 
wrote:

> Can Wimp_StartTask start up a second instance of the app that calls it?

Of course, why not? Why should it care whether it is the same 
application or another one? It simply starts up the task it is told to 
start up. Whether the task likes being started up more than once is an 
entirely different matter.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1988

Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In message <gemini.m8brqw003wvyv01qs.spamhater@keepyourfilthyspamtoyou 
> rself.co.uk>
>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> 
> wrote:
> 
> > Can Wimp_StartTask start up a second instance of the app that calls it?
> 
> Of course, why not? Why should it care whether it is the same 
> application or another one?

I didn't imagine it would. But I can't get it to work. I can start up any
other app, including second copies of apps already running, but not a second
copy of my own app. At the moment I can't understand how it can start up
normally but not from a Wimp_StartTask, hence my question. If the answer is
yes then somehow the problem is in my code.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1989

Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:
> I didn't imagine it would. But I can't get it to work. I can start up any
> other app, including second copies of apps already running, but not a second
> copy of my own app. At the moment I can't understand how it can start up
> normally but not from a Wimp_StartTask, hence my question. If the answer is
> yes then somehow the problem is in my code.

What happens when you try?  Your app isn't one that attempts to take over
task starting by an already-running instance, is it?  Like editors do when
you do *!Editor FileToEdit

I also vaguely remember something about Obey files being left open on some
OSes if they were still executing.  So if you do:
*!App.!Run
which does:
IconSprites <App$Dir>.!Sprites
Run <App$Dir>.!RunImage
| end of file

the RunImage line doesn't return until the app is quit, so the obey file
remains open.  If you try to run !App.!Run again, it might run into
problems.  There might be a flag to *Obey to prevent that.  But I can't
remember the details.

Theo

[toc] | [prev] | [next] | [standalone]

#1991

The following bytes were arranged on 6 Aug 2012 by Theo Markettos :

> I also vaguely remember something about Obey files being left open on some
> OSes if they were still executing.

You're allowed to open the same file many times over, as long as all
open requests are for read-only access.  As I can't imagine the Obey
file wanting write access, that shouldn't be a problem.

-- 
  __<^>__
 / _   _ \  I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1992

On Mon, 06 Aug 2012 13:55:16 +0100
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> The following bytes were arranged on 6 Aug 2012 by Theo Markettos :
> 
> > I also vaguely remember something about Obey files being left open
> > on some OSes if they were still executing.
> 
> You're allowed to open the same file many times over, as long as all
> open requests are for read-only access.  As I can't imagine the Obey
> file wanting write access, that shouldn't be a problem.
> 

There is a problem if the file handle for the !Run file is closed by
something else. When the application is eventually quit whichever file
now has that handle will be closed. That's why my !CloseIt application
warns you when trying to close a !Run file.

Ian

[toc] | [prev] | [next] | [standalone]

#1993

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:
> > I didn't imagine it would. But I can't get it to work. I can start up
any
> > other app, including second copies of apps already running, but not a
second
> > copy of my own app. At the moment I can't understand how it can start up
> > normally but not from a Wimp_StartTask, hence my question. If the answer
is
> > yes then somehow the problem is in my code.
> 
> What happens when you try?

Nothing. No error, no task, returns null taskhandle. If the task DOES start,
it doesn't get as far as the first line of main(), let alone call
Wimp_Initialise.

> Your app isn't one that attempts to take over
> task starting by an already-running instance, is it?  Like editors do when
> you do *!Editor FileToEdit

I'm not familiar with that particular example. My app is trying to
self-update. It downloads a newer copy of itself and starts the new version,
then waits for the newer one to broadcast a Wimp message telling it to quit.
There should be no overlap of any functionality - the old one does nothing
after starting the new, and the new one waits for the old to quit before
putting an icon on the icon bar.

> I also vaguely remember something about Obey files being left open on some
> OSes if they were still executing.

From my (admittedly very vague) memory, this was a problem in RISC OS 2 but
was fixed in RO3.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#2013

Nick Roberts <tigger@orpheusinternet.co.uk> wrote:

> In message
<gemini.m8c5vs00etj6f01qs.spamhater@keepyourfilthyspamtoyourself.co.uk>
>        Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:
> 
> > Nothing. No error, no task, returns null taskhandle. If the task DOES
> > start, it doesn't get as far as the first line of main(), let alone
> > call Wimp_Initialise.
> 
> Does the final Run command include an indirection?

No, it's just a straightforward call of the !RunImage.

However the problem seems to have sorted itself out for the moment during
the course of program development. I've absolutely no idea what caused it or
what the solution was. The oflas suggested it could have been a null
pointer, but the 'Syntax Error' was rather odd as I can't see how that could
be generated by a compiled program.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1994

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> What happens when you try?

OK, a bit more information. If I Wimp_StartTask the app from another
application, I get an error box saying "Syntax: ofla ofla..." etc.

So if the !Run file is run by double-clicking it works OK, if it's run with
Wimp_StartTask "Filer_Run..." it gives a Syntax error. Where do I start
looking?

And why is that error not given on the Wimp_StartTask call from the original
app?

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1995

On  6-Aug-2012, Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
wrote:

> So if the !Run file is run by double-clicking it works OK, if it's run
> with Wimp_StartTask "Filer_Run..." it gives a Syntax error. Where
> do I start looking?

You don't use Filer_Run, just the task path and name. eg.

SYS "Wimp_StartTask","<MyApp$Dir>.^.!MyApp"

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#1996

"David Holden" <SpamBin@apdl.co.uk> wrote:

> You don't use Filer_Run, just the task path and name. eg.
> 
> SYS "Wimp_StartTask","<MyApp$Dir>.^.!MyApp"

Same result I'm afraid. I was sure I'd read somewhere that Filer_Run was the
right way. My bad memory again no doubt.

Meanwhile Wimp_StartTask "Filer_Run <AnotherApp$Dir>.!Run" continues to
work.

I can easily find an alternative way of doing what I want, but now I'm
curious as to what could cause the "Syntax" error.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1997

On Mon, 6 Aug 2012 15:48:41 +0100
Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:

> "David Holden" <SpamBin@apdl.co.uk> wrote:
> 
> > You don't use Filer_Run, just the task path and name. eg.
> > 
> > SYS "Wimp_StartTask","<MyApp$Dir>.^.!MyApp"


> Meanwhile Wimp_StartTask "Filer_Run <AnotherApp$Dir>.!Run" continues
> to work.
> 
> I can easily find an alternative way of doing what I want, but now I'm
> curious as to what could cause the "Syntax" error.

Could it be the overall path length?

[toc] | [prev] | [next] | [standalone]

#1999

Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:

> I can easily find an alternative way of doing what I want, but now I'm
> curious as to what could cause the "Syntax" error.

I don't know what's wrong with your app, but just took a quick look at one
of mine that use to issue about 100 separate commands  - many of which
started other apps - just after I booted my machine.  

I issued all the commands via

   OSCLI("Do " + commands$)

where the commands in question had been stored in an array and were worked
through according to predefined delays.  A typical command was eg:

    "WimpTask Run <JN$Utilities>.Help.!StrongHlp"


So that leaves me wondering what the difference between "*Wimptask Run" and
the SWI you're using might be (it's years since I wrote my app, and can't
remember why I did it the way I did).  Also I don't recall which of the
commands I issued required the leading "*Do" to work properly.

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

[toc] | [prev] | [next] | [standalone]

#2000

Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:
> Meanwhile Wimp_StartTask "Filer_Run <AnotherApp$Dir>.!Run" continues to
> work.
> 
> I can easily find an alternative way of doing what I want, but now I'm
> curious as to what could cause the "Syntax" error.

AIUI Filer_Run adds a request to a queue.  When the Wimp next polls the
Filer, the Filer does the necessary Filer_Boot and Filer_Run operations that
are stored in that queue (for example, Filer_Run on a file will first offer
around DataOpen messages, not execute *@RunType_xxx as the CLI would). 
That means Filer_Run is not a task, since you can call it from the F12
prompt but will only get executed when you return to the desktop.

So I'm not too surprised that it isn't doing what you expect. 
Wimp_StartTask,"Filer_Run ..." may start a short-lived CLI task consisting
of just adding the parameters to the Filer queue and then exit.  If you
don't call Wimp_Poll anytime soon, nothing will appear to happen.  OTOH it
might go wrong through races or similar, I don't know - it feels like
there's plenty of opportunity for something bad to happen.

Theo

[toc] | [prev] | [next] | [standalone]

#1998

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> There might be a flag to *Obey to prevent that.  But I can't remember the
> details.

I think it's *Obey -c ....

where -c  tells Obey to cache the Obey file.

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

[toc] | [prev] | [next] | [standalone]

#1987

On  6-Aug-2012, Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
wrote:

> Can Wimp_StartTask start up a second instance of the app that calls it?

Wimp_StartTask will start whatever task it is told to start, it is
irrelevant to the Wimp what the calling task is.

However if you intend to start a second instance of a task then you should
make sure that the task is capable of running multiple instances. eg. don't
use 'raw' OS variables or any shared resources which could cause conflict.
Make sure that the program doesn't leave any files open except when they're
actually being accessed, etc.

Naturally all of this will depend on the nature of the task.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#2014

On Mon, 6 Aug 2012, Alan Wrigley wrote:

> Can Wimp_StartTask start up a second instance of the app that calls it?

Yes. It can start anything. However, there are caveats, as documented in 
the PRMs. In particular - you can only call this SWI from USR mode, and 
you can only call it when you are in a Wimp task in the first place.

Using the SWI outside of a Wimp Task, or from within a non-USR mode will 
not work, as documented in the PRM.

However, I can tell you what will happen (as I remember the 
implementation) if you are in either state.

If you call the SWI from outside of USR mode (eg SVC mode) then the SWI 
will install a Callback handler and use this to handle the return, exiting 
through the same handler that Wimp_Poll does. The SWI will return without 
setting the task handle, because it will expect that the call return will 
be performed by the Callback handler. When you return to USR mode, the 
Callback handler will be triggered and the task executed, at which point 
the registers will be updated to return the relevant handle. This may 
corrupt whatever R0 state was being restored in the USR mode environment, 
and may have Bad Effects for your application.

If you call the SWI from outside of a Wimp Task, the task that you have 
tried to start may report that it cannot do so.

There is an additional caveat which is non-obvious unless you've thought 
about what's going on. Executing a Wimp_StartTask will switch to the task 
immediate it begins executing and only returns control to the caller when 
the task initialises with the Wimp. Executing a Wimp_StartTask from 
within a TaskWindow does not allow the TaskWindow an opportunity to 
relinquish control of the task, prior to version 0.72 of the TaskWindow 
module (fixed '03).

http://select.riscos.com/SelChanges/All/TaskWindow.html
http://select.riscos.com/prm/desktop/taskwindow.html

This will also apply to any other preemption system.

You mentioned that you get a Syntax error, rather than the message that 
you were expecting - without mentioning what language you are using. You 
later mention that you have 'main()' but say nothing else - which might 
narrow it to a C-like language, but could really be anything. In any case, 
is this odd error possibly because you're invoking the program wrongly?

If you were to invoke it with the wrong command line then you wouldn't get 
the correct current directory. I'm specifically thinking of the invoking
the command without a 'run' prefix. For example:

SYS "Wimp_StartTask","<MyProg$Dir>.!RunImage"

This is, under all circumstances, wrong - you state that you're invoking 
the !RunImage in a follow up post, and this is wrong. If you execute the 
!RunImage, you take the WimpSlot of the 'next' task, which could be just 
about anything, and you may or may not like it. Never do that. Always 
invoke via the !Run where you set up the wimp slot correctly. As an aside, 
if you'd used a Filer_Run, of course, the WimpSlot would be increased 
appropriately for the application, but only on Filer 2.58 and beyond...

http://select.riscos.com/SelChanges/All/Filer.html

Additionally, and more importantly, the above form (which was suggested by 
someone else) is wrong because it doesn't include a 'run' prefix, as I 
mentioned. The correct syntax is:

SYS "Wimp_StartTask","/<MyProg$Dir>.!RunImage"
or
SYS "Wimp_StartTask","Run <MyProg$Dir>.!RunImage"

The syntax that using the bare system variable name will expand to 
something akin to:

ADFS::MyDisc.$.Bingle.!FancyProg.!RunImage

which will then be executed. This selects ADFS as the temporary filesystem 
and attempts to run ":MyDisc.$.Bingle.!FancyProg.!RunImage", which would 
work because the temporary filesystem is ADFS. However, if you then try to 
use that filename to find other files, you'll break because the temporary
filesystem is no longer selected. Additionally, the filename that you have 
now been invoked with is ":MyDisc.$.Bingle.!FancyProg.!RunImage" which 
means if you were to try the same thing again, you'd be executing:

SYS "Wimp_StartTask", ":MyDisc.$.Bindle.!FancyProg.!RunImage" which might
not be what you expect.

Temporary filesystems are a confusing and non-obvious part of the filing 
system interface, but one you must be aware of when writing robust and 
correct code.

There are (probably) quite curious things that you could do with this 
which might cause obscure errors. There are way more than this, but here's 
a fun little one. Create a RAM disc:

----
*Echo echo hello { > RAM:$.hello }
*SetType RAM:$.hello Obey
*RAM:%.hello
'hello' is a file
*/RAM:%.hello
hello
----

In case you missed it, the RAM:%.hello is 'select RAM as temporary 
filesystem and execute %.hello'. '%' means don't alias the command, but 
additionally the '.' is special cased as a command to mean 'cat' before 
anything else, so '%.' becomes a 'cat', which tries to list the directory 
'hello', which is a file - and so you get an error.

Why would you do that? Well, it's not a question of why, but being aware 
that there's some crazy stuff that you can do, and you need to cater for. 
It may be a little contrived, but it is one example of where not expecting 
such things will come back and bite you.

You also mention that you're invoking the application after having updated 
yourself. Obviously this has its own implications, but have you actually
closed the file you were writing before you try invoking yourself? If the
first application still has the file open for writing, you won't be able 
to execute it - you cannot read and write files at the same time. I'm
pretty sure you wouldn't see the Syntax: ofla message because of that, but 
then I can't think what else might do that.

-- 
Gerph <http://gerph.org/>
... It's my life; Yeah I know it's not a perfect one,
     but it's a life I can live with.

[toc] | [prev] | [next] | [standalone]

#2017

Justin Fletcher <gerph@gerph.org> wrote:

> You mentioned that you get a Syntax error, rather than the message that 
> you were expecting - without mentioning what language you are using. You 
> later mention that you have 'main()' but say nothing else - which might 
> narrow it to a C-like language, but could really be anything. In any case,

> is this odd error possibly because you're invoking the program wrongly?

It's a Norcroft-compiled C++ Wimp task. The app was starting up normally
when double-clicked from the Filer and AFAICS there's no difference in the
start-up procedure from dozens of other apps I've written over the years.

> If you were to invoke it with the wrong command line then you wouldn't get

> the correct current directory. I'm specifically thinking of the invoking
> the command without a 'run' prefix. For example:
> 
> SYS "Wimp_StartTask","<MyProg$Dir>.!RunImage"
> 
> This is, under all circumstances, wrong - you state that you're invoking 
> the !RunImage in a follow up post, and this is wrong.

No, I was responding to someone's query about the contents of the !Run file,
which does of course invoke the !RunImage in its last line.

Before posting my original query I had tried all combinations I could think
of - I normally try everything before I ask a question here because problems
are nearly always caused by an oversight. So I had already tried
Wimp_StartTask with "/<MyApp$Dir>.!Run" and "Run <MyApp$Dir>.!Run" before
trying "Filer_Run <MyApp$Dir>.!Run". Following Dave Holden's post I changed
to "<MyApp$Dir>.^.!MyApp" but that made no difference.

> Additionally, and more importantly, the above form (which was suggested by

> someone else) is wrong because it doesn't include a 'run' prefix, as I 
> mentioned. The correct syntax is:
> 
> SYS "Wimp_StartTask","/<MyProg$Dir>.!RunImage"
> or
> SYS "Wimp_StartTask","Run <MyProg$Dir>.!RunImage"
> 
> The syntax that using the bare system variable name will expand to 
> something akin to:
> 
> ADFS::MyDisc.$.Bingle.!FancyProg.!RunImage

Indeed, and I'm normally aware of all this stuff but I don't use
Wimp_StartTask on a regular basis so I was confused when nothing worked.

> You also mention that you're invoking the application after having updated

> yourself. Obviously this has its own implications, but have you actually
> closed the file you were writing before you try invoking yourself?

Oh yes, there are no files open. The update process is download update,
unpack it, copy it over the existing one (after taking a backup), then start
it up. Checking for updates is the first thing it does and no files are
opened until the process is complete. When the new one runs it tells the old
one to die before it puts itself on the icon bar.

> I'm pretty sure you wouldn't see the Syntax: ofla message because of that,
> but then I can't think what else might do that.

I'm guessing that something in the !Run file triggered it (though it's just
a standard file with no unusual commands), but as it all now seems to be
working I don't suppose I will ever know. It's been a useful discussion
anyway.

Thanks
Alan


-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#2021

On  8-Aug-2012, Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
wrote:

> Oh yes, there are no files open. The update process is download update,
> unpack it, copy it over the existing one (after taking a backup), then
> start it up. Checking for updates is the first thing it does and no files
> are opened until the process is complete. When the new one runs it
>tells the old one to die before it puts itself on the icon bar.
>
> I'm guessing that something in the !Run file triggered it (though it's
> just a standard file with no unusual commands), but as it all now seems
> to be working I don't suppose I will ever know. It's been a useful
> discussion anyway.

That triggered a thought. ISTR that if a !Run file contains *anything* after
the line that actually runs the program then it will remain open until the
program terminates. Normally this wouldn't matter, but if you try to run a
second instance then the !Run file will still be open.

I think this even applies if there's a LF at the end of the final line.
Certainly most programs (and all of mine) just end the !Run file at the end
of the final line with no line terminator.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#2022

"David Holden" <SpamBin@apdl.co.uk> wrote:

> That triggered a thought. ISTR that if a !Run file contains *anything*
after
> the line that actually runs the program then it will remain open until the
> program terminates. Normally this wouldn't matter, but if you try to run a
> second instance then the !Run file will still be open.
> 
> I think this even applies if there's a LF at the end of the final line.
> Certainly most programs (and all of mine) just end the !Run file at the
end
> of the final line with no line terminator.

Interesting. I haven't heard that one before and all my !Run files are
terminated by LF. However, as I said earlier it seems to be working now and
the LF is still there.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web