April 20th, 2003, 11:24 AM
What I was thinking of for having the server ACK a move would be something like the following pseudocode:
Think of a terminal emulator (like HyperTerminal) or a telnet session, where you can turn local echo off and have the other end echo your transmitted data back so that your local display comes from the other machine. That way, if you do not see anything display when you type, you know that there's something wrong with that connection.
client user enters a move;
client sends move to server;
client calls recvfrom to listen for message from server;
server updates game state;
server sends updated game state to all clients;
client receives game status;
client updates his own knowledge of the game state, which includes updating the board display;
if client just sent a new move and is waiting for ACK
call recvfrom to listen for next message from server;
prompt the user to enter the next move
I was thinking along the lines of having the client update his display only in response to a message from the server. Then the client needs to be smart enough to remember whether he had just sent that move to the server or not.
April 20th, 2003, 03:00 PM
he shoots......it's in....it's out.... HE SCORES!!! yes!! got it 95% working!! all i have to do is iron out some kinks, like it says the wrong person has won the game and whatnot, but that's small fries!! i ditched the ack, but now im gonna go back and put it in and make this thing presentable. thanks much for the suggestions, definitly helped me out a lot. :D :)
edit: worked out the above problems, 100% functional....well, that is if the user is nice to it - i.e. while it is in recieve mode u can fuxx0r it up by clicking repeatedly around the window. but if u play nicely it works fine. i realize that in order for it to be a more robust program the client side has to multithreaded, at least the recieve function needs to be a separate thread since it is waiting on the other user. im debating how i would go about doing this - in order to play teh game, i create a PlayGame object in my WinMain and call it's various member functions throughout MyWndProc. So, i think to create a thread i would have to define another member function in the PlayGame class that would be responsible for starting a thread(calling the recive function in that same class).
edit2: here's a simple questoin i cant seem to answer: how to "grey out" a menu option? -so it cant be selected until further action. and of course how to "un grey" it as well?
Last edited by infamous41md; April 20th, 2003 at 05:12 PM.
April 20th, 2003, 05:50 PM
That's good news! Wasn't that fun? (As our dance instructor says right after demonstrating the elaborate move we're about to learn: "It's going to be fun!" Scarier words were never heard!)
Command UI. In Class Wizard for the message handlers, you should see a message UPDATE_COMMAND_UI. Add a function for that. In that function, which passes in a CCmdUI* pCmdUI, you will call pCmdUI->Enable(BOOL). That BOOL parameter could be an explicit true or false, or it could be a function or variable of BOOL type. The main thing is that you will test for the condition to enable that control ("un grey" it) and pass in a true, else you will disable it ("grey out" it).
I explained it that way because you said that you're using Visual C++. For a lurker who uses something else, there should be something similar in the other development systems. I think Petzold covers it too.
April 20th, 2003, 06:17 PM
hmm, i got the impression that u think im using MFC? just using win32 api, no MFC Class Wizards. either that or i dont know what ur talking about :confused:
UPDATE_COMMAND_UI -> but im guessing that this is a message in the WndProc? i'll try sticking it there to see what i come up with.
April 20th, 2003, 07:41 PM
My Petzold book is at work, so no access to it until tomorrow.
Try WM_UPDATE_COMMAND_UI. Though I'm not sure from there how to enable and disable the menu item. There are constants for checking and unchecking (MF_CHECKED & MF_UNCHECKED), so the enabled/disabled constants should be similar and nearby in windows.h (or window.h -- I can't check now because my laptop is running Linux at the moment). Then Google should have an answer for you.
April 21st, 2003, 10:48 AM
OK, I'm at work now.
"Programming Windows 95" by Charles Petzold, pages 507-508, section "Enabling Menu Items", shows the use of the Win32 API function, EnableMenuItem; e.g.,
EnableMenuItem((HMENU)wParam, IDM_COPY, MF_GRAYED); // to gray out the Edit/Copy menu item.
From the Visual C++ 6 help:
Hope that helps.
April 21st, 2003, 01:27 PM
thanks, that's what i was looking for. I wish i had that VS help cd, but i have a non registered version of VS w/o help. i asked my teacher after class, and he replies "umm, let me get back to u" :rolleyes:
April 21st, 2003, 02:54 PM
Another source would be the Microsoft Developers Network (MSDN) at http://msdn.microsoft.com/default.asp . I just looked up EnableMenuItem and the same entry is there as is in the help CD.
Of course, you also had to know that that was the function that you needed.
April 21st, 2003, 03:54 PM
any clue as to what im doing wrong? nothing happens, when i try this:
EnableMenuItem((HMENU)IDR_MENU1, ID_EXIT, MF_GRAYED);
EnableMenuItem((HMENU)wParam, ID_EXIT, MF_GRAYED);
-i've tried putting these in various places in my WndProc. The "handle to the menu" - is that not the resource name? I also tried explicity creating a handle, like so:
HANDLE menHand = (void *) IDR_MENU1 , with no luck. and yes msdn is a great resource, i use that site often to look up errors. im still determined to get my hands on that help cd, but my social engineering skills weren't good enuf to con someone @ microsoft that i "lost' mine.
April 21st, 2003, 06:50 PM
Real quick, as I'm getting ready to rush off to class.
You should be able to initialize the menu items by adding those properties in the .rc file. If you're using the resource editor in VC++6, then you should see those properties in that menu item's property sheet.
The Windows messages associated with this is given as WM_UPDATE_COMMAND_UI which should come through when the program is idle. I'm not completely sure what that implies; i.e., whether this is being prevented by waiting in the recvfrom call. Also, somewhere I saw something about a WM_SYSCOMMAND message being involved, but I'm not sure. I would think that adding WM_UPDATE_COMMAND_UI to the WndProc's switch statement should work, but then it's been a very long time since I've worked at that level.
April 22nd, 2003, 12:55 PM
well i got everything working now, you can play multiple games in a row w/o resetting server, greyed menus, and even a multi threaded client. but the threading has brought something to my attention. i created a thread that would call the recieve function for my appClass. this thread is called in my WM_COMMAND and a few other spots. i use:
Create Thread; Wait forSingle(thread)
I was thinking about this, and in effect isnt teh whole purpose of multithreading nullified in Win32? Wait on Single holds up the command loop waiting on the recieve thread! So even tho it no longer crashes when the user clicks, it still seems to me as tho it is a single threaded program b/c u can't enter any more WM_Whatever's until the thread finishes!
April 22nd, 2003, 03:16 PM
It would indeed be ironic if Win32 had made multithreading obsolete, since we didn't even have multithreading in Windows until Win32 (OS/2 did have it, but not Win16). If you've been preached to about writing well-behaved Windows apps, the cooperative multitasking of Win16 is the reason -- if you didn't write short fast message handlers, then your app would hog up the computer and not let anything else run. Win32 not only brought us preemptive multitasking, but also multithreading.
So far I've only played a bit with multithreading console apps. But my understanding is that the main thread (the one that's always running, including in a single-thread app) does all the message handling and UI stuff while the worker thread(s) handle the stuff behind the scenes, the engine if you would. The idea in your case being that the worker thread would handle the sockets I/O in the background and keep the main thread free to handle the user interface and Windows messages. Conceptually, my approach would be for the worker thread to place the received data into a buffer which the main thread would then check periodically, or the worker could set a flag to indicate that data is ready to be processed. Or, the worker could do the processing itself, somewhat independently of the main thread.
Somewhere I have a book on Win16 sockets programming. You used to have to do all kinds of message and notification handling. It's a lot cleaner and easier now.
April 22nd, 2003, 07:55 PM
interesting. i didnt know multithreading was a new concept. i showed my teacher my program today, and apparently there are some special functions/utilities that are to be used with sockets and win32 Windows programming--something to do with asynchronous sockets or something along those lines, he didnt really explain it to me b/c he had to run, but he said he would have a look at my program and get back to me. finally, i am actually being taught something in this class....gogogo professor! all i know is that the way i was doing was indeed a self defeating process! and i must say, i think that my win32 book is a piece of crap, it seems to leave out so many key concepts its very irritating. this Petzold book, is it the "bible" of C++ or something? i have heard u mention it a few times as well as a few others.
April 22nd, 2003, 09:46 PM
I don't know how old the idea of multithreading is, but its implementation is relatively new. We were discussing multitasking in school in 1978 and the university's IBM mainframe used it, but I don't think it used multithreading. It was not a part of DOS and it was not a part of Win16 (Windows v1.0 through 3.11), but was implemented starting with Windows 95 -- I don't know when it became part of NT. UNIX/Linux has it, but only long after UNIX was created (c. 1970); I would guess somewhere between 1980 and 1990. OS/2 had it from the beginning, which was about mid-to-late 1980's.
We just started on the chapter on pthreads last night in my Linux Systems Programming class, so I'm learning more about it now. Then I'll see how gcc handles it under Windows. I'm even tempted to try to fork a process (different subject) just to see if Windows can handle it.
Petzold is/was the Bible of Windows Programming. Charles Petzold almost literally wrote the book on writing Windows programs in C (not C++) with the Software Development Kit (SDK), AKA the "Windows API". Actually, it seems to have been pretty much the same book modified for the new features in the new version of Windows. I first bought it when it was "Programming Windows 3.0" and I have "Programming Windows 95" at the office. I have seen the Windows 2.0 edition and can only assume that there was one for Windows 1.0. I also have his "Programming the OS/2 Presentation Manager" from when we worked with OS/2 -- it's very much like Windows, yet different enough to make it difficult to port an OS/2 program to Windows.
I believe that you are using much the same method that Petzold uses in his books. The first program he presents is the "Hello world", which requires about 100 lines of code. Then what Microsoft did with MFC and Borland with OWL was to encapsulate the message loop and message handling into an application class and create a framework that took care of the details of organizing the application and left us with just writing the message handlers.
You should be able to find Petzold either in the bookstore or in the library or in a used bookstore. I find myself going back to him when I'm maintaining our test applications, which were written in an odd mixture of MFC and SDK.
Last edited by dwise1_aol; April 22nd, 2003 at 09:51 PM.