Pascal Georges wrote:
Hi!
> I see no bug in what you write, and this behavior has
> always been there : the Filter object is unique for every
> base.
I know.
> The filter is set by search functions, and the Tree is a
> kind of search function (looking for a position).
Yes. I know that as well.
But CVS _overwrites_ the header search I initiated with the
results of a tree search that happend _before_ I initiated
the header search. There's a clear timeline here. I've to
close the tree window to get proper search results.
If this is intended, Header search will have to close the
tree view automatically before it executes the search.
> Maybe the way things are refreshed and overwritten have
> changed since 3.6.24 (depending of the Tree mode, like
> "fast" and "slow"),
I use always slow. Resorting a database every other month is
not an option, especially not for reference bases with
several millions of games.
> I don't know, but the collision in the filter has always
> been there.
This may be true.
But what I speak of has a time line. There are subsequent
user actionas: I open a view to the DB called Tree. Fine.
The filter is set accordingly, well this might also be fine.
THEN I do a header search AFTERWARDS, but the results are
NOT shown. Why? Simply cause a window is open. This just can
not be, it is not logical, especially as there is no link
(from a users perspective) between the tree window and the
header search and as there is a clear time line. FIRST I do
this THEN I do that.
I only came to the solution cause I knew that you did
something in the tree window anyway, and you can not expect
a users to keep your code changes in mind.
> To get the "expected" behavior for the user means to play
> with the ability to open multiple trees, for example.
No. Not at all. This would be nice, but is absoultely not
required to get it working properly.
> There is no standard behavior, sometimes you may want to
> see only games from one player in the Tree, sometimes all
> games in the base.
AFAIK I can not procude a tree for a specific player in any
other way than extracting the games of this specific player
to some other database (say clipbase).
> This implies to play with filtering and using clipboard to
> get the expected result.
That all does not touch the point.
The standard behaviour is very simple: If I do a search, I
expect the search results to show up. If I do one search
after another I expect the last search to show up till I do
the next search. Currently, this is NOT the case.
Probably, it would make sense to refresh the game list with
tree results again if the tree window gets back the focus.
I'm not even sure that this would make sense at all.
But, it is still completely sensless that I run a search
over several million games which may take several minutes,
if I have to search free PGN header tags, and just get no
result simply cause I've a minimised tree window somewhere
that hinders the game list to get updated properly.
If you search for "Pascal" in a text file and after that
search the same file for "George" but you get the results
for "Pascal" displayed you'd also see this as a bug.
Current CVS implements exactly this behaviour and this does
not make any sense.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
