I was unsatisfied with KermM's C port of AHelper's C++ file browser library. It caused a lot of system errors on my under-development image viewer, and its code "complexity" annoyed me as a beginner in C coding.
So I wrote my own file browser, first for specific purposes and now modified to fit most usage cases. It doesn't use dynamic memory allocation and supports a maximum of 200 files or folders per directory (same as OS).
Long file names are supported (that and the fact that it doesn't show the filesize are probably the reasons why it doesn't mimic the OS so well).
I'm yet to get a single system error with it.

I believe the code is pretty self-explanatory and easy to change according to your needs. There's an usage example at the bottom (and after removing it, the code should compile as-is).
When compiling, one or two warnings are returned but I don't know how to fix them.
Tell me if something doesn't work.


Code:

How much static stack space does it take up, if it doesn't do any dynamic allocation? I agree that my code is "complex", but only in that I needed to emulate class instance variable storage by passing around structs, and the automatic constructors and destructors that C++ creates for allocating and deallocating instance variables with functions. I'm sad to hear that you found it glitchy.

It uses at least 75991 bytes of stack space while the execution is inside the fileBrowser routine, and that is assuming the values for buffers from the code above. There's 512 KB stack so this shouldn't be a problem unless one has many static buffers declared and code in memory when fileBrowser is called.

alloca() alloca() alloca(). That's quickly becoming my mantra when people complain about the heap being nasty to work with.

Oh, alloca is like malloc but for the stack, and is automatically freed? I have to try that.

I don't use the heap on the Prizm because the OS doesn't seem to like it very much, furthermore, it's small (128kB) when compared to the stack (512kB).

Will you be releasing the "general" version of your file browser, or is this about it? Mind if I give it a try in LuaZM, slash is it appropriate for that?

Edit: What would be the easiest way to make this allow more than one extension, say, *.txt|*.lua? or even *.txt|*.lua|*.lc?

This is the general version of the file browser
I believe it is appropriate for use in LuaZM. As said, it uses a quite a large fixed amount of memory (I figured out using alloca for variably sized allocations would require me to get the number of items in a directory first, allocate space, and only then list the items, which would decrease the speed), but that memory is "freed" when you're not using the file browser, so just make sure to free all Lua-related resources when using the file browser (something I bet you already do) so there's always enough RAM.

Also, it still doesn't have checks to see if a directory has more than 200 items (which is the OS limit), meaning that if one does there will be an array overflow. I added this check in the snippet below, near line 85.

Currently the file browser only allows to filter for one file type, but you can make it filter more than one file type at once by adding more filter buffers, converting them to shorts with the syscall and then adding another if clause for them.

I did the work for you (but didn't compile it, and any errors it may have should be trivial to fix):

Code:


Also, feel free to adjust the size for the name buffers so that they can hold longer filenames and paths (and for the sake of it, also add a check to see if a path is going to fit in them, etc.; now I understand why Casio limits the end-user to see 8-chars filenames...)

Thanks a lot for helping me with those edits; my fingers aren't quite up to it, nor is my brain pre-coffee. I need to finish my zmg_drawcirclefilled routine before I can compile, then I shall test and let you know if it works.

I'm trying the one in the first post, but I keep getting this error:

Code:


I'm using the latest version of libfxcg.

Edit: Nevermind. I got that error out of the way. Now I'm getting:

Code:

That's not a fault in my code. You should be using the latest version of libfxcg (as in: compile it yourself from the code in GitHub).

Or grab an automated build.

I have a question about this. The filename it returns, does it include the "\\\\fls0\"? or do I have to add that when I do the StrToName_ncpy?

It includes the \\fls0\ portion. You only need to do the StrToName_ncpy to use it with the Bfile functions.

The filename it gives back is something like "\\\fls0\[filename]". It should be "\\\\fls0\\[filename]". Is there any way I can modify it to make it work?

It is working as it should. The "\" is an escape sequence ("" is the escape character) which makes a single backslash "". When you put the string "\\\\fls0\" in your C program, the C compiler recognizes that you are escaping the "" and knows what you mean, "\\fls0".

But Bfile_StrToName_ncpy doesn't work with it.

What do you mean by "doesn't work with"?

Well, I'm guessing that it isn't working with StrToName_ncpy, or OpenFile. The hFile it gives back is less than 0, so it is returning without examining the file like I need it to. This is the parts of my code:


Code:


It's in a function, so the PATH is the filename returned from your routine.

Try putting strlen(PATH)+1 instead of sizeof(PATH) on the second line of the snippet you posted.
I think you're mixing sizeof and strlen a bit. sizeof is the fixed data size (be it an int, a short, a char, etc.) and strlen is for measuring the length of char arrays (strings). Google it. You cannot use strlen when declaring arrays like array[size of array] because the size of arrays isn't dynamic in C, so the way you're using sizeof in the first line seems correct to me.

Thanks. It works now. The tutorial on WikiPrizm says sizeof(), so I just used that.