On 01/23/11 00:46, Gerd Lorscheid wrote:
Hi!
> 1. Switching databases does not remove unsaved games
> 2. When you call ctrl-x you can see in the switcher what is the current
> database.
> The harmful operation is "sc_game load ...", which does remove an existing
> game and load a new one without
> > You have mixed up core changes like inlining
> ReadTwoBytes
> > with the bestgames feature change. These should be in
> separate patches, not together. Large patches like this
> should have documentation about wtf they do. Ditto the
> Storedline changes.
> > You've removed the button bar. Congr
Steven wrote:
> You have mixed up core changes like inlining ReadTwoBytes
> with the bestgames feature change. These should be in separate patches, not
> together. Large patches like this should have
> documentation about wtf they do. Ditto the Storedline changes.
> You've removed the button bar.
I haven't had time to ~really~ look it over, but these are my
initial observations. Obviously they don't mean too much
anyway.
> Yes, the code is primitive
Of course there's no way Alex could accept this in any short
period of time.
Thanks for the patch. Your contributions are very good :>
B
, what's your opinion on the tree & filter behavior?
>Messaggio originale
>Da: stevena...@yahoo.com
>Data: 23/01/2011 21.18
>A: "f...@libero.it"
>Cc: "Scid Users List"
>Ogg: Re: [Scid-users] Potential data loss using trees
>
>Interesti
Interesting!
But so many bugs.
1. In undocked mode. Open database -> Click on tree toolbar icon ->Try to close
tree windo (won't close)
2. Open database -> Click on tree toolbar icon twice -> Click on best games
icon ->core dump.
S.
--
n of these changes.
Gerd
-Ursprüngliche Nachricht-
Von: f...@libero.it [mailto:f...@libero.it]
Gesendet: Samstag, 22. Januar 2011 22:01
An: Scid Users List
Betreff: Re: [Scid-users] Potential data loss using trees
I'm using a modified version, so my suggestion may be wrong
ulvio
>Messaggio originale
>Da: joost.t.h...@planet.nl
>Data: 22/01/2011 12.35
>A: "Gerd Lorscheid"
>Cc: "Scid Users List"
>Ogg: Re: [Scid-users] Potential data loss using trees
>
>Hi,
>
>I suggest we analyze this issue a bit further...
>
>On 10/08
r dentist will do when he has time and you have money I have
> described also below.
I resign.
Joost.
> Gerd
>
>
>
>
> -Ursprüngliche Nachricht-
> Von: Joost 't Hart [mailto:joost.t.h...@planet.nl]
> Gesendet: Samstag, 22. Januar 2011 20:25
> An:
sprüngliche Nachricht-
Von: Joost 't Hart [mailto:joost.t.h...@planet.nl]
Gesendet: Samstag, 22. Januar 2011 20:25
An: Gerd Lorscheid
Cc: 'Scid Users List'
Betreff: Re: AW: AW: [Scid-users] Potential data loss using trees
On 01/22/2011 07:33 PM, Gerd Lorscheid wrote:
Hi!
>
>
> -Ursprüngliche Nachricht-
> Von: Joost 't Hart [mailto:joost.t.h...@planet.nl]
> Gesendet: Samstag, 22. Januar 2011 19:15
> An: Gerd Lorscheid
> Cc: 'Scid Users List'
> Betreff: Re: AW: [Scid-users] Potential data loss using trees
>
> On 01/22/2011 04:36
#x27;Scid Users List'
Betreff: Re: AW: [Scid-users] Potential data loss using trees
On 01/22/2011 04:36 PM, Gerd Lorscheid wrote:
> Hello,
>
> I cannot solve all problems with one small fix.
Probably true, but I do not think that anybody was expecting this.
> The location, whi
t: Samstag, 22. Januar 2011 12:35
> An: Gerd Lorscheid
> Cc: 'Scid Users List'
> Betreff: Re: [Scid-users] Potential data loss using trees
>
> Hi,
>
> I suggest we analyze this issue a bit further...
>
> On 10/08/2010 06:20 PM, Joost 't Hart wrote:
>> Hi!
mstag, 22. Januar 2011 12:35
An: Gerd Lorscheid
Cc: 'Scid Users List'
Betreff: Re: [Scid-users] Potential data loss using trees
Hi,
I suggest we analyze this issue a bit further...
On 10/08/2010 06:20 PM, Joost 't Hart wrote:
> Hi!
>
> [Linux, CVS]
>
> 1a) Open a dbase
Hi,
I suggest we analyze this issue a bit further...
On 10/08/2010 06:20 PM, Joost 't Hart wrote:
> Hi!
>
> [Linux, CVS]
>
> 1a) Open a dbase in which you want to add a new game
> 2a) Open-as-tree some big reference database (~4M games, dunno if size
> matters here)
>
> Do NOT wait for (2a) - whi
On 01/20/2011 10:04 AM, Joost 't Hart wrote:
Hi!
>> Hmmm... Yes this fixes the reported issue,
>
> Ok.This is something I know how to reproduce and verify.
> If there is no chance of side impact (without air bags) I will do so
> and commit this.
> If not, we'd better keep things on the shelf unti
On Thu, Jan 20, 2011 at 9:47 AM, Steven wrote:
> Hmmm... Yes this fixes the reported issue,
Ok.This is something I know how to reproduce and verify.
If there is no chance of side impact (without air bags) I will do so
and commit this.
If not, we'd better keep things on the shelf until after 4.3,
Hmmm... Yes this fixes the reported issue,
but despite the comment, i'm not clear on why
sc_game load [sc_filter first]
is being called.
Is it necessary to load the first filter game
"to directly generate an opening report" ?
And if so, then that means the opening report will not be
generated
On 01/19/2011 09:03 PM, Gerd Lorscheid wrote:
Hi Gerd,
Should this maybe also solve a problem that I reported previously?
Something like.
1) Open (big) base
2) Open tree of (1)
3) Before (2) completes start a new game in (1) and enter a few moves
4) Observe that new game is destroyed upon comple
Hello,
at the end of ::tree::dorefresh you find the following code:
# if the Tree base is not the current one, updates the Tree base to the
first game in filter : that way it is possible to
# directly generate an opening report for example
if {$baseNumber != [sc_base current] } {
20 matches
Mail list logo
