Extended KotD #10: _FILES$ - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Official Links (https://qb64phoenix.com/forum/forumdisplay.php?fid=16) +--- Forum: Learning Resources and Archives (https://qb64phoenix.com/forum/forumdisplay.php?fid=13) +---- Forum: Keyword of the Day! (https://qb64phoenix.com/forum/forumdisplay.php?fid=49) +---- Thread: Extended KotD #10: _FILES$ (/showthread.php?tid=2727) |
Extended KotD #10: _FILES$ - SMcNeill - 05-23-2024 As we work our way backwards to cover our newest keywords in the language, we start to move back to version 3.11, where _FILES$ was added fro us. At first, I thought this would just be a quick show-n-tell type entry in our list of KotD, but it seems like I was mistaken. There's actually several points that need to be brought up and emphasized that everyone needs to be aware of with this newest way to get a file listing. First, let's cover the fact that _FILE$ is a dual-usage command. One has to use it for two very distinct uses inside their code, for it to be very functional at all. First, _FILES$ must be called once, to set the type of files that one is looking for. This isn't a hard step, but it's an essential one: Code: (Select All) x$ = _FILES$("*.bas") If we wanted to get a listing of all txt files from the "C:\My Documents\" folder, we'd want to call _FILE$ with those options to set the path and directory. Basically: Code: (Select All) x$ = _FILES$("C:\My Documents\*.txt") Now note that this first use of _FILES$ is to set the path and type of what we're looking for. After this, we can now call _FILE$ -- with no parameters -- to get back the files that meet those options for us, one at a time, until we come back with a null string. The way this looks is basically: Code: (Select All) x$ = _FILES$("C:\My Documents\*.txt") HOWEVER.... There's one more important issue that I need to stress for folks, or else things may not end up performing as they'd expect them to! Let's now take a moment to back up into the ancient past of coding. Back all the ways to the days of DOS and GWBASIC and QB45... Back, into the dim recesses of history, when the skies were still dark swirling masses of energy and the universe was just forming. Back... GASP.... even before the internet existed!! LONG... LONG... LONG AGO.... A lot of our user base problably remembers those days quite well. Back in those days, one would type something into the commnad line such as: Code: (Select All) DIR *.* DIR *.* would give you a listing of ALL files and folders for the ciurrent directory. And with that history out of the way, let's move forward in time a bit, to when those 8-character filenames became obsolete. At some point in time, we started to be able to use 256 character long file names. And then, as folks wanted even more characters, we even expanded beyond that to 65,535 character file names (in some cases/formats). No longer were files limited to juse being <name> <dot> <extension>. You could now write and create a file and call it "My.dot.filled.file.txt", if you wanted too, and the OS and your hard drive didn't care!! And keeping those two points in mind, how do you think that's affected _FILES$ and how it behaves now?? Let me sidetrack for a second, before answering that, to ask, "What do you think you'd get if you did the following:" Code: (Select All) DIR *e* Now, to back back up, let's ask, "What do you think you'd get if you do the following:" Code: (Select All) DIR *.* To highlight this difference, let's take a moment to look at a file list. Pretend this is my drive: Code: (Select All) C:\ Now, according to legacy rules, DIR *.* would list: Code: (Select All) C:\ But accoring to modern tules, DIR *.* would list: Code: (Select All) C:\Temp.Stuff\ Notice that C:\ and C:\Temp are missing from the modern way of processing *.*?? It's because they have no DOT in their filename. "*.*" isn't what it used to be. It no longer represents a file named <ANYTHING> and an extension named <ANYTHING>. "*.*" now represents <a DOT with ANYTHING before it and ANYTHING after it>. And that's an important distinction for folks to realize, when using _FILES$, as _FILES$ uses this more modern interpretation of the command syntax. If you want a list of <EVERYTHING>, the easiest way to get this with the modern ruleset is to simply Code: (Select All) x$ = _FILE$("*") Notice you're just looking for * (<ANYTHING>), and not *.* (<ANYTHING before><DOT><ANYTHING after>). This is a very important difference and something that everyone should note. Don't use "*.*" just because you're on old foggie like Steve, who got used to that in the age of the dinosaurs of programming. If you want a list of ALL files, just use "*" for your search limiter. RE: Extended KotD #10: _FILES$ - bplus - 05-23-2024 +1 this is useful when i get around to trying out this _files$ keyword |