Re: [AD] file_select_ex patch

[Chris <chris.kcat@xxxxxxxxxx>]

On Monday 12 September 2005 10:27 am, Grzegorz Adam Hankiewicz wrote:
> Instead of playing fire
> with a buffer whose size Allegro doesn't know, and could overflow

Actually, file_select_ex takes a size parameter for the buffer, so it won't 
overrun.

> Other than that, I think it's ok to mess with path. After all, if
> the function returns zero, user code is not going to use the path
> parameter any more because the user doesn't want to load whatever
> garbage Allegro might have spilled over that variable (even if it
> is a valid filename). Can you provide a use case where preserving
> path's content is necessary with a cancel return value?

What I tried doing in this case was create a d_box/edit/button_proc dialog 
combo to create an editable path area with a browse button. When the button 
is clicked, it exits the dialog, calls file_select_ex with d_edit_proc's dp 
pointer, and then reruns the dialog. However, since the path is not restored 
when clicking Cancel, clicking it is basically the same as clicking OK. What 
I ended up doing was create my own backup buffer, and if Cancel was detected, 
restore the .dp contents myself. It just feels like this is something the 
function itself should've done, though.