char problem

This is a discussion on char problem within the Windows Programming forums, part of the Platform Specific Boards category; Originally Posted by eXistenZ i totally agree but im a n00b in c++ to be honest and all i see ...

  1. #31
    I am me, who else?
    Join Date
    Oct 2002
    Posts
    250
    Quote Originally Posted by eXistenZ
    i totally agree but im a n00b in c++ to be honest and all i see there for adding text is SetWindowText() and this replaces all the text when calling it then adds the new text right ? and about that SetSel you said i have no idea how to use it and also have no idea how to format the text color, font etc..

    and as for the casyncsocket problem using a character to know the begining and the end of the message isnt such a good idea because some other guys could connect with a telnet client and send any data and this will probably cause errors + i will have to disable that character in my application and this isnt such a good thing either.. cant i use something else to know that begining and the end ?
    thanks

    Well to address the casyncsocket problem, if other people are connecting you will need to create a socket for them to use in any event, you can use that to separate out all the text. You can implement a buffer to count how much someone has sent, and simply dump after x number of bytes has been sent, that is a poor solution I agree, but something to be thought of. But the character to know the end of a sentence is a good idea unless you want to get unnecessarily(for this program) complicated. Each socket can communicate with the server, but even at that it might be better to have a buffer setup so there isn't total chaos in the chat room. Really this is probably the best and easiest way to go, live chat is hard(er) unless its between 2 people only.
    What I mean by "live chat" is that the text appears on the screen as you type.

  2. #32
    Registered User
    Join Date
    Dec 2004
    Posts
    103
    lol thats the real problem anyway there is no real way to tell if other people are using my application or their own and they can send anything, acctually that character to find out the end of the message is quite a very good idea but if the user doesnt send it then the buffer will probably never get cleared until that character is being sent well i guess that can be fixed thru some checkings what i realise now is that i have to create a serverbuffer for every client connected to it :P i dunno i really do have a data limit for every client but the problem comes when there is lagg and the client may send a message which reached the limit + some other message with that limit reached too.. and them together will be over the server buffer limit and that will cause the second message to get lost.. lol i really never thought that things could get so complicated over an easy thing

  3. #33
    Registered User
    Join Date
    Dec 2004
    Posts
    103
    after long searching i finally found the function that gets the data size of the main casyncsocket buffer atleast i think so
    Code:
    if(nErrorCode==0)
        {
            DWORD rcv;
            CString Data;
            wsClient.IOCtl(FIONREAD,&rcv);
            char *dta=new char[rcv-1];
            wsClient.Receive(dta,rcv,0);
            dta[rcv]='\0';
            Data=dta;
            delete[]dta;
            CString txt;
            m_re1.GetWindowText(txt);
            m_re1.SetWindowText(txt+CString("\n")+Data);
        }
    FIONREAD Determines the maximum number of bytes that can be read with one Receive call from this socket. The lpArgument parameter points at a DWORD in which IOCtl stores the result. If this socket is of type SOCK_STREAM, FIONREAD returns the total amount of data which can be read in a single Receive; this is normally the same as the total amount of data queued on the socket. If this socket is of type SOCK_DGRAM, FIONREAD returns the size of the first datagram queued on the socket.

    i guess thats what i need right ?

    btw how do i messagebox a dword value so i can see if that function really works for sure
    Last edited by eXistenZ; 02-17-2005 at 06:38 AM.

  4. #34
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,853
    >>If this socket is of type SOCK_STREAM, FIONREAD returns the total amount of data which can be read in a single Receive;

    the max amount that can be read in one recv is the size of the sockets recv buffer. This amount can be changed with SetSockOpt() as I stated.

    This will not solve your problem as you can NOT be sure all data will be recv'ed in one read even if sent in one write.


    >>do i messagebox a dword value so i can see if that function really works for sure

    CString Format(). Look at sprintf() and follow to 'type specifiers'.

    "printf Type Field Characters" in MSDN's Run-Time Library Reference.

    a DWORD is a 32 bit unsigned int (try %u)
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  5. #35
    Registered User
    Join Date
    Dec 2004
    Posts
    103
    Quote Originally Posted by novacain
    This will not solve your problem as you can NOT be sure all data will be recv'ed in one read even if sent in one write.
    why not ? this is exactly what i needed i made some tests and it works perfectly the ammount of memory declared in the buffer is the same as the casyncsocket buffer size, since its in the queue in the buffer it should be received all with no problem
    If this socket is of type SOCK_STREAM, FIONREAD returns the total amount of data which can be read in a single Receive; this is normally the same as the total amount of data queued on the socket.
    oh btw i got that code working, showing a dword value and i gotta tell you that i saw the exact number of the chars that were received in the chat
    thanks for replying
    Last edited by eXistenZ; 02-19-2005 at 01:25 AM.

  6. #36
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,853
    NOTE: You probably won't see this with a chat app as the data sent is small. It could happen, especially if an error (ie lost packet) occurs. If you app does not handle it then the results are usually terminal.



    After you write to the socket TCP/IP takes over. It breaks the data up into packets, adds error checking and sends the data.

    On your client end the data is re-assembled, any damaged or lost packets are re-requested.

    At this point the socket does not 'wait' until the message you 'sent' arrives, any amount of data can be recv'ed.

    The message could arrive in multiple recv's or multiple msg's could arrive togather (one after another, all in one recv) .

    Try getting your server to send data close to the recv buffer size multiple times and see if an error occurs.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  7. #37
    Registered User
    Join Date
    Dec 2004
    Posts
    103
    ill see if i get any error, thx

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need help understanding info in a header file
    By hicpics in forum C Programming
    Replies: 8
    Last Post: 12-02-2005, 11:36 AM
  2. char problem
    By ForlornOdium in forum C++ Programming
    Replies: 10
    Last Post: 10-29-2003, 01:39 PM
  3. simulate Grep command in Unix using C
    By laxmi in forum C Programming
    Replies: 6
    Last Post: 05-10-2002, 04:10 PM
  4. String Processing Problem
    By muffin in forum C Programming
    Replies: 0
    Last Post: 08-24-2001, 10:13 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21