Cheat sheet for opendir()
Richard Kreiss
rkreiss at gccconsulting.net
Tue Dec 1 07:03:25 PST 2009
Top Post:
I wrote something similar to what you showed at the bottom of this email.
I needed this routine to allow me to open more than one processing table on
my laptop where I had a single user version of FP.
The routine lists all of the processing tables in folder/directory and opens
it in an editor of choice.
The front end is similar to *cabe as it lists all of the files in the
filepro directory. This is displayed in a listbox allowing a directory to
be selected. Once selected, all of the processing tables are displayed.
Select a processing table opens it in an editor using a system call.
The only caveat is ABE=ASCII needs to be set.
Since this a program which does not do add or look at records, it is run
from my library file in *clerk on a blank screen from @entsel.
Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net
> >
> > He has this line of code that gave me the answer:
> > > ::handle_for_opendir=opendir("*.csv",foldername):
> > A little bit better explanation of on this command in the
> > documentation
> > would help avoid this problem for people in the future.
> >
> > Boaz
>
>
> Oh my God. I wondered how in the world you could be confused about such a
> simple function, so I looked at the doc you get from within *cabe. It is
> beyond horrible.
>
> Let me clarify a couple other things. Consider this a hints list, not a
> thorough doc by any means... But at least what should have been there for
> you in the real doc. If you want a really, complete, thorough
step-by-step
> manual about opendir() or *any* filePro function.... Then check by keyword
> in the Survivor Series CD's and you will be brought directly to one or
more
> movies that will immediately play in Windows Media Player. There is
> absolutely no need to ever struggle about anything filePro with this set
of
> hundreds and hundreds of movies... Indexed with thousands and thousands of
> keywords at your fingertips. Okay, ad over, good hints start here...
>
> First, if you rely on the example in the code that helped you (shown
above),
> you may continue to be a little confused about opendir(). When you first
> asked if there was a system maintained variable that holds the number of
> files found by opendir() I knew that you must have misinterpreted the
> docs... (Then I saw how horrid the doc on this function was ... And
well...
> It doesn't even state it at all clearly, so there was nothing to
> misinterpret.) The syntax is this:
>
> n=opendir(wildcard-mask,directory-path)
>
> Now, the fellow (or gal) who wrote the code that helped you is misleading
> himself or herself) the variable on the left side of the function is not a
> handle. It is a "return value". It holds the number of files found by
> opendir() with the wildcard-mask in that directory. So, don't think of it
> as a handle but as the return value of the function itself. The more
useful
> list of files found by opendir() when it is encountered is thrown into a
> series of system maintained arrays, @dirlist[], @dirlist_name[],
> @dirlist_filename[] and @dirlist_ext[].
>
> Here comes some of the hinty things. If you ask for *every* file in a
> directory, opendir() will always find at least two (2) files. You will
not
> usually find n to be equal to zero even in an empty directory. That is
> because there are always two files in any folder represented by "." and
> "..". The dot is a file which stands for the current directory and the
dot
> dot is a file that stands for the parent directory. ([1] - I'll put some
> very useful info at the end of the note about these.)
>
> Assuming the name of a file is "junk.2", and it is the only file in a
> directory called "/tmp/test". The program encounters
>
> then: n=opendir("*","/tmp/test")
>
> The variable n will be filled with "3", and those system maintained arrays
> will be filled with:
>
> @dirlist_filenam["3"] will equal "junk.2"
>
> @dirlist_name["3"] will equal "junk"
>
> @dirlist_ext["3"] will equal "2"
>
>
> @dirlist["3"] will hold the long list of data which used to be found by
> using nextdir() .... You can look nextdir() up if you want... But it is an
> archaic and essentially obsolete/useless function now since the @dirlist[]
> array already holds all the same data without having to retrieve it one
> element at a time which is what nexdir() used to do (still does, but only
> for backward compat....) If you want some of the data that is in the
> @dirlist[] array, simply access it by the right element number and you can
> parse out the piece you want with MID(). The nextdir() doc describes this
> character by character.) Here is how it looks along the line.
>
> @dirlist["3"] will equal "junk
> 2 2 12/01/2009 00:45:25a junk.2"
>
>
> Look closely at the first three @dirlist_ arrays, the ones you will be
using
> most. Note that the @dirlist_ext does not include the ".". Note that the
> @dirlist_filename value is the full filename and that the @dirlist_name
> value is only the name *without* any extension. Both are useful for
> different requirements.
>
>
> VERY IMPORTANT NOTE
>
> IN *all* versions of filePro, all platforms there was a bug in opendir()
up
> until 5.6.7 and above. It was a rare occurrence but if you had more than
> 1,000 files in a directory, the return value was truncated from the left
to
> only 3 digits. So, if you had 2913 files in a directory, the value would
be
> returned as 913. Even if the return_value variable has an edit big
enough,
> say (8,.0), it would still only be set equal to 913. My suggestion is to
> get the very latest version as soon as you can... Because there are lots
of
> other fixes and enhancements, but in the meantime, there is a very easy
> work-around. Instead of using the return value as reported by your
variable
> on the left side of the opendir(), just use @dirlist["0"]. It also holds
> the number of files found by the opendir(), but it is not truncated and
> always correct.
>
>
> The search key... The wildcard... Maybe even an exact file you wish to
> find....
>
> First, a little about the wildcard_mask you will see in the filePro docs
on
> opendir(). FilePro will help you get all the filePro formats of a filePro
> file with a few shortcuts. These are essentially factory provided
> wildcards. They are:
>
> PRC_MASK TOK_MASK SCR_MASK IDX_MASK
> BRW_MASK OUT_MASK SEL_MASK
>
> My bet is you will probably never use these. If you do however need to get
> all the screens in a file or all the processing tables, etc., these are
> ready made.
> Be sure to put quotes around them....
>
> n=opendir("scr_mask","test")
>
> This will get you all the screens in the filePro file called "test" in the
> current filePro directory.
>
> IMPORTANT: The return value, nor the @dirlist arrays will contain the "."
> and ".." files in this case? Why? Because you are not asking for *every*
> file in the directory as was being done with "*" as the wildcard.
>
>
> The same is going to be true about almost any wildcard you specify except
> "*".. If you limit a search with a prefix or a suffix as in:
>
> n=opendir("Jan.*","/tmp/fred" or n=opendir("*.Jan","/tmp/fred"
>
> You will find files like:
>
> Jan.120109 and 120109.jan
>
> You are only going to retrieve files which match that criteria. The dot
and
> dot dot files don't ever match such a search.
>
>
>
>
> You can most profitably use expressions as the search criteria.
>
> n=opendir(aa,"/tmp/fred") or n=opendir(i_need_this,"/tmp/fred")
>
> Which assumes that you have previously filled the dummy variable aa with
> your correct search criteria, or the same with the declared variable
> i_need_this.
>
> IMPORTANT: Remember, if you want to find *every* occurrence of an
> expression
> whether it falls at the end of a name or the beginning, you have to use
the
> "*" in ate appropriate place. For example:
>
> n=opendir("*" { aa,"/tmp/fred") or n=opendir(i_need_this {
> "*","/tmp/fred")
>
> And all variations of such.
>
> Another important thing to remember is the directory being searched is
also
> an expression, so it can be any kind of variable rather than a literal in
> quotes.
>
> n=opendir("*",aa)
>
> And, of course, you have filled aa with a good directory path before this
> opendir().
>
> All right, one more really IMPORTANT hint. (the kind of thing that should
be
> in a doc... Not as a hint, but as a piece of information that is EXTREMELY
> important.)
>
> Boaz asked how you use opendir() on a different directory. He experimented
> with chdir() and some other things I bet. It is also not very clear in the
> docs, but you can only use opendir() one time... And it stays active with
> all the @dirlist arrays for that particular directory... UNTIL.... You
issue
> a closedir() command. Then, and only then can you use opendir() again
with
> a different directory. You can use it as many times as you like, even in
> elaborate loops in quick succession, but you MUST encounter that
closedir()
> before you hit the opendir line again. And, remember that opendir is a
> function with a return value also... It has to be used as:
>
> n=closedir()
>
> You never put anything in between the parens... It just closes the last
> occurrence of opendir(). And this is very important *and* useful... An
> opendir() does not have to be in effect to use closedir(). It will just
do
> nothing and not complain if there is no previous opendir() to close.
>
> Okay, that's enough to get you using one of the most powerful filePro
> functions.
>
> In case you want to try opendir() and do it quickly and harmlessly and
> really see how cool it is in about 1 minute of code writing.... Here you
go.
>
> Usually what is done with the information opendir() gives you is this.
The
> return value is set as the highest number in a loop. The loop lets you
step
> through each file doing whatever you want with it. When you get to that
> highest value, you end the loop because there are no more files to
process.
>
>
> But, in fact, you of course don't have to do any processing on each and
> every file... You do whatever it is you need. Heck, you may want to simply
> display all the files in a directory so the user can "pick" one... Then
you
> process that one in the way you need. This can be as simple as a pair of
> lines of code. So, go pick a directory on your system and do something
like
> the following. Then go into the file in which you wrote this processing
> with rclerk and got to record 1 and press "T".
>
>
> then: end
> @keyT if: '@keyT test opendir()
> then: n(4,.0)=opendir("*","/tmp")
> then: xx(4,.0)=listbox(@dirlist_filename,"1",n)
> then: exit
>
>
> FilePro is actually pretty quick and nifty at such things.
>
> John Esak
>
> {1} Oh yeah... I said I would tell you how to deal with the "." and the
".."
> if you ever have the need. Here is a little loop that writes every
filename
> in a directory to an array that gets put on the screen... But it
eliminates
> the "." and "..".
>
>
> then: dim my_array["5000"; a(4,.0)="1"; b(4,.0)="1"
> then: n(4,.0)=opendir("*","/tmp"
> loop if: a gt @dirlist["0"]
> then: xx(4,.0)=listbox(my_array,"1",b - "1"); exit
> if: @dirlist_filename[a] { "x" eq "." { "x" or
> @dirlist_filename[a] { "x" eq ".." { "x"
> then: a=a + "1"; goto loop
> then: my_array[b]=@dirlist_filename[a]; a=a + "1"; b=b + "1";
> goto loop
>
>
> This simply skips the two unwanted filenames "." and ".." by incrementing
> one counter (a) to move through the file list and another counter (b) when
> we actually fill the array that listhbox() will show on the screen. It
will
> only show the correct number of names in the listbox because we are
telling
> it to stop at the value of b minus one. Which is the number showing how
> many times we actually filled the my_array array. :-)
>
> By the way the compare being used to test the filename against "." and
".."
> makes use of the thing Nancy described a few days ago of squishing some
> character against the test values so that for example, things like
> ".profile" and ".ssh" won't match ".". She said she uses a "~" or "|" I
> think... I have always just used an "x". Any character will do, since it
> does the job no matter what it is.
>
> I hope you have fun with all this. Truly, I would never have to write
> another word if people picked up the Survivor Series movies. They go step
> by step from knowing NO filePro and NO programming to a point where you
> could easily call yourself an EXPERT filePro programmer... But, you don't
> actually have to do the step by step thing... Although I heartily suggest
> it... You can just type in whatever you want at the Search index, and
watch
> the movies as you need them. They have always been a pretty much money
> back
> guarantee, and I have never had anyone ask yet.
>
> One caveat only... EVERYTHING in filePro except none of the HTML command,
> ODBC or SOCKETS. Otherwise "it's in there" through ADVANCED/EXPERT
> level.
>
> www.valar.com/survivor_series/choice.htm
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
More information about the Filepro-list
mailing list