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