No announcement yet.

Directory listing in 4DGL

  • Filter
  • Time
  • Show
Clear All
new posts

  • Directory listing in 4DGL

    In SGC mode we are able to get a directory listing using the extended commands for uVGAII,
    However since then I have ported most of my project to GFX as there is a big performance improvement (may be its just my percecption)

    I have not been able to locate any call in the internal guide to get file names for a wild card search. file_Dir(*.*) returns a count of matching files but not the actual file names.

    The file_Dir() talks of streaming the file name, but how it is to be done is not very evident.

    Is there any thread or example somewhere?

  • #2

    Check out FAT16dir2.4dg in the picaso examples folder.

    Shows something like this.

    var filenames[100];
    to(filenames); file_Dir("*.*");
    print([STR] filenames);
    That puts all the file names into a string. Then you can use all of the string functions on it.


    • #3

      dart!!! did not check through the samples (on my disk)
      will try it later, got a few other issues (other thread)


      • #4
        Hi, I have a problem with file_Dir, the streamed string has upper case alpha characters only, when you try to use a filename it fails because the case is always upper! What's the fix?


        • #5
          OK I have got it working. DOS file-names seem to be upper case only, when streamed to an array using file_Dir(filenames). I had to use a string pointer sp to the single name array to get flash_LoadFile(FLASHBANK_1, sp) to work, you can't just use the array name as you can with putstr(name). All very confusing, I dislike this old packed bytes string handing, it is very tricky, and probably buggy too!


          • #6
            8.3 filenames are always uppercase, it's only 'long filenames' that support lowercase.

            Not sure what you are getting at with 'putstr', since RAM is word aligned/addressed you always need a string ptr when referencing RAM as a string. Have you read ?


            • #7
              Thanks, yes I see that 8.3 is the filename convention, not made very clear in the manuals! So it is not possible to use longfilenames, that takes me back too far....

              What I was saying is that with putstr(name) you need not use a string pointer, I would say that there it is not obvious whether you use a pointer or not, for me putstr(name) works without declaring name to be a pointer. The whole issue of strPtr(...) is curious, a search in the Manual only returns examples of it's use, not the definition! I now realise that simply declaring a var and then an assignment make that variable a string pointer.

              This avoidance of types is confusing, I was much happier with pure 'C' I have to say!


              • #8
                Sorry I made a typo - it should be str_Ptr, but that did pick up a typo in an example! In fact putstr will not work if one uses a string pointer created with str_Ptr. The Manual says "A string constant, a pointer to a string, a pointer to an array, or a pointer to a data statement". So "a pointer to a string" is not the same thing as "a string pointer" !!


                • #9
                  What you say is unfortunately correct, in the eye or the writer, a man who's English was extremely pedantic, they are two distinctly different things. Unfortunately for the rest of us they appear to be the same. We will be getting this sort of phraseology updated in the manuals


                  • #10
                    That's very amusing! For a language that purports to be less demanding than 'C' these semantic niceties are surprising. I see that the Manual says that more 'types' will be introduced, but I cannot see any others except for constants. Of course there is also the question of floating point variables being 32 bits. The need to define different sized arrays for these things is a great way to introduce very subtle bugs. All this would be avoided by being able to define variable types of char, float, and pointer (16 bit words as default) would go a long way to avoid confusion...

                    Or of course simply introduce a 'C' compiler, if you can get that for a PIC and lots of other processors why not 4D devices?