On 01/15/2011 09:21 PM, Gerd Lorscheid wrote: Hi!
> here you can see the difference how we work. When I > prepare an opening I load a new game, and play the moves > of the opening. At the same time I follow in the game > window the matching games. I copy till here, though I use "best games" window(s) instead of the games list for this. This relates to the fact that I usually check at least two distinct DBs (OTB and CC). That is usually I do not even have the games list opened at all. I really fire it up by ctlr-l only in case I do "db editing" where I run a bunch of header searches in sequence, e.g. to attach bibliographic linking or the like. > There might be a well commented one, a game of a good > player playing the same kind of positions as me etc. To > get this info I do not want to click anywhere let's say > after every move. Copy that as well. > I can do this with Chessbase and I can do it with Scid, if > I open a tree window of my large database. When I prepare > for the next opponent I go through the opening I play and > watch in the game list the games of my opponent. This is where your filter patch comes in very handy, indeed. > So I can see where he is leaving my preparations. If I > have to click here and there every move to get this > information, I will get mad. Hm, well, probably not mad but searching for improvement ;) > So the possibility to filter the games list automatically > by the current position is essential. Right. This is what Fulvio refers to "search current board". > What I find a wrong idea is to connect the existence of > the tree window with the filtering in the game list. This > is what I would like to decouple. And here I do not entirly understand this decoupling. If I have the tree window opened I notice that Scid is actually searching the tree, updating for the current position. I also see possible alternatives to the move I might consider myself, and I understand what's going on inside. Now with this decoupling you suggest: would that mean that the games list is _always_ updated for the current board position? Ie. an automatic tree search? And this all the time? Though I've opend my tree windows all the time I indeed freeze them from time to time if I'm working on games further down the road where the DB actually ended. If I miss freezing them Scid indeed gets pretty slow due to the ongoing searching. The other point is, if you're e.g. on the above DB editing you run a header search for some event or a player or whatever. Surely you'd want to freeze the game list with the result you obtained and it should not update at all but stay at your results for otherwise you'd have to rerun the search all the time. That is, quite some work is actually not related to the current position. Btw: did (historically) the tree alway update the games list? cu Alexander ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
