Filer$DefaultDir Missing in the Wiki?

From RISC OS 4 onwards an option exists to change the save behaviour of the Filer icon on the iconbar (presuming that it is supported by the Filer module for a certain Filing System).

I did know this exists, I also knew that it is possible to change the default target (the root of the related disk) to another folder, however I did not know from memory what the name of the variable should be. I found out that the format is “FSTitle + Filer$DefaultDir” by using Zap and extracting the RAMFiler module from memorty and searching through it, however I’m unable to find it in the ROOL Wiki.

When searching for the RAMFiler$DefaultDir (as this one should exist on all RISC OS versions) I cam across a changelog for RISC OS 5.24 which seems to indicated that the behaviour is corrected related to earlier versions of RISC OS 5.

Shouldn’t this information be part of the Wiki?

That sounds like a good thing to add.

There’s already a page for system variables (which looks handy), so you can go ahead and put it in there.

I have updated the Wiki page mentioned by Julie to include this information in a new Filer section.

When adjustments are needed then please let me know.

When adjustments are needed then please let me know.

I just skimmed it because I hadn’t realised it existed. Somehow I noticed something that looks wrong. In the last table, machine code variables are shown as being removed by OS_ReadVarVal. But if I’ve read correctly the descriptions of OS_SetVarVal and OS_ReadVarVal, removal has to be done by OS_SetVarVal.

I’m happy to be corrected if I’m wrong. Machine code variables are not an area that I’m at all familiar with.

As I do have a RISC OS 3 PRM, I checked the related entries and it clearly indicates that deletion should be done using OS_SetVarVal as well. In addition the related Wiki entries seem to contain some details which deviate from the RISC OS 3 PRM, however I could be that the behaviour has changed in RISC OS 5, although even then I’m puzzled about the OS_ReadVarVal variable types, what is a block of code supposed to do in case we are reading a variable?

In the last table, machine code variables are shown as being removed by OS_ReadVarVal.

That, is, weird.

I just looked and on first look it was OS_ReadVarVal in both columns. Now it’s OS_SetVarVal and OS_ReadVarVal.
The weird bit is that the wiki says no changes have occurred on that bit of text…

A little example that might help. Wiki updated

REM >SetVarVal3
REM 03Jan21
DIM buf% 32
str$="help"
$buf%=str$
len%=LEN STR$
:
REM Set and read variable
SYS "OS_SetVarVal","test$test",buf%,len%,0,0
PRINT "test$test : " + FNreadSysVar("test$test")
:
REM Unset and read variable
SYS "OS_SetVarVal","test$test",buf%,-1,0,0
PRINT "test$test : " + FNreadSysVar("test$test")
END
:
DEF FNreadSysVar(SysVar$)
  SYS "XOS_ReadVarVal",SysVar$,buf%,256,0 TO ,,len%
  IF len%=0 THEN ="Variable not found"
  buf%?len%=13
=$buf%

I have added a line such that set, read and unset are all shown in the “Notes” in to the “Type of System Variables” section of the wiki

I think the idea with machine code variables is you don’t want the user to be able to do say *Unset Sys$Time, as they’d never be able to get it back.

Most variables are fixed, set in an Obey file or somesuch. Edit$Dir, for example. Or what action to take to run a text file.
Read and written, they are generally numbers or strings (which may or may not go through GSTrans).

Code variables, on the other hand, are changeable entities. Sys$Time is a good example, as it reads the clock and constructs a time string each time it is read.
And when it is set? The time string is taken apart and used to update the clock.

That’s what code variables are for.

you don’t want the user to be able to do say *Unset Sys$Time, as they’d never be able to get it back

So obviously I did just that and was slightly surprised.

*Show Sys$Time
Sys$Time : 13:43:23
*unset Sys$Time
*Show Sys$Time
Sys$Time : 13:43:53
*

A larger example does show system set variables that should be left alone.

*show sys$*
Sys$Country : UK
Sys$Date : Sun,03 Jan
Sys$DateFormat : %24:%mi:%se %dy-%m3-%ce%yr
Sys$Path : ADFS::Titan4.$.!BOOT.Resources.!System.
Sys$RCLimit : 256
Sys$ReturnCode : 0
Sys$Time : 13:37:04
Sys$Year : 2021
*unset sys$*
*show sys$*
Sys$Date : Sun,03 Jan
Sys$RCLimit : 256
Sys$ReturnCode : 0
Sys$Time : 13:37:39
Sys$Year : 2021
*

Is a caveat required such as, “RISC OS sets some System Variables at startup, these should be regarded as read only.”?

I have had a further look at unsetting Sys$Time. PRM page 1-292 has, “Any non-code variable can be removed using *Unset”, which implies a code variable cannot so be unset, which is the case. Sys$Time can be unset with OS_SetVarVal.

REM >UnsetVar
REM 03Jan21
DIM buf% 32
PRINT "Sys$Time : " + FNreadSysVar("Sys$Time")
SYS "OS_SetVarVal","Sys$Time",buf%,-1,0,16
PRINT "Sys$Time : " + FNreadSysVar("Sys$Time")
END
:
DEF FNreadSysVar(SysVar$)
  SYS "XOS_ReadVarVal",SysVar$,buf%,256,0 TO ,,len%
  IF len%=0 THEN ="Variable not found"
  buf%?len%=13
=$buf%

Sys$Time : 18:25:49
Sys$Time : Variable not found
*

which implies a code variable cannot so be unset

What do you mean by this, that a code variable should never be unsettable? Or do you mean that it should not be possible with *Unset?

that a code variable should never be unsettable?

A code variable is clearly unsettable, just not using *Unset.
Given that it isn’t hard to do, as demonstrated above, I’m guessing it might have been done deliberately in order to stop people doing things like unsetting the Sys$ variables.