(in dev)
So, KermM has been poking me to make a file open dialog of some sort. So, I have been working on a file dialog that will mimic how the OS does it. Until we can figure out the current syscall, I am making a configurable one.
Now, note that since this is being made as fast as possible with scattered time, I am using STL containers (vector) and algorithms (std::sort), which work with no problems. I will make a library and header available when I am done, but for now, here is a screenie just showing that I am plugging away:
Note the folder icons, these can be opened and such. You can filter files, like *.g3a, set the dialog title, and some other fun stuff.
Very nice. Of course, for simple file opening/saving that can comply with Casio's standards (8 chars, uppercase, no symbols...) it'd be better if we just discovered the syscall. However, as I think we're always going to need a custom file browser of some sort for more advanced file opening/saving (for example, with support for extended filenames and over 300 files in a folder) or even for a shell, your work is very important.
Here is an example on using the current API:
Code: FBL_Filelist *list = new FBL_Filelist("\\\\fls0\\", "*.g3a", "Open file (*.g3a)");
list->go();
Bdisp_AllClr_VRAM();
if(list->result == 1)
{
char buf[21];
locate_OS(1, 1);
Print_OS((unsigned char*)list->getFilename(buf, 20), 0, 0);
}
delete list;
Why classes? I worked hard to get uClibc++, why shouldn't I?
I need to add a few other minor features, like making/renaming folders, deleting and renaming files, searching, and using the filter.
edit:
There is no max filename length, and the same browser can access the main memory from the @MainMem folder.
edit:
Here is what the above code produces:
Note that the native file browsers do not allow for browsing the main memory along with the storage memory (in some cases, they only provide a Fkey function for switching between the two). I suggest you have two modes: one for storage memory only, another for main memory only and a third one that combines both main and storage memories (like it is now).
I don't want to keep making special cases to hide certain entries, so @MainMem stays since this syscall is meant to do this. You can just override the function in your own class.
If this is the case, we really need all the f* functions to transparently handle main and storage memory. Otherwise it's going to be a bit unfortunate when a user selects a main memory/MCS file with that and it turns out to crash the add-in when it gets to fopen
Also, I don't think the MCS is really a filesystem like FAT; I see it as more of a database which has tables called "folders" and keys that can be exported into the g3m format.
But I must agree, since the whole thing is open source, developers may just tailor it to their needs and hide whatever they want (it's easier to comment code than to write it
).
KermM, I am adding in MCS support, so you don't have to do anything. You can do FILE *f = list->getFile(); and that will work for either main memory or storage memory.
AHelper wrote:
KermM, I am adding in MCS support, so you don't have to do anything. You can do FILE *f = list->getFile(); and that will work for either main memory or storage memory.
That's great! But will I still be able to fread() and fclose() the returned handle like a normal file?
KermMartian wrote:
AHelper wrote:
KermM, I am adding in MCS support, so you don't have to do anything. You can do FILE *f = list->getFile(); and that will work for either main memory or storage memory.
That's great! But will I still be able to fread() and fclose() the returned handle like a normal file?
Of course!
Any word on when it will be done? I'd love to try this out!
I'm excited too, specially because after my tests with LuaZM's file browser (the only public release of the library), which indicate that apparently this library is much faster to browse than the native file browsers with progress bar.
(I could only test with lots of folders, I'm yet to test with lots of *.lua files).
Oh, this is actually somewhat released. I would be happy to package and release my pure-C (as in, non-C++) version for you all, but it lacks a few things:
- Sorting
- Program renaming/deletion
I felt that those latter two features, though present and buggy in AHelper's C++ version, were outside of the purview of this particular tool, so I removed them. If you guys don't care about that, I can add sorting and release my version.
How about this: Release what is ready, then release the full version when ready.
Many THX!
KermMartian wrote:
Oh, this is actually somewhat released. I would be happy to package and release my pure-C (as in, non-C++) version for you all, but it lacks a few things:
- Sorting
- Program renaming/deletion
I felt that those latter two features, though present and buggy in AHelper's C++ version, were outside of the purview of this particular tool, so I removed them. If you guys don't care about that, I can add sorting and release my version.
That would be great! I was planning on using it to open files for both ImgViewer and my CHIP-8 emulator, so a release (even without sorting) will be much appreciated.
Thanks for that. I'm having some issues compiling it, though.
Code: ImgViewer.c:(.text.FBL_Filelist_chdir+0x168): undefined reference to `_Bfile_Name_MatchMask'
Note: you must either add the syscalls to your libfxcg manually or from my libfxcg fork on github.
Now I'm getting this...
Code: sh3eb-elf-gcc ImgViewer.o -mb -m4a-nofpu -mhitachi -nostdlib -T/home/souvik1997/libfxcg/toolchain/prizm.x -Wl,-static -Wl,-gc-sections -L/home/souvik1997/libfxcg/lib -lfxcg -lc -lgcc -o /home/souvik1997/libfxcg/projects/ImgViewer/ImgViewer.bin
/home/souvik1997/libfxcg/lib/libfxcg.a(crt0.o): In function `ctors_s':
(.pretext+0x60): undefined reference to `start_ctors'
/home/souvik1997/libfxcg/lib/libfxcg.a(crt0.o): In function `ctors_e':
(.pretext+0x64): undefined reference to `end_ctors'
/home/souvik1997/libfxcg/lib/libfxcg.a(crt0.o): In function `dtors_s':
(.pretext+0x68): undefined reference to `start_dtors'
/home/souvik1997/libfxcg/lib/libfxcg.a(crt0.o): In function `dtors_e':
(.pretext+0x6c): undefined reference to `end_dtors'
/home/souvik1997/libfxcg/lib/libc.a(_vfprintf_internal.o): In function `__vfprintf_internal':
_vfprintf_internal.c:(.text._vfprintf_internal+0x258): undefined reference to `_abort'
_vfprintf_internal.c:(.text._vfprintf_internal+0x3d0): undefined reference to `_strnlen'
_vfprintf_internal.c:(.text._vfprintf_internal+0x3dc): undefined reference to `_fputs_unlocked'
/home/souvik1997/libfxcg/lib/libc.a(_ppfs_setargs.o): In function `__ppfs_setargs':
_ppfs_setargs.c:(.text._ppfs_setargs+0xdc): undefined reference to `_abort'
collect2: error: ld returned 1 exit status
make[1]: *** [/home/souvik1997/libfxcg/projects/ImgViewer/ImgViewer.bin] Error 1
make: *** [build] Error 2
Edit: Nevermind, I got it working by using Jonimus's libfxcg and adding Bfile_Name_MatchMask.S.
