Home | Reviews | GUIpedia | Forum | Fun500
pharoah | How does your scripter handle the filesystem?I'm still trying to put together a decent multi-scripting GUI, but I keep hitting the problem that I can't think of an elegant way to have scripts handle the file system. I don't really have an issue with opening files, I would just use a command that took the path as an argument and spat out a handle. The problem is, how do I handle directories and the like. PDS/FB's "DIR$" function is terribly inelegant in its usage to my mind. Anyone have a better way of implementing the feature to return a DIR listing to a script? | 2009-01-30 | 4:23 PM |
Todd | Re:How does your scripter handle the filesystem?There used to be some code I saw that uses interrupts to list all the files. I don't know where I have it or where I found it but that would be one way.
If all fails, you can just use a SHELL command to return a file listing:
[code]
path$ = "C:"
SHELL "DIR "+path$+" /A-D /ON /B >FILES.LST"
SHELL "DIR "+path$+" /AD /ON /B >DIRS.LST"
SHELL "DEL DIRS.LST"
SHELL "DEL FILES.LST"
[/code] | 2009-01-30 | 4:55 PM |
Brandon | Re:How does your scripter handle the filesystem?I personally would avoid temp files, as I don't want to fry the 30mb hdd in my Epson. | 2009-01-30 | 7:29 PM |
| Re:How does your scripter handle the filesystem?Cobra works that way, I do that all the time, no prob. but i may switch to interrupts. since they are fast. | 2009-01-30 | 8:11 PM |
Brandon | Re:How does your scripter handle the filesystem?lol, no prob? LOL. your defense to the burning up of my harddrive for temp files, that could be in ram is? | 2009-01-30 | 8:27 PM |
pharoah | Re:How does your scripter handle the filesystem?Well to be honest I'll probably be using temp files myself. But I have come up (finally) with an elegant solution to my quandary which, as you might recall, was how to give scripts access to the DIR listing once I've got it.
Basically I create a static array of 10,000 strings to start. They will hold script variables.
Then I create another array with 10,000 integers. These will be used to create linked lists in the variable array. Linked lists are nice because they won't require me to deal with the age old question of what to do when a script closes and leaves 20 variable spaces open in a block, but another script comes along and wants 21. With lists, each element can be on its own and points to the location of the next element. The last element of my lists will have a pointer value of -1, unallocated spaces will have a pointer value of 0.
So when a script in my GUI wants a directory, it can use the dir word (stack based language, remember), and get the pointer of the first element of a list created just for it, where each element is a name of a file in the directory. It can use my provided count function to get the number of elements, and then go through and print them all out or whatever it needs to.
I'm happy I've started using linked lists, along with stack languages they make my life easier writing a scripter. Otherwise I just spend way too much time trying to think of an elegant way to do things before I start. | 2009-01-30 | 9:15 PM |
SonicBrit | Re:How does your scripter handle the filesystem?The dir$ issue is due to the way dos handles getting a list of files.
function 4eh is find first file
cx = attribute bits(0-read only, 1-hidden, 2-system, 3-volume, 4-directory, 5-archive)
ds:dx pointer to null terminated string
returns a no carry flag if successful (otherwise error code is in ax)
There is an area in DOS memory called the disk transfer area (use function 2fh, to get the DTA location returned in es:bx), this is used in this instance to store information about what files it finds.
Bytes Description
0-14h Reserved
15 Attribute
16-17 File Time (bits 0-4 seconds *2, 5-A minutes, B-F hours)
18-19 File Date (bits 0-4 day, 5-8 month, 9-F year+1980)
1A-1D File Size (4gb max, hence why there is a 4gb limit on files under older versions of windows)
1E-2A File Name (without the period, so its 8 chars name, 3 chars extension+1 byte null)
Now call 4eh will only return the first entry off the disk, to be able to get more entries you have to call 4fh.
Hence why dir$ in reality is 2 operations, first to set what your looking for and get the first match, the second to retrieve further items. | 2009-01-31 | 1:01 AM |
GUIs
2021 Brandon Cornell