I updated prgmCMD to include the OPEN command and you can see as it opens DK5ION that this should be very useful!

indeed! i bet basic programmers out there will love this, and the code could be really useful elsewhere as well. is it calling those other apps to open the selected files? if so, it would be nice to have a hook that's called whenever a program is run from the homescreen, seeing as there isn't really anything out there that chooses what to use in opening a file dynamically like that.

Quote from: Sorunome on January 08, 2013, 08:37:33 pm

Looking nice, but can you also use it in basic programs?

Sorunome, that screenshot is of it being used in a BASIC program.

It was off the homescrean

Quote from: Sorunome on January 08, 2013, 08:37:33 pm

And if yes, is it compatible with BatLib as it uses dim( too?

The answer is yes and no. The two cannot work at the same time, but in this update I will introduce a new command OPEN() that is able to open BatLib programs (among other things). Also, a bunch of BatLib commands are provided at the moment with FileSyst, though some may be removed later.

Oh, that is pretty cool, does batlibs chainhook still work then?

I figured that I would ask for input on the following changes to be made to FileSyst:

-Using "/" instead of ":" for folder paths
-Getting rid of the File Association field and just using file extensions. For example, DonkeyKong.ION

Do these sound like good ideas?

Thanks And since FileSyst is going to be used in at least three projects (LinuxOS, ScopeOS, and LSDOS), all of which will have shell features, that should be greatly useful. Plus, as it is, it isn't easy to show the user what file associations there are. However, if it is part of the file name as a file extension, users will be able to clearly see what kind of file they are opening.

Okay, so I added in file extensions and using / for filepaths. It as actually a lot easier than I thought it would be to convert to using file extensions. I also added in the .DOC7 to open up DocDE7 files and I removed AFA() and RFA() as they are no longer needed.

I think I should probably mention that in the screenie running prgmGUI, prgmGUI keeps its subprograms archived. It creates a folder in the main directory called GUI, creates OS shortcuts there, then runs them when it needs to using OPEN(). But what is even cooler is that GUI recognises hidden files or folders and won't display them in the menus. That is why you don't see its folder-- it is marked as hidden using the HIDE() command.

You need DoorsCS as well as DocDE7 to open .DOC7 files.

Currently it is case sensitive. I was thinking of making it not case sensitive for the extension part of the name, but I am trying to figure out the best approach for the rest of the name. For example, DOnkeyKong.ION is different from DonkeyKong.ION. I could make the file searching code recognise the two as the same name, though. Do you think this would be a good idea?

I think case-insensitivity is possibly a good idea if input is calc driven, since it would save tedious typing time? But i guess it comes down to your preference Xeda ... is the necessary work required to implement worth the benefit? - I guess you can see it as both an increase and decrease in flexibility.