>> On 10-11-2017, at 5:53 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> If I highlight a specific file on the lower right side, that becomes the new suggested
>> file name in the top edit box. This makes sense if the file I select is foo.image but
>> not if it is foo.changes or foo.cs or foo.txt.


>> 
>> I think that I would expect the dialog (lower right side) to present only the file
>> names that I can legitimately select (because they end in '.image'). Or I would
>> expect it to "grey out" the entries that I am not permitted to use, such that only
>> file names that end in '.image' can be highlighted and thus moved into the top
>> file name edit box.

I added setting a pattern list in the creation methods and it works ok; I’d prefer to have the file list able to show everything and grey out the invalid ones but that’s a job for anyone wanting to improve the multicolumn list stuff.

What is eluding me right now is a good heuristic to handle a typed in filename that doesn’t match the pattern. Obviously we can do what we want in the #inputText: method to test the proposed name but I’m just blanking on what that might be. Test against the list of patterns I suppose is a start … and what it if doesn’t? What’s the way to tell an input field to sound the klaxons and flash disaster-red to alert the user that they are an idiot?

>> 
>> I think I would also expect the suggested file name that initially appears in the
>> top edit box to also be highlighted in the panels below. If my current image name
>> is 'foo.image' then I would expect 'foo.image' to appear both in the edit box on
>> the top, and also as the selected file in the lower right navigator pane.

OK, easily fixed and definitely an improvement.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: RDRI: Rotate Disk Right Immediate