Filer 'seeing' an application
Chris Hall (132) 3503 posts |
When the filer sees an application directory for the first time, it will execute its !Boot file. When a new drive is mounted, which contains several application directories in its root directory, how does the filer know whether it has seen them? Does it rely on the AppName$Dir variable being set to determine this? What happens if an application directory !Fred uses Jim$Dir and uses a task name Sheila – does the filer know it has already seen !Fred and, if so, how and can this be visible to the user? |
GavinWraith (26) 1532 posts |
I doubt it. My belief is that the filer simply looks at the objects of filetype 0×2000 and remembers their names, executing their !Boot files if it has not seen them before. The use of system variables of the form AppName$Dir was a recommendation, rather than a necessity, I think, but I cannot remember in which version of RISC OS it was first mooted. |
John Williams (567) 768 posts |
Does it not check to see if the corresponding sprite has been loaded into the sprite pool? |
Rick Murray (539) 13405 posts |
Probably whether or not the Sprites file has been loaded. I don’t know if it builds a list of application names or not. It depends upon what you mean by “seen”, as that expression is usually used to refer to the effects of having executed the !Boot file – namely that the run action for specific files is set up (if Ovation is “seen”, then from that point on RISC OS knows what to do if the user doubleclicks an Ovation document).
It is a necessity these days. How else does one refer to the contents of an application? Using Obey$Dir is only “guaranteed” for the execution of the Obey file, not the application.
Then somebody needs to be slapped upside the head for totally disregarding the rules. This isn’t RISC OS 2 any more, it isn’t a melee of floppy discs. If !Fred uses the system variable Jim$Dir, then what does !Jim use? There’s a reason this stuff should match up. Wow. Fred, Jim, and Sheila. That takes me back. Well, I’ll take your Fred, Jim, and Sheila and I’ll raise you an Andy, Lynne, and Hazel. :-) |
GavinWraith (26) 1532 posts |
A bit of experimentation with putting applications on a memory stick shows that the filer must be keeping a list of seen applications for each directory. Of course you can only refer to an application either with a literal pathname, which is clumsy, or with a system variable holding that pathname. What the system variable is called matters not at all as far as the filer is concerned. We have names, names of names, names of names of names, … about which the White Knight will have pointed out the necessity of discriminating. |
Chris Hall (132) 3503 posts |
My only reason for asking was I had an idea! If I put a pen drive in the USB socket, then the filer will execute the !Boot file inside the application directory !Update and thus update my application on the SD card. As I have no keyboard, mouse or monitor, just an OLED display I can’t do any checking. However next time I put a SCSI pen drive in the socket, with an app !Update on it, will it auto-run the !Boot file? I do a -SCSI-Dismount before unplugging the pen drive. A specific method of making the filer forget is what I might need… The unit will not have been turned off between these events. |
John Williams (567) 768 posts |
AFAIK that should work as long as there isn’t a Sprites file. Why not make the dismount an alias and execute it from the end of the Boot file? An alias so you’re not actually doing it from within the file itself. |
Andrew Conroy (370) 724 posts |
Won’t you have to click on the USB drive icon to open the filer window first? |
John Williams (567) 768 posts |
That occurred to me after I’d posted! |
Steve Pampling (1551) 7932 posts |
I think with that you’re expecting the kind of behaviour you get on the configured boot drive where in the old days you would do: and then the system would choose the adfs filesystem and boot from the first bootable drive and run the !Boot file/application on that drive. Not sure what happens if you make the drive (USB) that you plug in bootable and plug it in after the rest of the system has booted. |
Andrew Conroy (370) 724 posts |
Nothing, it sits there waiting for you to click on the iconbar icon. |
Chris Hall (132) 3503 posts |
Nothing, it sits there waiting for you to click on the iconbar icon. More thinking. Yes, of course, simply plugging the USB pen drive in will never be sufficient to activate something. At present pressing the ‘ON & INFO’ button attempts to open a file on SCSI::0.$ and, if successful, do a download onto it with error trapping. I will need to add something to the application to ‘pull’ an update from the USB drive rather than to ‘push’ something. Thanks for the help. Another lightbulb moment. I will add ‘*Filer_OpenDir SCSI::0.$’ as well as trying to open a file on the SCSI device. That will run SCSI::0.$.!Update.!Boot (which has no Sprites) and update the software. It already uses *-SCSI-Dismount once finished, which will close the invisible directory window again. |
John Williams (567) 768 posts |
Would X Filer_OpenDir be even better? To avoid raising an error if the device is not present! |
Chris Hall (132) 3503 posts |
Would X Filer_OpenDir be even better? To avoid raising an error if the device is not present! No. I want it to throw an error if there is no disc in the drive: any error is trapped and reported on the OLED display. |