Repeated search: entry fields should respect data changes

[Andreas Schnellbacher]

After a search action, the first entry field 'Files to search for' is filled with data and maybe also the second 'Text to search for (if any)'. In this state everything works as expected, except for that 'Search results history' wasn't filled with data.

If I change an entry field and execute the second search, also the entry field 'Search results history' is filled with data. From then on, any change of one of the first two entry fields won't be overtaken, if I press the 'Search' button. The previous data of all three entry fields from the last search is restored.

It works only, if I change the entry filed data plus the line in 'Search results history'.

As a result, I see two future changes:

1. A data change of one of the two entry fields 'Files to search for' and 'Text to search for (if any)' should be overtaken and maybe change the line in the third entry field 'Search results history' immediately, at least after the search.

2. Fill the 'Search result history' entry field with data already after the first search.

IIRC, this has worked with Alessandro's last version, hence the 'Version 1.0' entry. I'll check that on your demand.

[Andreas Schnellbacher]

I've just noticed that apparently auto-completion of entry field data, based on the search history, might happen. An example:

I open DataSeeker? from a folder's context menu. That leads to a prefilled entry field 'Files to search for' with e.g. 'G:\Dev\netlabs\*'.

Then I enter 'kdiff3' in the entry field 'Text to search for'.

Pressing the Search button or hitting the Return key searches all files for that string.

Then I do a second search: I change the search string from 'kdiff3' to 'kdiff' and hit Return.

The entry field is restored with previous search data and changes immediately to 'kdiff3'. Apparently that would happen with every search string that I try, which starts with a 'k'.

A search string with another leading letter works, but only if it's not already with a different full string in the search history.

I hope that makes the problem clear now.

[Andreas Schnellbacher]

I've just found a workaround, how I can can bypass the problem:

In the example above, after deletion of the '3', the cursor must be placed in another entry field to save the data of the Text entry field. Only then the Search button can be pressed without restoring the text string back to 'kdiff3'.

That means: Apparently the data of an entry field is saved only when moving the cursor to another entry field.

Solution: On pressing the Search button, save also the data of those entry fields, whose data have changed. Perform the search only after that.

[andib]

Thanks for the detailed description. This problem annoys my too since years.

I (once again) tried to track down this. I added some debug code and I now think this is a feature of the standard OS/2 ComboBox?/dialog. Changing the text in the entry field of the ComboBox? and pressing Enter (which is handled by the dialog window) without changing the focus away from the ComboBox? refreshes the ComboBox? entry field with a matching entry of the list box (if exists). Which means, if you delete some characters from the end of the entry field without changing the focus, the entry line text will be restored with the the matching entry of the list box (with the additional characters at the end).

I tried some SETFOCUS code but couldn't find a solution to this. Maybe the ComboBox? have to be subclassed to change such behavior. But I'm not experienced enough to do that. Maybe someone else has some other hints about that. But guess it's not worth the effort to spend even more time on that.