I am trying to rewrite some of the Allegro source so I can try and get the native dialog to show my filename by default when I call it, and after browsing through the source, I can't seem to locate where the al_create_path() function is. It seems to me that if there is a problem, it is probably in that function as that is what is used to pass the path + filename in dialog.c.

I looked up the Windows command for opening a dialog and there definitely seems to be a fairly simple way to pass the filename to it. I would hate to have to implement this myself as I am trying to keep my game cross platform compatible, but if I can't fix the allegro function I may have to.

Unless of course al_create_native_file_dialog() has been fixed in newer builds and it now shows the filename passed to it by default? I have a hard time believing this is a difficult thing to fix and am more than willing to try my hand at it, if I don't drown first in the source.

src/path.c:154

Thanks. After looking at this for a while I decided I can more easily write my own dialog from scratch than try and figure this out.

I miss the days of Allegro 4 when things were simpler. I may ditch the idea of staying cross platform and just stick to windows.

Isn't that why you couldn't find al_create_path()? Stupid yellow dog.

If you had used grep to find it we wouldnt' be having this discussion.

git grep -n "ALLEGRO_PATH *al_create_path"
src/path.c:154:ALLEGRO_PATH *al_create_path(const char *str)
src/path.c:186:ALLEGRO_PATH *al_create_path_for_directory(const char *str)

Hmm, yeah, the win32 api is so much easier to use and makes a lot more sense than the allegro 5 api.

Lols

There is no doubt that Allegro 5 is much easier, it's why I use it. But the al_create_native_file_dialog() function won't show a default filename when you go to choose a file, even though I specify one with it.

I guess I should have clarified, I will probably use Windows specific code for saving because I really want a default filename in there. I would rewrite the allegro code myself to fix this, but it is such a confusing mess to look over the Allegro code when you're not used to it that it would be easier to use a Windows function just for this one thing.

Something like GetSaveFileName().

It's a bug likely. Someone just needs to fix it. Probably not a difficult bug to fix. But I loathe the win32 api, so I'm not likely going to be the one to do it.

I understand. I looked at it myself and haven't seen where the bug is but I figured it was an easy one to fix, but wading through that Allegro file structure when I'm not used to it, and then the thought of compiling Allegro afterwards kind of turned me off. I have had a difficult time compiling this version due to dependencies. I DID manage to get it compiled once, but then came up with a slew of problems I won't get into here. I imagine implementing that one Windows function shouldn't be much of a problem. I am thinking of just adding in some #ifdef's to check for Windows/Linux compile perhaps, if I decide to compile it for Linux in the future. <shrug>

Edit: I'll look into grabbing grep. I'm not used to working on large projects like this, but I suppose it's time I learned.

Edit2: Oh, and if the problem with this is in path.c (`al_create_path()`) as I suspect, than this wouldn't be a problem with programming the Windows API, but more of an Allegro specific problem parsing the path + filename string that is sent to that function. I would be curious if anyone has noticed the missing filename on other platforms like Linux?

al_create_path doesn't remove filenames. Though if you call al_create_path_for_directory it'll treat the last path component as a directory rather than a filename, even if the path doesn't end with a path separator. Also if the dialog code could be stripping the filename from the path it sends to the dialog function. Not entirely sure why it'd do that, but it could be.

I took a quick look at the native file dialog code and I couldn't see anything that screamed wrong at me, but I only took a quick look.