files@

Just a remark: It seems that the return value number_of_files is not initialised in the routine files@. It would be nice to set this value to zero just at the beginning of the routine:

      program test

      IMPLICIT NONE
 
      integer*2      M_1(1000)
      integer*4      M_2(1000)
      integer*4      nof   ! number_of_files
 
      character*120  afile(1000)
      character*120  string
 
      string = '*.xxx'
      call files@(string,nof,1000L,afile,M_1,M_1,M_1,M_2)
      print*,nof

      end

Regards - Wilfried

Wilfried,

You should check the documentation for FILES@, as both N and NMAX are INTEGER (KIND=2), which is INTEGER2, not INTEGER4.

Only today I again came across the limit of NMAX < 32,768, being limited to 32,767 entries in a directory. I'm not sure if a directory in Windows 7 can have more entries. My test that N < NMAX failed, so I increased the size of NMAX from 25,000 to 40,000 in my include file, without checking, as a call required more than 25,000. I now have 32,000 and that is working for my directory scan at the moment.

It would be a nice change if integer2 could be replaced by integer4 generally in the library, as is generally in clearwin and observed by Dan.

John

I have had a quick look at the code for FILES@ which indicates that the number of files will be returned as zero when this is the case. Please let me know if using INTGER*2 does not fix the problem.

The use of INTEGER*2 arguments goes back to DBOS days. Although DBOS was a 32 bit extender for the existing Win16, presumably it was necessary to use existing 16 bit graphics routines. DBOS graphics routines were ported to ClearWin which later formed a part of ClearWin+.

As a result there are a number of library routines that pass 16 bit arguments and users do need to be aware of this legacy.

Indeed, using integer*2 for number_of_files solves the problem. Thank you, John. So it was my mistake...

Regards - Wilfried