I am not sure if this is a problem in the native dialog addon or not, but the file chooser isn't displaying the way I expected.

fileDialog = al_create_native_file_dialog(al_create_path("data/maps/"), "Select Map", NULL, ALLEGRO_FILECHOOSER_FOLDER);

According to the documentation, this should allow me to choose a folder rather than a file. Am I just doing something wrong here or is this just not supported on windows? Also, I use another file chooser dialog earlier in my program, and it works fine there except for a few things. For instance, the filter passed was "*.jpg;*.bmp;*.png". When the dialog comes up, however, it acts as if *.* were the filter. Also, the dialog title doesn't seem to be used.

I wasn't sure if this was a problem with the addon or my code, so I posted it here. I tried testing in Ubuntu 10.10 also, but as I run it in VMWare, I get
XWindow errors creating a display, which is probably due my setup. My windows testing is also inside VMWare running Windows XP.

WG

Windows has a folder selector. Allegro probably doesn't support it.

Side note: your al_create_path() is a memory leak. The function would probably be more useful if it just accepted a const char *, as it's easy to convert a path to it via al_path_cstr...

Looking at the native dialog add-on code it seems that filters are ignored in Windows. Also, folder select is not implemented. I have some experience working with Windows file selectors so I could easily create a patch to address both these issues. I won't be able to do it until tomorrow, though.

Ah, thanks to both of you for that. I'm reinstalling Ubuntu right now so that I can try to do more of my work in Linux first, then move to Windows to test. Since I have a lot more luck compiling SVN code in linux than in Windows. Knowing that the windows code is simply not there does help a lot and can lead me in the right direction for what I was doing. As far as the memory leak, I did wonder about that but that line of code was added as a test situation only, so I had planned to fix it later by actually using al_create_path and al_destroy_path. I do agree that for the native file dialogs, a c style string could be more useful.

Thanks again

WG

I didn't get as far with this as I wanted today. Everything is working now except the filtering. I should be able to get this done on Friday.

That would be really awesome... converted 2/3 of my pc's today to Linux, am debating trying to run windows XP in vmware for linux or something similar.

Still might switch my pc back to windows.

wg

I've attached the patch. This patch makes the following improvements to the Windows native file chooser:

• Use Windows' folder selector when using the ALLEGRO_FILECHOOSER_FOLDER flag.

• Implement patterns ^[1].

• Display the title of the dialog that the user specified instead of Windows' default.

I haven't looked at the patch yet, but could you change the first parameter from an ALLEGRO_PATH* to a const char* while you're at it? Everybody on [AD] agreed that it should be that way.

Edit: If that affects multiple platforms, then you can just ignore me, and we'll add it after your patch.

Thanks, I'll take it from here.

I had one more question about how the native dialog works when using the folder chooser. It worked fine in Linux. The only problem I had was that I expected the entire path to be directory components with a NULL filename and extension. What I found, however, was that the folder which was chosen is considered the "filename" component. Is this the intended mode? It really is not a big deal, but it does require changing the way you deal with the path returned by the file dialog.

WG

I think the Folder select dialog should be creating its ALLEGRO_PATH with al_create_path_for_directory or appending a '/' to the end of the path to make sure the code parses it as a dir.

I'm not at the linux machine right now but I will test it again later. Last time I tested I was able to select the directory and the path was something like this:

/home/name/game/maps/worldmap

Since each map has a jpg image with the same name as the folder, to load the
image, I used al_get_path_component(path,-1) to store "worldmap" and
add /worldmap.jpg to a string. Unfortunately, the path component being returned
was maps rather than worldmap. The "worldmap" portion of the path was returned by
calling al_get_path_filename(path)

WG

Yeah, the ALLEGRO_PATH path parsing assumes a path without a slash at the end is pointing to a file. It doesn't do any detection to see if it might exist or not or what type it might be.

The solution would be to get the Folder Select dialog to create its ALLEGRO_PATH with al_create_path_for_directory instead of al_create_path because the former creates the path as a directory with no filename components, even if the path doesn't have a trailing slash.

Ah, ok.. I misunderstood what you meant the first time. So the key to making it work properly is to do this:

start=al_create_path_for_directory(path);

and then pass that starting path to the file chooser dialog?

Thanks for clarifying that.

That may also help. I was thinking you were saying that the path that al_get_native_file_dialog_path was returning was "wrong", and if so, the folder chooser should be using al_create_path_for_directory if it isn't already.

I wanted to drop a note about something I noticed tonight when I was working. There is an inconsistency with the documentation and the actual way the libary works in the filesystem code.

According to both the manual on A.cc and at docs.liballeg.org, al_make_directory should:

However, the following code shows that if the directory already exists, the function will return false rather than true. This caused me quite some trouble today before I actually thought of testing for the true return value. Was this changed a while back?

  returnValue = al_make_directory("monsters");

I was using this code to return false on a file saving routine:

if (!al_make_directory("monsters")
 return false;

After finding out about the true return values, I had to change that code to this:

al_change_directory("data");
if (!al_change_directory("monsters")
 al_make_directory("monsters");
else
 al_change_directory("..");
al_change_directory("..");

Also, since the data directory already exists, when the monsters directory did not, this command failed every time as well:

al_make_directory("data/monsters");

I assume this is because al_make_directory tries to make the parent directories as well, and since it is returning false because data already exists, it does not create the monsters directory.

Just wanted to mention that in case it wasn't an intentional change.

WG