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

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

System variables cleanup

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

Contents

  System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-27 16:11 +1300
    Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-27 05:13 +0100
      Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-27 18:29 +1300
    Re: System variables cleanup Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-11-27 21:55 +0000
      Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-28 12:27 +1300
        Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-29 06:33 +0100
          Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-30 00:29 +1300
            Re: System variables cleanup Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2011-11-29 13:14 +0000
              Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-30 11:50 +1300
                Re: System variables cleanup Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2011-11-29 23:22 +0000
                  Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-11-30 13:19 +1300
                    Re: System variables cleanup Nick Roberts <tigger@orpheusinternet.co.uk> - 2011-11-30 21:41 +0000
                Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-30 08:33 +0100
                Re: System variables cleanup Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-11-30 21:38 +0000
                  Re: System variables cleanup "David Holden" <SpamBin@apdl.co.uk> - 2011-12-01 08:20 +0000
                Re: System variables cleanup Vince M Hudd <vinceh@softrock.co.uk> - 2011-12-01 16:00 +0000
                  Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-02 08:38 +0100
                    Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-12-03 12:05 +1300
                      Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-03 06:31 +0100
                        Re: System variables cleanup Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2011-12-03 10:02 +0000
                        Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-12-04 11:39 +1300
            Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-30 08:20 +0100
              Re: System variables cleanup Ron <beeb@woosh.co.nz> - 2011-12-01 10:22 +1300
              Re: System variables cleanup Chris Johnson <chrisjohnson+news@spamcop.net> - 2011-11-30 23:59 +0000
                Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-01 07:21 +0100
          Re: System variables cleanup jgh@arcade.demon.co.uk (Jonathan Graham Harston) - 2011-12-01 14:15 +0000
            Re: System variables cleanup Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-02 08:35 +0100
    Re: System variables cleanup druck <news@druck.org.uk> - 2011-11-27 22:47 +0000
      Re: System variables cleanup druck <news@druck.org.uk> - 2011-11-30 20:19 +0000

Page 1 of 2  [1] 2  Next page →

#1070 — System variables cleanup

A recent post mentioned how Zap leaves System variables set and I
think there are other apps doing this.
It doesn't seem a correct thing to do, I think when you terminate
a program it should remove it's system variables.
I am knowledgable about system variables now, but I can remember 
a time when it was a frustration I had to put up with.
If someone must use Zap not StrongED to view a text file upon 
clicking, the program can be started at boot time anyway.
I can remember on slower machines it was a benefit to have !Edit
do the job of reading a ReadMe.

It is probably difficult to get all the programs changed to my
suggested protocol, but maybe there has been a utility made
that can check system variables against running programs and
then remove them, Or perhaps if you wanted to run Zap and
Stronged side by side and just drag files to the desired
editor you might want to unset some of the variables.

I'm thinking now of a menu with Unset Zap variables,Unset Edit
and so on.
I guess this is related to a System configuration where you
tick your desired default browser etc, but needs to be accessible
so things can be set straight at any time.

Thanks  Ron M. 

[toc] | [next] | [standalone]

#1071

On 27/11/2011 04:11, Ron wrote:

> I'm thinking now of a menu with Unset Zap variables,Unset Edit
> and so on.

The pain in the ass is when a variable like:
   MyApp$Running
is set, and unset on exit but not unset upon a crash.

Anyway, you might find you can get rid of all the Zap stuff with a 
simple command like:
   *Unset Zap*

 From memory, of course, I'm using the PC right now...


Best wishes,

Rick.

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

#1072

In message <4ed1b8cc$0$2520$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 27/11/2011 04:11, Ron wrote:
> 
> > I'm thinking now of a menu with Unset Zap variables,Unset Edit
> > and so on.
> 
> The pain in the ass is when a variable like:
>    MyApp$Running
> is set, and unset on exit but not unset upon a crash.
> 
> Anyway, you might find you can get rid of all the Zap stuff with a 
> simple command like:
>    *Unset Zap*
> 
>  From memory, of course, I'm using the PC right now...
> 
> 
> Best wishes,
> 
> Rick.

If that works, it would unset ZapFonts$Path which is needed by other apps.
There is the alias's to unset/set as well. But still, a finite list.

BTW Rick, have you checked out !MoveWind, you mentioned once about
needing a window brought to the front. I was using AltClick, but that
has stopped working for some reason and !Movewind is better anyway. 

It is possible on Ubuntu to do a similar thing, it can be the only way
to get a window back on screen in their case.

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

#1077

In message <a901803852.beeb@ron1954.woosh.co.nz>
 on 27 Nov 2011 Ron  wrote:

> A recent post mentioned how Zap leaves System variables set and I
> think there are other apps doing this.
> It doesn't seem a correct thing to do, I think when you terminate
> a program it should remove it's system variables.

Unfortunately the programmer cannot read the mind of the user, and there is
no clear guidance from Acorn on this.

I guess you are mainly thinking about Alias$@RunType_ variables, which
control which applications are run when double-clicking on a file?

Some applications set these when being booted.  Some only set them if not
already set to something else, others just set anyway.  If you keep
application A and application B in the same directory and boot both, it all
depends on which is booted first and how they each behave as to which
application grabs the files.

And many programmers assume that if you run the application it's because you
like it and you would prefer to use it for the appropriate filetypes
thereafter, which is not unreasonable on the whole.

> If someone must use Zap not StrongED to view a text file upon clicking, the
> program can be started at boot time anyway.

Why should it have to be?  I like to keep my iconbar clear until these things
are needed.  A simpler solution is just not to install StrongED in the first
place!

> It is probably difficult to get all the programs changed to my suggested
> protocol, but maybe there has been a utility made that can check system
> variables against running programs and then remove them.

Tricky: you have to know what the system variables are all for, and who
really owns them.  I don't think this is really workable.

> Or perhaps if you wanted to run Zap and Stronged side by side and just drag
> files to the desired editor you might want to unset some of the variables.

Remember that Alias$@RunType_ does not apply to applications that are already
running.  Before the Filer invokes the run type information, a message is
broadcast round all applications which are already running asking if any
would like to handle the file.  System variables are not going to help with
this, as if NetSurf is running, say, there's no way Oregano will be loaded to
view the HTML file as NetSurf will handle it.

Again, the OS assumes that you'd prefer to use the application you've already
got loaded.  If you have two suitable applications loaded, it all depends on
what order the Wimp passes the message round in.

> I guess this is related to a System configuration where you tick your
> desired default browser etc, but needs to be accessible so things can be
> set straight at any time.

I think you'd be best off outlining the problem on the RISC OS Open Ltd
forums, in the Wishlist section.

I could envisage an improved Filer which would have a friendly way of
allowing the user to state his/her preferences for applications to handle
different sorts of files.  This could also control which applications are
polled first when broadcasting the message offering a file.  There's some
discussion on proposals for a new Filer going on right now so this may be the
time to get your suggestions in!

But include examples of real practical issues: what happens at present which
you dislike, so that folk can come up with the best way to fix it. Don't go
straight in suggesting a particular technical fix -- it may not be the best
design.

-- 
Matthew Phillips
Durham

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

#1081

In message <63e5e63852.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <a901803852.beeb@ron1954.woosh.co.nz>
>  on 27 Nov 2011 Ron  wrote:
> 
> > A recent post mentioned how Zap leaves System variables set and I
> > think there are other apps doing this.
> > It doesn't seem a correct thing to do, I think when you terminate
> > a program it should remove it's system variables.
> 
> Unfortunately the programmer cannot read the mind of the user, and there is
> no clear guidance from Acorn on this.
> 
> I guess you are mainly thinking about Alias$@RunType_ variables, which
> control which applications are run when double-clicking on a file?
> 
> Some applications set these when being booted.  Some only set them if not
> already set to something else, others just set anyway.  If you keep
> application A and application B in the same directory and boot both, it all
> depends on which is booted first and how they each behave as to which
> application grabs the files.
> 
> And many programmers assume that if you run the application it's because you
> like it and you would prefer to use it for the appropriate filetypes
> thereafter, which is not unreasonable on the whole.
>
Yes but (similar to the next comment) why should it be necessary to hide
an application so that it's !Boot's variable setting doesn't ensue.

Likewise for apps that change the IconSprites.

One answer might be to shift the offenders from !Boot to !Run on each
problem app.
 
> > If someone must use Zap not StrongED to view a text file upon clicking, the
> > program can be started at boot time anyway.
> 
> Why should it have to be?  I like to keep my iconbar clear until these things
> are needed.  A simpler solution is just not to install StrongED in the first
> place!
>

 
> > It is probably difficult to get all the programs changed to my suggested
> > protocol, but maybe there has been a utility made that can check system
> > variables against running programs and then remove them.
> 
> Tricky: you have to know what the system variables are all for, and who
> really owns them.  I don't think this is really workable.
> 
> > Or perhaps if you wanted to run Zap and Stronged side by side and just drag
> > files to the desired editor you might want to unset some of the variables.
> 
> Remember that Alias$@RunType_ does not apply to applications that are already
> running.  Before the Filer invokes the run type information, a message is
> broadcast round all applications which are already running asking if any
> would like to handle the file.  System variables are not going to help with
> this, as if NetSurf is running, say, there's no way Oregano will be loaded to
> view the HTML file as NetSurf will handle it.
> 
> Again, the OS assumes that you'd prefer to use the application you've already
> got loaded.  If you have two suitable applications loaded, it all depends on
> what order the Wimp passes the message round in.
> 
Thanks, that is worth remembering.

> > I guess this is related to a System configuration where you tick your
> > desired default browser etc, but needs to be accessible so things can be
> > set straight at any time.
> 
> I think you'd be best off outlining the problem on the RISC OS Open Ltd
> forums, in the Wishlist section.
> 
> I could envisage an improved Filer which would have a friendly way of
> allowing the user to state his/her preferences for applications to handle
> different sorts of files.  This could also control which applications are
> polled first when broadcasting the message offering a file.  There's some
> discussion on proposals for a new Filer going on right now so this may be the
> time to get your suggestions in!
> 
> But include examples of real practical issues: what happens at present which
> you dislike, so that folk can come up with the best way to fix it. Don't go
> straight in suggesting a particular technical fix -- it may not be the best
> design.
>
Yes, it may be a case of isolating the problem first. In your first comment
that there has never been any protocol set, is possibly the cause.

Thanks     Ron M.
 

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

#1088

On 28/11/2011 00:27, Ron wrote:

> Yes, it may be a case of isolating the problem first. In your first comment
> that there has never been any protocol set, is possibly the cause.

I'm having trouble following the problem here. For example, on my "bare" 
system I have !Edit autostart and iconbar itself. It gets text files, 
and being auto-started, no delays.

When I dev code, I quit !Edit and load !Zap. Then Zap gets the text 
files. I can see the problem where you might want to quit Zap and have 
textfiles start !Edit again (fix: load Edit ??) but now you're adding a 
*lot* of complexity for a smallish problem. Likewise, it might be *nice* 
for plain text files to go to Edit, with .s, .c, and .h files to go to 
Zap (actually <app>.c.<file> but you know what I mean...). As they're 
all &FFF it's not really possible without screwing around giving them 
different types and hoping it doesn't break anything. Oh, and knowing if 
I want to load a code file into Edit to just look up something, it's now 
that much more difficult.

There was a discussion on the BBC mailing list a while back where 
JGHarston and myself really don't see eye to eye - and this is the 
extension to use for tokenised BBC BASIC files. On my system, it is 
".basic" which loads into a program of mine to detokenise and toss to 
Notepad. I can't use the suggested ".bas" for that will auto-start 
VisualBasic (the wrong one, I should add - I have two versions 
installed) which then chokes on Acorn style BASIC files. So this 
question of what-application-works-with-what-file is not a specifically 
RISC OS problem.

And for what it is worth, I quite like the RISC OS method. It is 
flexible, it doesn't need "associations" to be set up between the filer 
and the application [which, actually, would be liable to fail anyway 
given RISC OS doesn't really mind where software puts itself, so it is 
better to let booted software auto-link itself, else you risk 
rearranging your programs to find everything buggered up].


Best wishes,

Rick.

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

#1089

In message <4ed46eb6$0$5667$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 28/11/2011 00:27, Ron wrote:
> 
> > Yes, it may be a case of isolating the problem first. In your first comment
> > that there has never been any protocol set, is possibly the cause.
> 
<snip>

> And for what it is worth, I quite like the RISC OS method. It is 
> flexible, it doesn't need "associations" to be set up between the filer 
> and the application [which, actually, would be liable to fail anyway 
> given RISC OS doesn't really mind where software puts itself, so it is 
> better to let booted software auto-link itself, else you risk 
> rearranging your programs to find everything buggered up].
> 
It is manageable, but not correct.
If an editor has not been loaded, Zap will set the RunType for FFF 
to ZAP just because a directory with !Zap in it has been opened.
That is the equivalent of presetting Zap as the default Editor
in say a !Boot config setting, which is what you dont like.

There are other apps that change your range of filetype icons for
you because you happened to open its parent directory.
A similar presumption takes place.

The result is hiding these apps deeper, and perhaps resorting to
shortcuts or links, which shouldn't really be needed.

In the case of Zap, It has a complex !Boot and !Run - very hard
to follow and make any change to.

As Matthew stated, you might not want to start an editor at all,
and I think the only option left would be to set the preferred
System variable in a saved config so that the first time you
click on a text file the right editor starts up.
The alternative is to line your apps up in the order you
will come across them so their !Boot does their thing.

I agree it's not much of a problem, we always use an editor,
!Netsurf has no competition etc.
I think if you start !Phoenix after !Netsurf, it takes over
clicks on HTML. That is another case where you might want to 
have a preference one way or another.

Cheers  Ron M.

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

#1091

Ron <beeb@woosh.co.nz> wrote:

> If an editor has not been loaded, Zap will set the RunType for FFF 
> to ZAP just because a directory with !Zap in it has been opened.

But this is PRECISELY how RISC OS is supposed to work.

If applications followed your suggestion of unsetting their variables when
they quit, then there will come a point where double-clicking files will
have no effect.

If you must have more than one application that runs a certain type of file,
this is not a fault of the system or the applications but your choice. The
solution is to edit the !Boot file to disable the variable setting for all
editors apart from the one that you want to always start up by default.

Alan

-- 
RISC OS - you know it makes cents

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

#1098

In message <gemini.lvfbfw00a4wyv0078.spamhater@keepyourfilthyspamtoyourself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:

> Ron <beeb@woosh.co.nz> wrote:
> 
> > If an editor has not been loaded, Zap will set the RunType for FFF 
> > to ZAP just because a directory with !Zap in it has been opened.
> 
> But this is PRECISELY how RISC OS is supposed to work.
>
So it /is/ written somewhere? 
 
> If applications followed your suggestion of unsetting their variables when
> they quit, then there will come a point where double-clicking files will
> have no effect.
> 
Correct, but there is probably no reason to quit the application,
other than to get it out of the way of a rival.

There is an option where the System config could hold preferred
Run types until an application  forces it otherwise. An app
could read any existing runtype and replace it on quitting.
I am not a fan of extra un-needed extras though.
Also I certainly wouldn't like to see program launchers like
other Platforms use.

If package managers become the norm on RISC OS, the function of adding
its runtype to the System Boot Config to add it to the menu for any
group would allow user prefs. That means you would have to have an
unpackager for removal unless they are easly deleteable. Then there
is the problem if someone deleted an entry, how to put it back
without running the package installer again.

But I think simple as possible is best.
 
> If you must have more than one application that runs a certain type of file,
> this is not a fault of the system or the applications but your choice. The
> solution is to edit the !Boot file to disable the variable setting for all
> editors apart from the one that you want to always start up by default.
> 
Yes we have many apps that can open images, text, html, spreadsheets
so it will probably be the way to go.

Cheers   Ron M.


 

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

#1099

Ron <beeb@woosh.co.nz> wrote:

> There is an option where the System config could hold preferred
> Run types until an application  forces it otherwise. An app
> could read any existing runtype and replace it on quitting.

If I understand you correctly, that's sort of how it can work now. Let's say
App A and App B can both handle Widget files. App A sets an Alias$@RunType
so that if you double-click a Widget file it runs App A. But if you then
quit App A and run App B, double-clicking a Widget file will load it into
App B for as long as App B is running, but will re-run App A when App B is
quit.

However, for that to work, App B must not set the Alias$@RunType (which you
can enforce by editing the !Boot and !Run files), so the previous setting
remains intact. Is that the sort of behaviour you meant?

Alan 

-- 
RISC OS - you know it makes cents

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

#1100

In message <gemini.lvg3m800vvl7t0078.spamhater@keepyourfilthyspamtoyourself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:

> Ron <beeb@woosh.co.nz> wrote:
> 
> > There is an option where the System config could hold preferred
> > Run types until an application  forces it otherwise. An app
> > could read any existing runtype and replace it on quitting.
> 
> If I understand you correctly, that's sort of how it can work now. Let's say
> App A and App B can both handle Widget files. App A sets an Alias$@RunType
> so that if you double-click a Widget file it runs App A. But if you then
> quit App A and run App B, double-clicking a Widget file will load it into
> App B for as long as App B is running, but will re-run App A when App B is
> quit.
> 
> However, for that to work, App B must not set the Alias$@RunType (which you
> can enforce by editing the !Boot and !Run files), so the previous setting
> remains intact. Is that the sort of behaviour you meant?
> 
> Alan 
> 
I dont think it is wrong that an app sets a runtype when the program is 
actually run, otherwise it would lose it's rightful purpose.
I think the premature setting of a runtype from an App's boot (likewise
A range of iconsprites)is a bit presumptuous and unexpected behaviour
is the result.

Going back to my original thought of a possible utility, An obey file
could set your expected default runtypes, so for example if Netsurf is 
running and you want Phoenix running as well and you are happy enough
just to drag html to its Iconbar icon a hit on the panic button 
would reset your default runtypes and netsurf would resume it's
usual actions.  (untested)

A bit harder would be resurrecting iconsprites.

The trouble with editting apps, they may be updated occasionly,
and you would have to keep a record of patches somewhere.

Another way might be to use a something like Dave Thomas's !Makro
to assign a commonly used requirement to a button. 

Thanks,   Ron M.

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

#1120

In message <5dbbfb3952.beeb@ron1954.woosh.co.nz>
       Ron <beeb@woosh.co.nz> wrote:

> In message
> <gemini.lvg3m800vvl7t0078.spamhater@keepyourfilthyspamtoyourself.co.uk>
>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
> wrote:
> 
> > Ron <beeb@woosh.co.nz> wrote:
> > 
> > > There is an option where the System config could hold preferred
> > > Run types until an application  forces it otherwise. An app could
> > > read any existing runtype and replace it on quitting.
> > 
> > If I understand you correctly, that's sort of how it can work now.
> > Let's say App A and App B can both handle Widget files. App A sets
> > an Alias$@RunType so that if you double-click a Widget file it runs
> > App A. But if you then quit App A and run App B, double-clicking a
> > Widget file will load it into App B for as long as App B is
> > running, but will re-run App A when App B is quit.
> > 
> I dont think it is wrong that an app sets a runtype when the program
> is  actually run, otherwise it would lose it's rightful purpose.

The one time when an application doesn't need an Alias$@RunType set is
when it is actually running, as it will (if properly written), handle
the open message for double-clicked files internally.

Alias$@RunType is only of use when an application isn't running - it
well the Wimp what application to run if nothing handles the open
message.

-- 
Nick Roberts           tigger @ orpheusinternet.co.uk           

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

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

#1104

On 29/11/2011 23:50, Ron wrote:

>> But this is PRECISELY how RISC OS is supposed to work.
> So it /is/ written somewhere?

Source code? Style guide? PRMs? Every proper app ever written?

Yeah, it's written somewhere... ;-)


> There is an option where the System config could hold preferred
> Run types until an application  forces it otherwise.

Err... weren't you just arguing against an app overriding something 
already defined?


> An app could read any existing runtype and replace it on quitting.

Mmm, I actually have an idea.

No, seriously, I do. And it might be pretty simple to implement. Like 
REALLY simple, and compatible.


Take one star command:
   *FileProtect [ON|OFF]

When FileProtect is *OFF*, all Set AliasBlah actions are obeyed. The 
current behaviour.

When FileProtect is *ON*, if an application sets an action to a file 
(RunAction, etc) and there is *currently* a defined action for that 
specific filetype, the action being applied will be silently dropped.

Thus meaning:
   In !Boot files, it will have no effect.
   In !Run files, files will load into that app as it is loaded, but
   when the app is quit, previous behaviour will resume (as the
   RunAction will not have been touched).


To my mind, this is the simplest and most compatible way of dealing with 
this solution, and it only needs a new command and some tweaks to the 
*Set code.


[note: I specifically don't specify a config option as I would expect 
the FileProtect ON to be at the end of a desktop boot sequence, once all 
your favourite apps have been booted and associations set up]


> If package managers become the norm on RISC OS,

I hope so, pointy-clicky installs are much tidier than alternatives, 
especially now so many applications have "resources".


> That means you would have to have an unpackager for removal

...part of what a package manager can do?


> But I think simple as possible is best.

How does the above idea sound?


Best wishes,

Rick.

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

#1118

In message <7793f33952.beeb@ron1954.woosh.co.nz>
 on 29 Nov 2011 Ron  wrote:

> In message <gemini.lvfbfw00a4wyv0078.spamhater@keepyourfilthyspamtoyourself.co.uk>
>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:
> 
> > Ron <beeb@woosh.co.nz> wrote:
> > 
> > > If an editor has not been loaded, Zap will set the RunType for FFF 
> > > to ZAP just because a directory with !Zap in it has been opened.
> > 
> > But this is PRECISELY how RISC OS is supposed to work.
> >
> So it /is/ written somewhere? 

I think you're harking back to my comment about Acorn not providing clear
guidance about one aspect.

The aspect I was referring to was whether an application, when being booted
or run, should overwrite an existing Alias$@RunType setting or leave it in
place.  You will find variation from one application to another on this. 

That was the only aspect I was talking to.  I quite agree with what Alan says
about how RISC OS is supposed to work: booting occurring when the containing
directory is opened, and Alias$@RunType persisting after the application is
quit.

-- 
Matthew Phillips
Durham

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

#1123

On 30-Nov-2011, Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> The aspect I was referring to was whether an application, when being
> booted or run, should overwrite an existing Alias$@RunType setting or
> leave it in place.  You will find variation from one application to
> another on this.
>
> That was the only aspect I was talking to.  I quite agree with what Alan
> says  about how RISC OS is supposed to work: booting occurring when
> the containing directory is opened, and Alias$@RunType persisting after
> the application is quit.

As  general rule the !Boot file shouldn't replace a pre-existing RunType
setting as it would be assumed the user is intelligent enough to make sure
the program he prefers to handle that filetype is the one first 'seen' by
the filer or by setting the appropriate 'look at' in !Boot  It would not
really be appropriate for a program to usurp this just because the user had
inadvertently opened a directory containing that program.

However it's not necessarily inappropriate for the !Run file to set the
RunType and/or LoadType, replacing any previous settings The assumption here
is that if you've deliberately run a particular program then you want that
program (or that instance of it) to claim the filetype. That make is easy to
switch between programs. Even a non-techie user would be able to understand
that the last program he ran would be the one to claim the filetype.

However this action (and I suggest only this action) *is* a point of debate
and depends very much on the type of file. For example, with HMTL and text I
have a preferred text editor and a preferred browser for local files. I may
want to look at a particular file in a different editor/browser for some
reason but I don't want the second one I've run to take over the RunType or
LoadType for that file, I just want it to load a particular file.

So, the only answer would seem to be that nothing (apart, perhaps, from
always setting RunType in the boot file) is always 'right' or always
'wrong'. In particular the actions for universal and 'owned' fileypes may
need to be different. Perhaps the most sensible approach would be to put the
necessary lines in !Run and then suggest the user should put a '|' at the
start of these if he/she doesn't want this action?

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

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

#1130

Ron <beeb@woosh.co.nz> wrote:
> In message
> <gemini.lvfbfw00a4wyv0078.spamhater@keepyourfilthyspamtoyourself.co.uk>
>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
wrote:
> > Ron <beeb@woosh.co.nz> wrote:
 
> > > If an editor has not been loaded, Zap will set the RunType for FFF to
> > > ZAP just because a directory with !Zap in it has been opened.
> > 
> > But this is PRECISELY how RISC OS is supposed to work.

> So it /is/ written somewhere?

The RISC OS Style Guide, page 102:

| You will probably use a !Boot file to set up the icons, filetypes and
| corresponding system variables that RISC OS needs so that it can show your
| application in a directory display and run it when you double-click on its
| icon. If your application is called Appl, this might involve:

| - setting Alias$@RunType_ttt, Alias$@PrintType_ttt and File$Type_ttt 
|   variables
| - loading !appl, sm!appl, file_ttt and small_ttt sprites from the
|   !Appl.!Sprites file (see below).

| However, an application should only grab filetypes on start-up if
| filetypes are not currently set. This means that instructions such as
| SETFile$Type, Alias$@RunType and Alias$@PrintType should only be executed
| if File$Type, RunType or PrintType are not set at all (null) when the user

| starts that application.

That last paragraph is the important one in the context of this discussion.

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/
RISCOSitory:                          http://www.riscository.com

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

#1135

On 01/12/2011 17:00, Vince M Hudd wrote:

> | However, an application should only grab filetypes on start-up if
> | filetypes are not currently set. This means that instructions such as

And how many !Boot/!Run files run %If clauses on the Alias$Meh stuff?

<looks>

Thought so.

:-)


Best wishes,

Rick.

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

#1138

In message <4ed8808d$0$5662$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 01/12/2011 17:00, Vince M Hudd wrote:
> 
> > | However, an application should only grab filetypes on start-up if
> > | filetypes are not currently set. This means that instructions such as
> 
> And how many !Boot/!Run files run %If clauses on the Alias$Meh stuff?
> 
> <looks>
> 
> Thought so.
> 
> :-)
> 
> 
> Best wishes,
> 
> Rick.

I think it would still fail in the case of text runtype, because
it gets set to Edit at !Boot time. It's probably not such a bad 
thing that the Rom editor is set, but one likely time you would
use !Edit is when !Boot has failed, and you have bypassed it.
You then have to go to Apps and click on it. 
(Not that hard to do really)

So a text editor would have to test for runtype_fff being set to
!Edit rather than runtype_fff being unset.

Maybe the Rom apps runtypes could be configured on/off in 
!Boot Config?


Incidentally, I think 'If' in an Obey file is limited to one test
so the only way to do

If variable1=<value> && variable2=<value> do_something

is to do

If variable1=<value> Obey secondaryfile

secondaryfile has

If variable2=<value> do_something 

| then returns to the Obey file.
 
Maybe nested macro's could do the more complex tasks?
They can be tricky though.

Ron M.

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

#1141

On 03/12/2011 00:05, Ron wrote:

> it gets set to Edit at !Boot time. It's probably not such a bad
> thing that the Rom editor is set, but one likely time you would
> use !Edit is when !Boot has failed, and you have bypassed it.

I use Edit a lot. It is resource light and it works (well, if you ignore 
the redraw fail when viewing a large wodge of binary ;-) ).
Thing is, I thought Edit's module set itself as the editor?

Yup. Just reconfig'd RO5/RPCEmu to start up without booting. Afterwards, 
I looked at the aliases, which were as follows:
--8<--------
*Show Alias*
Alias$. : Cat
Alias$@LoadType_FCF : LoadFontCache
Alias$@LoadType_FF7 : Print %0
Alias$@LoadType_FF9 : SLoad %0
Alias$@LoadType_FFA : RMLoad %*0
Alias$@LoadType_FFB : Basic -load |"%0|" %*1
Alias$@PrintType_AFF : /Resources:$.Apps.!Draw -print
Alias$@PrintType_FF9 : /Resources:$.Apps.!Paint -print
Alias$@RunType_AE9 : Run Resources:$.Apps.!Alarm %0
Alias$@RunType_AFF : /Resources:$.Apps.!Draw
Alias$@RunType_BD9 : ShareFSIcon %0
Alias$@RunType_BDA : ShareFSIcon %0
Alias$@RunType_F9D : ShareFSIcon %0
Alias$@RunType_F9E : ShareFSIcon %0
Alias$@RunType_F9F : ShareFSIcon %0
Alias$@RunType_FB4 : ShareFSIcon %0
Alias$@RunType_FCF : LoadFontCache
Alias$@RunType_FD6 : TaskWindow |"Exec %*0|" -name |"Task Exec|" -display
Alias$@RunType_FD7 : TaskWindow |"Obey %*0|" -name |"Task Obey|" -quit
Alias$@RunType_FEA : Desktop -file %*0
Alias$@RunType_FEB : Obey %0
Alias$@RunType_FED : WimpPalette %0
Alias$@RunType_FF7 : Print %0
Alias$@RunType_FF9 : /Resources:$.Apps.!Paint
Alias$@RunType_FFA : RMRun %*0
Alias$@RunType_FFB : Basic -quit |"%0|" %*1
Alias$@RunType_FFE : Exec %0
Alias$@RunType_FFF(Macro) : If "<Wimp$State>"="commands" Then Type %*0 
Else /<Edit$BootDir> %*0
--8<--------

So this lot is done by the operating system itself, thus providing a 
functional set of file actions without the need to go through the whole 
boot process - like, as you say, when it gets mucked up and you need to 
poke around manually.


> So a text editor would have to test for runtype_fff being set to
> !Edit rather than runtype_fff being unset.

Hehe... which would fail if Edit *WAS* your preferred editor.


> Incidentally, I think 'If' in an Obey file is limited to one test
> so the only way to do
> If variable1=<value>  &&  variable2=<value>  do_something
> is to do
> If variable1=<value>  Obey secondaryfile

...I think that it is usual to call a program of some sort to handle 
complicated stuff, like the "SysPaths" in !System.

The problem, the REALLY BIG problem, is the Obey "language" lacks an 
"Exit" command to drop out of the Obey and return to caller. If you call 
"Obey" (with no parameter), it will terminate Obey processing, but it 
terminates *ALL* of them.


> Maybe nested macro's could do the more complex tasks?
> They can be tricky though.

Indeed.

I guess it isn't a surprise that Obey is functional-but-limited given 
BASIC is a standard feature; the logic was probably "if you need more, 
write a real program!".


Best wishes,

Rick.

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

#1144

Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> I use Edit a lot. It is resource light and it works (well, if you ignore 
> the redraw fail when viewing a large wodge of binary ;-) ).

...or text.

Alan

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web