Page 2 of 2 First 12
  • Jump to page:
    #16
  1. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    What I was thinking of for having the server ACK a move would be something like the following pseudocode:

    Code:
    loop
        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
            then 
                call recvfrom to listen for next message from server;
            else 
                prompt the user to enter the next move
        end if
    end loop
    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.

    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.
  2. #17
  3. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96
    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 04:12 PM.
  4. #18
  5. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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!)

    Originally posted by infamous41md
    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?
    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.
  6. #19
  7. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96
    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.
  8. #20
  9. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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.
  10. #21
  11. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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:
    EnableMenuItem
    The EnableMenuItem function enables, disables, or grays the specified menu item.

    BOOL EnableMenuItem(
    HMENU hMenu, // handle to menu
    UINT uIDEnableItem, // menu item to enable, disable, or gray
    UINT uEnable // menu item flags
    );

    Parameters
    hMenu
    Handle to the menu.
    uIDEnableItem
    Specifies the menu item to be enabled, disabled, or grayed, as determined by the uEnable parameter. This parameter specifies an item in a menu bar, menu, or submenu.
    uEnable
    Specifies flags that control the interpretation of the uIDEnableItem parameter and indicate whether the menu item is enabled, disabled, or grayed. This parameter must be a combination of either MF_BYCOMMAND or MF_BYPOSITION and MF_ENABLED, MF_DISABLED, or MF_GRAYED. Value Meaning
    MF_BYCOMMAND Indicates that uIDEnableItem gives the identifier of the menu item. If neither the MF_BYCOMMAND nor MF_BYPOSITION flag is specified, the MF_BYCOMMAND flag is the default flag.
    MF_BYPOSITION Indicates that uIDEnableItem gives the zero-based relative position of the menu item.
    MF_DISABLED Indicates that the menu item is disabled, but not grayed, so it cannot be selected.
    MF_ENABLED Indicates that the menu item is enabled and restored from a grayed state so that it can be selected.
    MF_GRAYED Indicates that the menu item is disabled and grayed so that it cannot be selected.


    Return Values
    The return value specifies the previous state of the menu item (it is either MF_DISABLED, MF_ENABLED, or MF_GRAYED). If the menu item does not exist, the return value is 0xFFFFFFFF.

    Remarks
    An application must use the MF_BYPOSITION flag to specify the correct menu handle. If the menu handle to the menu bar is specified, the top-level menu item (an item in the menu bar) is affected. To set the state of an item in a drop-down menu or submenu by position, an application must specify the handle to the drop-down menu or submenu.

    When an application specifies the MF_BYCOMMAND flag, the system checks all items that open submenus in the menu identified by the specified menu handle. Therefore, unless duplicate menu items are present, specifying the menu handle to the menu bar is sufficient.

    The InsertMenu, InsertMenuItem, LoadMenuIndirect, ModifyMenu, and SetMenuItemInfo functions can also set the state (enabled, disabled, or grayed) of a menu item.
    Hope that helps.
  12. #22
  13. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96
    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:
  14. #23
  15. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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.
  16. #24
  17. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96
    any clue as to what im doing wrong? nothing happens, when i try this:

    EnableMenuItem((HMENU)IDR_MENU1, ID_EXIT, MF_GRAYED);

    or

    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.
  18. #25
  19. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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.
  20. #26
  21. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96

    threads....


    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!
  22. #27
  23. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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.
  24. #28
  25. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    96
    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.
  26. #29
  27. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,322
    Rep Power
    2224
    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 08:51 PM.
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo