Board index » cppbuilder » How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?


2005-09-20 02:46:34 AM
cppbuilder11
Help! (so far 'kbhit()' & 'GetAsyncKeyState()' do not work)
------------------------------------------------------------
BFruit.exe is a chess playing program.
BFruit.exe is targeted to run under a chess playing GUI.
Examples are the Fritz 8 GUI and the Shredder 9 UCI GUI...
BFruit.exe is an application started by the 'Console Wizard'
BFruit just wants to poll for input from the GUI
without getting stuck waiting for the GUI.
All of scanf, fscanf, gets, fgets
and the like,(feof, eof,...)...
all of them!!!!!
get stuck waiting for the GUI, ouch.
So, I want to do whatever is simple and works ...
if (no_input) get_back_to_calculations();
is there a NO_WAIT flag or switch for fgets and the like?
This is needed so BFruit.exe
can get back to his move evaluations
when there is no input
from the GUI.
Thanks Bill
//----------------------------------------------------------------------
#include <vcl.h>
#include <condefs.h>
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <process.h>
#include <conio.h>
#pragma hdrstop
// includes
#include "attack.h"
#include "book.h"
#include "fen.h"
#include "hash.h"
#include "move_do.h"
#include "option.h"
#include "pawn.h"
#include "piece.h"
#include "protocol.h"
#include "random.h"
#include "search.h"
#include "square.h"
#include "trans.h"
#include "util.h"
#include "value.h"
#include "vector.h"
//---------------------------------------------------------------------------
USEUNIT("attack.cpp");
USEUNIT("board.cpp");
USEUNIT("book.cpp");
USEUNIT("eval.cpp");
USEUNIT("fen.cpp");
USEUNIT("hash.cpp");
USEUNIT("list.cpp");
USEUNIT("material.cpp");
USEUNIT("move.cpp");
USEUNIT("move_check.cpp");
USEUNIT("move_do.cpp");
USEUNIT("move_evasion.cpp");
USEUNIT("move_gen.cpp");
USEUNIT("move_legal.cpp");
USEUNIT("option.cpp");
USEUNIT("pawn.cpp");
USEUNIT("piece.cpp");
USEUNIT("posix.cpp");
USEUNIT("protocol.cpp");
USEUNIT("pst.cpp");
USEUNIT("pv.cpp");
USEUNIT("random.cpp");
USEUNIT("recog.cpp");
USEUNIT("search.cpp");
USEUNIT("search_full.cpp");
USEUNIT("see.cpp");
USEUNIT("sort.cpp");
USEUNIT("square.cpp");
USEUNIT("trans.cpp");
USEUNIT("util.cpp");
USEUNIT("value.cpp");
USEUNIT("vector.cpp");
//---------------------------------------------------------------------------
#pragma argsused
int main(int argc, char * argv[])
{
// init
util_init();
my_random_init(); // for opening book
//printf("Fruit 2.1 UCI by Fabien Letouzey\n");
printf("BFruit_21 UCI by Fabien Letouzey and Bill Mowery\n");
//...
//---------------------------------------------------------------------------
 
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Quote
All of scanf, fscanf, gets, fgets
and the like,(feof, eof,...)...
all of them!!!!!
get stuck waiting for the GUI, ouch.
None of those functions is related to the gui.
If you are looking to detect that a key was pressed then test the return
value from kbhit()
If you wish to learn the value of the key which was pressed then call
getch().
Look at the help that came with the compiler to learn how those functions
are used.
. Ed
Quote
w h mowery jr wrote in message
news:432f072d$ XXXX@XXXXX.COM ...
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Ed Mulroy wrote:
Quote
>All of scanf, fscanf, gets, fgets
>and the like,(feof, eof,...)...
>all of them!!!!!
>get stuck waiting for the GUI, ouch.


None of those functions is related to the gui.

If you are looking to detect that a key was pressed then test the return
value from kbhit()

If you wish to learn the value of the key which was pressed then call
getch().

Look at the help that came with the compiler to learn how those functions
are used.

. Ed


>w h mowery jr wrote in message
>news:432f072d$ XXXX@XXXXX.COM ...



GUI means Graphical user Interface.
The GUI sends the commands,
not from the keyboard
when playing a chess game.
If you don't know,
please find for me someone who does,...
thanks Bill Mowery
XXXX@XXXXX.COM
 

{smallsort}

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

w h mowery jr < XXXX@XXXXX.COM >wrote:
Quote
GUI means Graphical user Interface.

The GUI sends the commands,
not from the keyboard
when playing a chess game.

If you don't know,
please find for me someone who does,...
You seem to be totally confused, and it's confusing us. Ed is perfectly
aware of what a GUI program is and how it works, and what a console
program is and how it works. Unfortunately, you seem to be confusing
them, and are coming across as somewhat rude.
A GUI program and a Console program work in totally different ways. One
is proactive - the Console program goes and looks to see if a key is
pressed, or there's something in the input buffer. The GUI program is
event driven - when a key is pressed or a menu selected, some code in
the program is then executed in response to that event.
So - you have a windows style program, and it's got a menu and buttons
and controls and the like. Now you want it to respond on any keypress,
not just on ones that correspond to controls and menus. Is that the
case?
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2004 Discworld Convention <url:dwcon.org/>
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Alan Bellingham wrote:
Quote
w h mowery jr < XXXX@XXXXX.COM >wrote:


>GUI means Graphical user Interface.
>
>The GUI sends the commands,
>not from the keyboard
>when playing a chess game.
>
>If you don't know,
>please find for me someone who does,...


You seem to be totally confused, and it's confusing us. Ed is perfectly
aware of what a GUI program is and how it works, and what a console
program is and how it works. Unfortunately, you seem to be confusing
them, and are coming across as somewhat rude.

A GUI program and a Console program work in totally different ways. One
is proactive - the Console program goes and looks to see if a key is
pressed, or there's something in the input buffer. The GUI program is
event driven - when a key is pressed or a menu selected, some code in
the program is then executed in response to that event.

So - you have a windows style program, and it's got a menu and buttons
and controls and the like. Now you want it to respond on any keypress,
not just on ones that correspond to controls and menus. Is that the
case?
Alan Bellingham
Allen:
Apologies for the parts of my question that are missing that I do not
see. My question - to me - seems to be perfectly clear. In this way I
do not know what is missing from my problem definition?
Here is another try to specify my current problem:
Fritz 8 is a chess GUI.
The Fritz 8 chess GUI loads & runs files
like Shredder 9.1 UCI (EngineShredder9UCI.exe),
like Tao 5.6 (yin56.exe)
and Fruit 2.1 (fruit_21.exe)
The GUI loads and runs the engine file.
The engine file plays chess.
BFruit.exe will be an chess playing engine file.
BFruit.exe will be run from and by the GUI.
I think the GUI's use spawn? I do not know.
Maybe the GUI's thread as sometimes the thread priority is set to 'below
normal'.
The Borland 'Console Wizard' supplied the initial template that
BFruit.exe was put into.
The GUI is a windows style program with buttons and controls, event
driven.
The engine files like yin56.exe & fruit_21.exe are not windows style
programs in that they have no controls. The engine files just receive
commands from the GUI and send information back to the GUI.
The engine files are slaves to the GUI.
Every now and then,
in the middle of a large calculation,
the chess-engine BFruit.exe
needs to poll and see if the GUI sent anything.
Right now the chess-engine BFruit.exe gets stuck waiting for input from
the GUI instead of
just polling and getting back to his calculations
when there is no new input from the GUI.
Does that explain it?
Bill MSEE (not CS)
P.S. Some code...
//----------------------------------------------------------------------
#include <vcl.h>
#include <windows.h>//for SECURITY_ATTRIBUTES
#include <stdlib.h>
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
#include <process.h>
#include <condefs.h>
#include <conio.h>
#pragma hdrstop
// includes
#include "attack.h"
#include "book.h"
#include "fen.h"
#include "hash.h"
#include "move_do.h"
#include "option.h"
#include "pawn.h"
#include "piece.h"
#include "protocol.h"
#include "random.h"
#include "search.h"
#include "square.h"
#include "trans.h"
#include "util.h"
#include "value.h"
#include "vector.h"
//---------------------------------------------------------------------------
USEUNIT("attack.cpp");
USEUNIT("board.cpp");
USEUNIT("book.cpp");
USEUNIT("eval.cpp");
USEUNIT("fen.cpp");
USEUNIT("hash.cpp");
USEUNIT("list.cpp");
USEUNIT("material.cpp");
USEUNIT("move.cpp");
USEUNIT("move_check.cpp");
USEUNIT("move_do.cpp");
USEUNIT("move_evasion.cpp");
USEUNIT("move_gen.cpp");
USEUNIT("move_legal.cpp");
USEUNIT("option.cpp");
USEUNIT("pawn.cpp");
USEUNIT("piece.cpp");
USEUNIT("posix.cpp");
USEUNIT("protocol.cpp");
USEUNIT("pst.cpp");
USEUNIT("pv.cpp");
USEUNIT("random.cpp");
USEUNIT("recog.cpp");
USEUNIT("search.cpp");
USEUNIT("search_full.cpp");
USEUNIT("see.cpp");
USEUNIT("sort.cpp");
USEUNIT("square.cpp");
USEUNIT("trans.cpp");
USEUNIT("util.cpp");
USEUNIT("value.cpp");
USEUNIT("vector.cpp");
//---------------------------------------------------------------------------
#pragma argsused
int main(int argc, char * argv[]) //WHM - the original version
{
// init
util_init();
my_random_init(); // for opening book
printf("Fruit 2.1 UCI by Fabien Letouzey and Bill Mowery\n");
.
.
.
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

w h mowery jr < XXXX@XXXXX.COM >wrote:
Quote
Apologies for the parts of my question that are missing that I do not
see. My question - to me - seems to be perfectly clear. In this way I
do not know what is missing from my problem definition?
Ah. What wasn't obvious is that you have two programs communicating with
each other.
When I saw "The engine files just receive commands from the GUI and send
information back to the GUI.", I though you meant from Windows. I didn't
realise the presence of the two programs.
In which case, as already suggested, you should probably look at
inter-process communication and named pipes.
(Though you could be crude and use a file that they both lock and
unlock. But that _is_ crude.)
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2004 Discworld Convention <url:dwcon.org/>
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Alan Bellingham wrote:
Quote
w h mowery jr < XXXX@XXXXX.COM >wrote:


>Apologies for the parts of my question that are missing that I do not
>see. My question - to me - seems to be perfectly clear. In this way I
>do not know what is missing from my problem definition?


Ah. What wasn't obvious is that you have two programs communicating with
each other.

When I saw "The engine files just receive commands from the GUI and send
information back to the GUI.", I though you meant from Windows. I didn't
realise the presence of the two programs.

In which case, as already suggested, you should probably look at
inter-process communication and named pipes.

(Though you could be crude and use a file that they both lock and
unlock. But that _is_ crude.)
Alan Bellingham
Rumer has it that a Windows API called PeekNamedPipe() can be made to
work.
So when my current chess tourney completes tonight, I'll dabble with
PeekNamedPipe(), of course tommorrow.
Aiming to get BFruit.exe to run under as many Windows chess GUI's as
possible. They are all incorporating the Universal Chess Interface
(UCI), invented by Stephan Meyer-Kahlen, a multiple world computer chess
champion and the current Blitz champ with Shredder 9.1 UCI.
So, Alan, are you interested in chess?
Bill XXXX@XXXXX.COM
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

w h mowery jr < XXXX@XXXXX.COM >wrote:
Quote
So, Alan, are you interested in chess?
Not really. I'm more a World of Warcraft person.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

w h mowery jr wrote:
Quote
Every now and then,
in the middle of a large calculation,
the chess-engine BFruit.exe
needs to poll and see if the GUI sent anything.

Right now the chess-engine BFruit.exe gets stuck waiting for input from
the GUI instead of
just polling and getting back to his calculations
when there is no new input from the GUI.

Does that explain it?
That explains your problem, but doesn't get us much closer to the
answer as you have not yet shown the polling code that is causing the
problem in the first place.
There are many ways for two programs to communicate, and more ways
than that to poll incorrectly.
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Bob Gonder wrote:
Quote
w h mowery jr wrote:


>Every now and then,
>in the middle of a large calculation,
>the chess-engine BFruit.exe
>needs to poll and see if the chess GUI sent anything.
>
>Right now the chess-engine BFruit.exe gets stuck waiting for input from
>the chess GUI instead of
>just polling and getting back to his calculations
>when there is no new input from the chess GUI.
>
>Does that explain it?


That explains your problem, but doesn't get us much closer to the
answer as you have not yet shown the polling code that is causing the
problem in the first place.
There are many ways for two programs to communicate, and more ways
than that to poll incorrectly.



There is no polling code as I have found nothing in the Borland Help
files to do polling. And I have looked hard and long since before
9/15/2005.
//----------------------------------------------------------------------
char string[65536];
int size;
/* right here i gotta poll for input because the next line gets
stuck and waits. */
my_file_read_line(stdin, string, size);
//----------------------------------------------------------------------
void my_file_read_line(FILE * file, char string[], int size)
{
char * slash_n;
ASSERT(file!=NULL);
ASSERT(string!=NULL);
ASSERT(size>0);
if (fgets(string,size,file) == NULL) // here is where we wait.
{
if (feof(file))
{
return;
}
else
{ // error
my_fatal("my_file_read_line(): fgets(): %s\n",strerror(errno));
}
}
// suppress '\n'
slash_n = strstr(string,"\n");
if (slash_n != NULL)
{
string = strtok(string, "\n"); // string_token, tokens removed...
}
}
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

w h mowery jr wrote:
Quote
There is no polling code as I have found nothing in the Borland Help
files to do polling. And I have looked hard and long since before
9/15/2005.

//----------------------------------------------------------------------
char string[65536];
int size;

/* right here i gotta poll for input because the next line gets
stuck and waits. */

my_file_read_line(stdin, string, size);
Ah, then the gui app has spawned your app and redirected the
stdin/stdout for communications.
Have you tried kbhit() ?
if( kbhit() )
{ my_file_read_line(stdin, string, size);
};
BTW, "size" should be 1, and your program should then put together the
string as the characters come in.
char* PollGui(void)
{
static char string[whatever];
static char *sp = string;
static int scount=0;
while( kbhit() )
{ *sp = getch();
++sp;
++scount;
if( scount == size )
break;
};
if( scount == size )
{
sp = string; // reset for next string
scount = 0;
return string; //process the command
}
return 0;
}
char *s = PollGui();
if( s )
{ process string s.
};
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Alan Bellingham < XXXX@XXXXX.COM >wrote:
Quote
w h mowery jr < XXXX@XXXXX.COM >wrote:

>So, Alan, are you interested in chess?

Not really. I'm more a World of Warcraft person.
The keyboard state need to get examined in Warcraft,
too, doesn't it? <g>
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

"Hendrik Schober" < XXXX@XXXXX.COM >wrote:
Quote
The keyboard state need to get examined in Warcraft,
too, doesn't it? <g>
In the code, yes, I expect so.
Actually, I do find it interesting that I can be holding down 'w' (run
forwards), and without releasing it, press Shift-1 followed by 6, and
then escape, and have all those keyboard commands recognised correctly.
And then have the release of the 'w' key recognised when I finally do
lift it.
This is keyboard handling that really, truly wouldn't have worked on the
first PCs.
I'm even more impressed though by the game's software architecture, and
its balance of what the server needs to know and calculate, and what the
local client can calculate. There are interesting data synchronisation
issues to do with the fact that to aim a blow at an opponent, both your
local client _and_ the server have to agree that you are in range. If
the client doesn't think you can do it, it doesn't bother telling the
server about the attempt. But you can end up in the situation that the
client and the server disagree about your location - so the opponent
happily bashes away at you while you are totally unable to fight back.
This is known as 'lag', and it's a pain when it does occur.
All of this to happen in soft real time.
(I'm strongly tempted to try to reverse engineer the design based on
black box observation coupled with guesses at design principles.)
However, this has departed from the group's mandate, being about
architectures rather than about the C++ language. Therefore, I'm
diverting this to borland.public.cppbuilder.non-technical
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:How does BFruit.exe poll for input from GUI without getting stuck waiting for GUI?

Alan Bellingham wrote:
Quote
There are interesting data synchronisation
issues to do with the fact that to aim a blow at an opponent, both
your local client and the server have to agree that you are in range.
If the client doesn't think you can do it, it doesn't bother telling
the server about the attempt.
I agree. For perhaps even more complexity consider this:
www.eve-online.com/guide/en/g26.asp
I don't know which side is doing the calculations but presumably it
must be the client. Eve is a very low bandwidth application and most of
the delays occur when the game is changing session (jumping into a
system, undocking or whatever).
Luckily for Eve it's not a first person shooter. Control is one step
removed so although lag might delay swapping out ammunition or a weapon
modifier it isn't a disaster. How quickly you can do something is less
important than working out what you should be doing and what you should
be doing it with. And to whom.
Sometimes the client definitely seems to be predicting the consequences
and assuming the server will agree. Sadly some of these areas have had
to be tightened up. Used to be you could dock, change ship and undock
in a couple of seconds. Now you get an annoying session change timer
which is presumably the client waiting for the server to accept the
ship change before you can undock in it.
But considering www.eve-online.com/news/newsOfEve.asp
I think CCP developers should be given a pat on the back achieving
anything let alone a successful game.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html