Community
Participate
Working Groups
see attached image. The wizard for creating a new product opens with a file name initialized to ".product" which is selected. Generally this would imply that this is a good default but if you start typing you will replace the text with something else that is also a good name. If you require an extension for a file you should add it yourself like the "Export Archive" wizard.
Created attachment 37616 [details] wizard
>If you require an extension for a file you should add it yourself like the >"Export Archive" wizard. Good suggestion, but won't work in this case due to the validation logic on the page (which is the standard platform/ui behaviour) If the user enters 'bla', and a file by that name already exists, we get an error indicating so, even though the end result will be a "bla.product" file, which may or may not exist. The problem here as I see it is that we have no direct control over the text field nor the initial selection of WizardNewFileCreationPage (from Platform/UI). That is why the wizard comes up with the entire '.product' selected. Note that pre-setting the field with '.product' is important since we don't want people to type the long extension themselves. So a good solution would be for WizardNewFileCreationPage to not select the entire content of the file name, but instead just position the cursor at the first position.
Should we change the behavior in the setFocus() method of ResourceAndContainerGroup? I presume selecting the text was done for a reason e.g. an initial file name could be suggested but is selected initially so that if a user would like to change it then he doesn't need to ctrl-a to select all the text to clear it (see Save As dialog for example). As a side note, if you override the setVisible() method of your wizard page and just call getControl().setVisible(visible) then the text in the file name field will not be selected. The only problem with this solution is the focus will no longer initially be in the file name field, it will be in the parent folder field.
A couple things: First let's agree on what the scenario should do ideally then fix the problems where they exist. I.e in the framework or in the PDE code. - putting the extension in and placing the cursor at the front is not typical. Most apps just remove the worry of having to type in the extension at all that should be your goal. - doing it this way also removes the need to throw up an error when the name does not end with .product
re comment 4, if we go with this suggestion, the wizard validation of whether a file by that name already exists would be bogus if the file name field did not end with .product. you would be validating a file name that is not what the actual file name is going to be at the end after .product is implicitly added. This would be even more atypical than pre-setting the field with .product.
A few comments. "if we go with this suggestion, the wizard validation of whether a file by that name already exists would be bogus if the file name field did not end with .product." I don't dissagree, but I think your missing my point. The goal is to make this as smooth and easy to use as possible and not make the user have to know and be responsible for things they don't care about. So the error should just not be there in the wizard as opposed to being there with a bogus file name. The pattern I see in other applications it one of the following two: A) after a file name is entered and focus leaves the field the extension is automatically tacked on to the end (e.g. MS Word > Save As...) B) the extension is not added to the file until finish is pressed, at that point only if the <file name>.product file exists is there a separate dialog opening up asking if you want to overwrite the existing file So the point is remove the validation and errors from the wizard as that is just more noise for the user, if on finish there is a problem OR perhaps if they do infact type in the whole name with .product only then should you raise the warning concerning over-writing another file and you would never have to have an error that says they need to add .product to their file name. "This would be even more atypical than pre-setting the field with .product." Please have a look around at what other apps do. Also what other wizards do.
I've created a patch to tackle the discussed problems. Please see attached Patch #1 Overview: If a default file extension is specified, then it will be appended with a '.' to the text from the file name field for validation only if the following conditions are met: (1) Default file extension length is greater than 0 (2) File name field text length is greater than 0 (3) File name field text does not end with a '.' and the default file extension specified (case sensitive) The default file extension will not be reflected in the actual file name field until the file name field loses focus. It would have been better to add the default file extension when the "Finish" or "Next" button is pressed down; however, it is not easy to get access to either button given the way the current API is setup for wizards. If no default file extension is specified, then it is assumed that the user must manually enter the file extension in the file name field. As a result, strict backwards compatibility is maintained. If no default file extension is specified, then the old behaviour is used. The critical transition points between the old and new behaviour can be found here: org.eclipse.ui.dialogs.WizardNewFileCreationPage.setDefaultFileExtension(String) org.eclipse.ui.internal.ide.misc.ResourceAndContainerGroup.getResource() Work Done: * Created new wizard API to allow clients to specify a default file extension that will be added to the file name field text during validation without storing it in the actual field * Updated 'resource already exists' error message to specify the resource name * Implemented a feature to append a client specified default file extension to the file name field when focus is lost * Added full API comments to all methods and instance variables * Tested new API using updated cheat sheet file wizard * Tested old API (including new changes) using existing product file wizard
Created attachment 56740 [details] Patch #1
The patch seems reasonable to me. I tried it out with the PDE Product wizard and it seems to behave as intended. Tod, are we ok with adding the new API to WizardNewFileCreationPage? I have a couple of minor nits though: 1. The file extension you specify is the *only* one that can be used for that page and it will be used regardless of whether or not the user deletes the .product extension in the file name field. So perhaps the method should be called setFileExtension() rather than setDefaultFileExtension() - it's not really a default, it's the only one allowed! Also, this should be calrified in the setFileExtension() method. 2. I am not sure if you can make the following statement in the setFileExtension() method: * If no default file extension is specified, then it is assumed that the * user must manually enter the file extension in the file name field. because subclasses can add a file extension in their page's logic somewhere in between calling getFileName() and creating the file (it appears the new java snippet file wizard does this).
Hi Karice, Thanks a lot for the feedback. I'll make the changes you suggested for (1) and (2) in Comment #9 and repost the patch.
Created attachment 57482 [details] Patch #2
Hi Karice, I updated the patch according to your feedback. For (1), I removed the "default" substring from the getter and setter methods and updated comments to reflect that the file extension is the only one allowed. For (2), I removed the comment indicating the user must manually enter the file extension if not specified. Please see attached Patch # 2.
Patch released for build > 20070129, with one minor change - I changed the FocusListener to a FocusAdapter so the no-op focusGained() method doesn't need to be present.
Any chance this patch could be applied to the 3.2 stream? Is there going to be a 3.2.3?
If you check the Eclipse dev site, there are currently no plans for a 3.2.3 release: http://www.eclipse.org/eclipse/development/ If this changes, open a new bug requesting the fix for this bug go into 3.2.3
