Cheat sheet for opendir()

John Esak john at valar.com
Tue Dec 1 07:19:13 PST 2009


Very cool, Richard,

Lots of people like editing in a regular editor, and you actually get around
the silly licensing restriction as well with your idea.  By silly, I mean
that I think as many copies of a development filePro program as desired
should be allowed to be opened simultaneously on any one machine. Whatever
could be the logical/business reasoning behind limiting this?  Would the
owners actually be afraid too many people would be developing filePro apps
at the same time? :-)  Sounds like the more the merrier to me... The program
has already been paid for... And I fall back on my old comparison to Word...
Can you just imagine if Microsoft had started out their design strategy
saying you could only open one document at a time?  :-)  Oh well, that is
water over a very long ago bridge... Now, it hardly matters, but still, it
would be so nice if a a single user development copy would let you work as
we all do with lots of things open at once. Maybe in the final, final 6.0
version... Or okay, 5.6.9?  :-)

John


> -----Original Message-----
> From: Richard Kreiss [mailto:rkreiss at gccconsulting.net] 
> Sent: Tuesday, December 01, 2009 10:03 AM
> To: john at valar.com; filepro-list at lists.celestial.com
> Subject: RE: Cheat sheet for opendir()
> 
> 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