Community
Participate
Working Groups
DLW (6/15/01 1:19:40 PM) I would suggest that we modify the FileDialog's open() method to include the following logic (just before or after the similar code for SWT.MULTI): if ((style & SWT.SAVE) != 0) { struct.Flags |= OFN_OVERWRITEPROMPT; } This is low priority, so obviously don't need in near future, but this is also an easy change if you decide to accept it. Since users of the SWT FileDialog aren't able to modify this behavior themselves, I'd think it would be better to default this way than not. NOTES:
PRODUCT VERSION: win32 0.112
Has this been fixed? Please mark PR as FIXED or LATER as appropriate.
The problem is that if this behavior is added but not supported on other platforms, then applications applications not running on Windows will not prompt for overwrite.
We obviously have the tension between platform behavior and portability here. Are you saying that adding the prompt will affect SWT API? If so, then I agree this is an issue on other platforms. However, if this native behavior is encapsulated in the API (e.g. no return code is issued as to whether "overwrite" was selected), then I see no harm in modifying the Windows version to behave this way.
If the Windows code is modified to prompt for overwrite, application will be written that rely on this (ie. don't include the check for overwrite) and when these application run elsewhere, they won't ever check for overwrite. It's possible to solve this by adding a new flag, that is documented to be a hint. It's also possible to add the overwrite checking code on other platforms and have it run after the native dialog has closed. If the file exists, and the user selects "don't overwrite", the native file dialog could be opened again. These are the only solutions I can think of right now.
The resolution of this bug seems to have bogged down around a reasonable question, but as a developer trying to use SWT for cross-platform desktop apps, I strongly encourage this one-line fix. As it currently stands, neither platform behavior *nor* portability are served, because either it's not platform-consistent, or developers like me will have to hack up my own version of FileDialog, which is a terrible thing to do for many reasons. It's *far* better for me to get the "overwrite prompt" behavior, but to follow the API which should say "FileDialog with SAVE style does *not* guarantee the non-existence of the file; beware of overwriting existing files if that's your intended behavior". Because I need cross-platform behavior, I've already written the "if file exists, put up an alert and possibly loop back to the file dialog" logic. Thus, I will get the best of both worlds, portability AND platform behavior, if the overwrite prompt flag is set. Having it be an optional "hint style" is fine, though I personally have no need for *not* setting it (so far :-), and one potential drawback of the hint is that it might encourage non-portable code among weaker coders, so I understand either decision on that. Please please please take a look at this again - it's a simple but important fix! (And by the way, I *LOVE* SWT, so thanks for your efforts, they are appreciated!)
*** Bug 4558 has been marked as a duplicate of this bug. ***
Wow, this has been around for awhile. I agree something should be done. It's not possible to write a production application without verifying the user wants overwrite. It looks pretty tacky if the dialog goes away while verifying. a) If there is platform support for it, it should be implemented as a side effect of SAVE. That's what everyone will want. b) Either provide a platform-independent tacky version for platforms that don't support it, or at least extend the API to allow a developer to test whether SAVE implies overwrite check. hasSaveOverwriteCheck() or something like that. c) A third option would be not to default it anywhere, but require the developer explicitly turn the check on. The method to do so could return boolean to indicate whether the platform supports the feature. (I believe there is some precedent for this, but can't recall where offhand.) The worst case would be to do nothing. The second worst would be to require the developer be aware how all possible platforms behave. Thanks, Steve, for pointing out this oldie-but-goodie.
I'd like to point out that the mac file dialog does ask if you want to overwrite an existing file. Personally I think that this should be the behaviour on all platform regardless if the platform supplies native support for it or not.
"prompt-on-overwrite or not" seems like an application decision to me. If the application says prompt, then the user should always get a prompt. If some platforms provide this natively and some don't then it seems natural to emulate the behavior on platforms that don't. If the application says don't prompt, then it should never prompt. I'm assuming all platforms allow the prompt to be turned off. Is that technically feasible? I think it's the same thing that Steve said in comment #5.
This is now many years old and it appears as though in 3.3 this has not yet been addressed in any way. Is there any intention of resolving this or has anyone put together a solution in some form?
Ok Carolyn, how about addressing this along with the other FileDialog bug we were considering? You have ownership of this and please take ownership of the other one. We can talk about it next week when I am back.
OK. So the (interesting) missing piece of the puzzle is what does GTK do? The answer is that the (gtk 2.4.10 and up) FileChooserDialog has a function called gtk_file_chooser_set_do_overwrite_confirmation which does exactly what we want. I agree with Ed that the application needs to decide whether or not they want the prompt. An example use that comes to mind is this: say the user types "newfile.txt" for the file name to save, and it already exists. The application prefers to just write out "newfile1.txt" instead of bothering the user with yet another prompt. Steve, if you agree that the app needs to be able to turn this feature on/off, then we need to define a new style bit (SWT.OVERWRITE_PROMPT, say) and it needs to be a hint because the old (pre gtk 2.4.10) GtkFileSelection dialog does not have this feature. Just to confirm the details of the feature on OS X Carbon, the prompt is on by default and you need to set the kNavDontConfirmReplacement option to turn it off. I see that we are not currently doing this, so at the moment, we are not consistent. Steve, would you prefer that the *default* state of the style be "off" (i.e. no prompt - the current Windows and GTK behavior) or "on" (i.e. prompt - the current Mac behavior). There are pros & cons for both. "On (prompt)" is the typical state for most applications. "Off (no prompt)" would mean that fewer SWT users would get a free magic change, however it also means that Mac SWT users could suddenly be overwriting files without intending to. Up to you... <g>
I hope this hasn't died and that it makes it into 3.4. I'm relatively new to Java and SWT. This seems like a significant "hole", from an application developer and user's point of view. The work-around, while effective, is somewhat funky. Any chance this will be included in 3.4? Thanks.
Car, just fix it. Don't add the style bit, add the API FileDialog.get/setOverwrite() or something like that. Application programmers can set the API, then query it back to see whether the operating system allows it. Make the default the same for all platforms (off because application code is relying on that). API freeze is next week. We can settle on the final name Monday.
Fixed > 20080324. The name is get/setOverwrite(boolean). Default is false, except on Cocoa - see bug 223703.
