Unrecognised file type

At present an error message of the form ‘An application that loads a file of this type has not been found by the Filer. Open a directory display containing the required application and try again.’ is produced if no response is made to a service call (no running application knows what to do) and there is no run action specified (no application has been seen that handles a file of this type).

Although it is obvious which file is involved if it is the user that double-clicks a file, the same error is produced if an obey file tries a ‘Run filename’ command.

Could this error message be improved (now that the vast majority of filetypes that will ever be allocated have been allocated) to say something like:

File (full pathname) has tried to run file (full pathname) which is of type (type name from full database along with hex number). The software to run this may be on your machine where the Filer has not yet seen it, but if not can be downloaded from (registered web site that hosts such software)?

One possibility is to have a ‘catch all’ application that is invoked by a default run action for all filetypes that knows all file types and where suitable software may be found.

File (full pathname) has tried to run file (full pathname) which is of type (type name from full database along with hex number). The software to run this may be on your machine where the Filer has not yet seen it, but if not can be downloaded from (registered web site that hosts such software)?

I don’t think all software will run in response to a file it can handle even if it has been seen by the filer. I’m thinking specifically of DigitalCD which will handle audio MPEGs but only if it’s running.

That is unless there’s something wrong with my setup.

There’s something wrong with your setup – more specifically, the file !DCDRes.Setup. Read the manual for details of how to make DigitalCD claim filetypes when not running.

Thanks for the pointer Martin.

I think Chris’s suggestion falls into the category of “would be nice, but would be a massive administrative burden to maintain”. The number of registered filetypes measures in the thousands and is still growing, and a fair number of those can actually be read by more than one application. There isn’t currently any database mapping filetypes to URLs, and URLs are liable to change at the drop of a hat.

While ROOL, with our RISC OS allocations manager hats on, have access to the master list of allocated filetypes, the allocations system has always operated confidentially, and much as we might like to, we do not have permission from the countless people who have used it over the years to make these details public. The closest I think you’re likely to get is a community-maintained list of filetypes – but surely one of these exists already somewhere?

Behind my suggestion was an idea that the error messahe could say which file had done the run instruction and which file (and of which filetype) was attempted to be run.

Wouldn’t any action beyond reporting what the system knows about the file be better handled by an app emporium/packager?

i.e. if packaging is installed, the packager is asked if it knows the type and if it does, more information is given and the option to install the required package.

I had a little think about this. There are two different situations to handle, if you want to provide a more helpful error message when a file of unknown type is run.

Firstly, the *Run command. This could be issued by the user typing a command, or it could be in an obey file. In this instance, whoever handles the command (UtilityModule? The kernel?) seems to check the Alias$@RunType_xxx variable, and if no alias is set, issues the error message. In this instance, no loaded applications get a chance to load the file being run – no messages are sent.

The second case is for a Filer_Run command, which is the same as a double click in the Filer. This could happen due to the command being in an obey file, being typed, or by the user double clicking.

In this case, a Wimp message is sent informing applications of the file being run, and they get a chance to claim the message and load the file. If no one claims the message, the Filer checks the Alias$@RunType_xxx variable. If the variable exists, the file is run, otherwise the error message is shown.

It’d be possible to write a small application that intercepts the Wimp message for case 2, and displays a more helpful error message for an unknown file type. However I can’t see an easy way of such an application being able to know the origin of the Filer_Run command – for example if it was issued from an obey file. Is there some sort of hook an app can use to know an obey file is being run? I suppose you could set Alias$Obey …

Hmm, I love a challenge. Here’s a wonderful bodge I came up with: http://www.btinternet.com/~rik.griffin/archives/CatchUKF.zip

To use it: Put the application in Boot:Choices.Boot.Tasks or somewhere else appropriate.

How it works: We listen for WimpM_DataOpen messages from the Filer. When one arrives, we reply to the Filer, making the Filer think someone has opened the file. The app then broadcasts its own identical message, duplicating what the Filer does. If this message is returned, no other app has opened that file, so we can check the Alias$@RunType variable.

If the variable exists, we try to run the file, using Wimp_StartTask. If the variable doesn’t exist, we display a more helpful error message.

The nasty part: We also set an alias for the Obey command. When an Obey file is run, our alias runs another obey file inside the application directory (“MyObey”). This remembers the path of the original file in a system variable (CatchUKF$ObeyFile), and then runs the original obey file. Then we send a wimp message to the CatchUnknownFile application so it knows that the system variable has been set.

The application, on receipt of this wimp message, sets a flag, and 50 cs later (on a null poll event) deletes the CatchUKF$ObeyFile variable.

If that variable is set when the application receives a returned WimpM_DataOpen message, it’s used in the error message.

If anyone wants to use this as the basis for something better, feel free, consider all this code to be in the public domain.

I think I like that..

Sadly it doesn’t work properly. I’ve uploaded a new version that fixes some problems with leaving files open, but there are still several major faults:

1 – You get a full screen refresh when a new task is started.

2 – Absolute files are not run. Utilities are probably broken too.

3 – WimpSlot for newly started tasks seems to not be set correctly. I’m not exactly sure what’s going on with this.

Anyway, I don’t think this bodge is ready for serious use without some further work. It was an interesting experiment, but ultimately it’ll probably be better to incorporate this feature into the appropriate parts of the OS.

TBH My thought before reaching the end of this thread is that this is a job for the Filer to delegate to someone else – if the Filer doesn’t know what to do with a file after exhausting the usual methods it could broadcast a last-chance message before issuing the usual error (if that bounces).

Optional helper can jump in there if required, examining a local database, searching the net, displaying a huge and verbose error message etc.

if the Filer doesn’t know what to do with a file after exhausting the usual methods it could broadcast a last-chance message before issuing the usual error

This is exactly the sort of thing that would be helpful – with this hook the helper app can try to identify the file and filetype concerned and produce a more helpful message if it can.

I misremembered… Filer just delegates running of files to Wimp_StartTask, which ultimately results in FileSwitch reporting the error by the usual mechanisms.

So FileSwitch would have to do an UpCall at that point which could be trapped by the Filer, stopping FileSwitch from raising the error. When the Wimp finally returns to the Filer after Wimp_StartTask, the Filer notices the flag it set in its UpCall handler and issues the last-chance message. If that bounces, the Filer raises the error FileSwitch would have. Note of course that the Filer only responds to the UpCall when inside the desktop.

I think that would work. (It’s a pity the Filer doesn’t do the wrangling itself, instead of relying on the underlying FileSwitch behaviour – it’s not like the Filer is issuing command line instructions here, it specifically wants to use RunType_***, and does for the special case of shift-running a file to make it behave like a text file. I don’t see why it can’t do the RunType lookup itself and hence avoid a lot of that overhead for this case)

General question: Why doesn’t Filer do @RunType lookups itself?

One could also argue that FileSwitch shouldn’t be mentioning “finding an application” anyway as in a RISC OS configured to never start the desktop, how could one “find” an application? However, that opens another can of worms.