Enter chess moves with Visual Foxpro 4

[german12]

I have a lot of chess books because I've been playing for a long time.
For a special opening I am always looking for variants, but they are difficult to find in my literature.
Now - when I've found something - I want these moves
transferred to a separate Foxpro table.
This would also have the advantage that you can then use a program to remove duplicate variants, or to index or recognize transpositions of moves, etc.
It's faster than writing it down, and I programmed a keyboard to do this.
In the photo you can see this keyboard at the top left.

The program works fine up to this point.

Example 1:
The move with the rook on the e4 square is displayed after clicking R-e-4 in the text field (text1, yellow).

Now I want this content in the table below
in the field M1 (means: Move No.1).
Field-names are M1 to M20
Then I want to type the next move on the keyboard again
and that should then be saved in field M2.
This is how it should go on .... next move in M3 .... etc.

So it is a horizontal filling of the table.
Example 2:
The table should look like this:
Row 1: e4 c5 Nf3 Nb6 d4
Row2: d4 Nf6 Nc3 d5 Bg5 c6

That means the length of the variants can be different.
My table is sufficient for 20 moves (half moves).

Each time a new series of moves is entered, a
new data set is necessary.

Maybe someone can help what the code behind the button "Transfer to table" (red) could be like, or there is a better idea.

I would be very pleased.
Thank you.

Greetings Klaus

By the way:
If you wanted to record all possible moves within a game of chess in a database, then there would be
big problems: at some point I read that there were 10 to the power of 35 possibilities. (So ​​a 10 with 35 zeros).


Peace worldwide - it starts here...

 

[Chris Miller]

My code was only made to find out, what space would be used, when I fill a table with 200,000 records.

Oh, that would have been simple, in a DBF all records have the same size RECSIZE(), no matter whether you're storing in char or varchar fields. The sizes of FPT and CDX file will depend on what is stored there and what indexes are defined.

Only Memos storing the whole game can save space, but they use 4bytes in the DBF file as starting pointer into the FPT file without storing anything, so storing just single moves is less effective, that's why Tom made his example with a memo for the whole game, which I think will bring you forward better than the half moves idea.

If you store (for example) "1. f4 e6 2. Nf3 d5 3. e3 c5 4. b3 f6 5. Bd3 g6 6. Qe2" into the "Zuege" memo, you can find this opening with index on LEFT(Zuege,240) you can make searches of partial openings, ie SEEK '1. f4' will find this opening as well as SEEK '1. f4 e6' or other partial string searches. So while you play a new game and want to see how openings of your database continue, this will find them. And that's much simpler than trying to search for M1='f4' and M2='e6' and so on. So it makes searches easier and you store a game shorter than with 20 fields.


Chriss

 

[german12]

Tom and Chris:
Thank you for further valuable advice on how to improve the program

Buttons
The click of the buttons could do something like that :
Thisform.odata.zuege = Thisform.odata.zuege + this.caption && assuming caption of button = text to insert

I also used the idea of the caption on my keyboard. For chess moves you only need a few keys.
For the figures: R, N, B, K, Q -
for the coordinates on the chessboard: a, b, c, d, e, f, g, h and
1,2,3,4,5,6,7,8, for castling 0-0 + 0-0 0 and noauf ch
en-passant ep,
Beat symbol x
and possibly also about the outcome of the game (draw, white wins, black wins)

Player names could come from another table

The players or the venue are not that important to me, it may just be unnecessary work when collecting the data. You can do that in exceptional cases (e.g. if well-known grandmasters have played it, but you have to judge the position yourself anyway and not just look at the name, the grandmasters sometimes make glaring mistakes, it is actually enough after a few moves to judge whether I like such a game.

And that's much simpler than trying to search for M1='f4' and M2=

that is correct, and now I also believe that it is better to work with memo fields instead of half-moves, because you can easily get a whole game into there with drag and drop.


Thanks also for the tips on how to search in memo fields.

Greetings to both of you from Lingen (on the border with the Netherlands)
Klaus









Peace worldwide - it starts here...

 

[tomk3]

Hello,

just to add to chris :
You may also find something with the $ operator and locate.
Its slower then seek, but can search after 250 Bytes (max len of index), something like
csuch = "a2 a4"
locate for cSuch$zuege

$ can also be used to get all matches into a cursor (a temp table) which maybe shown in a separate grid,
select * from chess where csuch$zuege into cursor c_treffer

or use it as a filter
set filter to csuch$zuege
browse

Best regrads
tom

200.000 Records is no much for vfp, if you exceed 2GB you may switch to MS-SQL, MYSQL,... for database

 

[german12]

Hi Tom,
I know the $ operator - but I'm still happy that you remind me of it.
Thank you.
I intend to collect information only for a special opening first.
The space for this will be clearly enough with VFP.
I also believe that 2 GB maximum size of a table file.
plays no role - because you could
call up a new table for a new opening,
and if necessary close the old table.
Or did I get this wrong?

Keep healthy
Klaus


Peace worldwide - it starts here...

 

[tomk3]

Hi Klaus,

I think you want to save all interesting openings in a dbf, even if it needs 1000 bytes for zuege and title , you may save nearly 2.000.000 openings before touching the 2GB limit. And I guess, 200 Bytes will be enough...

Yes, you could begin a new table when reaching the limit
(or us sql-database for storing)

Best regards
Stay healthy
tom