Community
Participate
Working Groups
The UI shows the extensions as "*.txt" while the API expects "txt" only. This is confusing. The format of the extension is not specified. The dialog should be able to tread "*.txt" as input as well and also be able to return "*.txt" (instead or in addition to "txt").
The input currently handles both by stripping out the prefix if required. Enter the following extensions bob,*.fred If you reopen the type selector it will read bob,fred
>The input currently handles both by stripping out the prefix if required. Only half true: If I use *.txt as input I would then expect that *.txt is checked in the list and not added to the others extension list.
Do you consider to fix this (i.e. that *.txt is checked if I use *.txt as input and if *.txt is part of the list)?
I have tried by entering txt and *.txt in the extensions list and in both cases when I reopen the dialog they select the right entry in the list. Can you give a case where this fails as it is a bug if it does not allow both.
I used the patch you attached to the PR and then tested the File Search dialog page: 1. Enter *.txt as file name pattern 2. Press "Browse..." ==> "*.txt" appears in the others field instead of selecting "*.txt" in the list
Replicated. Thanks for extra steps.
Problem was that your version checks labels, ours checks extension. Updated TypeFilteringDialog to check both.
I have still problems using the dialog because the dialog only returns the extension and not the full pattern: I lose information which I can not reconstruct and hence not use the dialog: Imagine I have the follwoing three patterns as input (in my Search page): *.txt, properties, plugin.xml, testFile First the information that properties is a file gets lost: it is transformed into *.properties and checked in the list. Then what I get back from the dialog is: txt, properties, plugin.xml, testFile I have no chance to tell which one comes from the list and which one comes from the others field. Couldn't you add a new constructor which then deals with input/output as if it were patterns (i.e. don't do any smart things with it)?
The problem with changing what the dialog returns is that current users of the dialog are assuming that they are getting just extensions back so changing what is returned would be a breaking API change. The input can currently take either extensions or extensions with leading code so the output is the issue. I see two approaches 1) A flag that is used to determine the output mode (i.e. withExtensions or something like that - defualt is false). 2) Some sort of alternative getResult (getResultWithWildcards()) that can give you what you are after. As I am not a fan of modes within a class (too much room for error) I think the alternative API is the best choice. Opinions?
Agree but the I also need API to SET the input to prevent "properties" being converted to *.properties.
Marking closed