Who said that was put there for pity? That is really in there so that people DON'T talk down to me and like I am an idiot. I don't believe your comment was necessary, considering that it has nothing to do with pity. Thank you for your help though. I appreciate it. Jimmy Just cause I am 15, doesn't mean I'm dumb! (I'll really be 4 on Feb. 29...the year 2004)

With UDP sockets you have to call ReceiveFrom instead of Receive. Thats why it works with TCP. Bunburry

The error WSAWOULDBLOCK not indicate that all was right. This code is returned because you are using non-blocking sockets and the operation can't be completed(you have a pending connect). After it, you have to use select api (unless you are using WSAAsyncSelect or WSAEventSelect) to check when the operation is completed. When this occur(after connection timeout), then check the error code of the operation and you will see that the connection can't be established.

and, (haven't used Format or printf for a while...) you can specify the field width as an argument itself, like this; testStr.Format("%0*X", n, myString) where n is the number of digits you want. Steve S

oops...sorry about that yes, both myString and myString2 are numbers that needs to be displayed as hex Jimmy Just cause I am 15, doesn't mean I'm dumb! (I'll really be 4 on Feb. 29...the year 2004)

Why would I be offended? It's not my forum. Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

You can get at the string in the edit box with CString FileName; MyEditCOntrol.GetWindowText(&FileName); You can then perform all of the validation on FileName. To verify the edit box wasn't blank: if(!FileName.Getlength()) //handle error here - zero length filename To verify that no illegal filename characters were entered: CString InvalidFilenameChars = ""; // put all invalid filename chars in this string if(FileName.FindOneOf(InvalidFilenameChars) != -1) //handle error here - filename contains invalid character There may be a pre-built MFC way of handling all of this.........

try: int * myArray = new int[size]; remember to call: delete [] myArray; when you've finished with it. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky

You can uncheck the System Menu option to remove the Maximize, Minimize, and close buttons. But if you want to have Max/Min buttons, then what you can probably do is to grey out the close button. For that you, just add this to the end of your InitDialog( ) VERIFY( pSysMenu->DeleteMenu( SC_CLOSE, MF_BYCOMMAND ) ); CFileDialog doesn't have any options like that. You will have implement it in your own way. "A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."

There are several ways. Here are a few. The example below will display the binary representation for the decimal 100. In addition to '#including' <bitset>, you'll also have to '#include' <limits> cout<<"\n 100: " <::bitset(85) <('A') < Ltrs = bitset<numeric_limits<unsigned int>::digits>('ABCD'); cout<<"\n \"ABCD\": " <

AND means that BOTH bits must be 1 in order for the resulting bit to be 1. 10100000000100101011010000110101 AND 1111 101 Continuing to bit-shift the value to the right one word at a time means that you can use 0x0000000f exclusively. You could also have had something like: DWORD dw = 0xA012B435; WORD w1 = dw & 0x0000000f; WORD w2 = (dw & 0x000000f0) >> 8; WORD w3 = (dw & 0x00000f00) >> 16; WORD w4 = (dw & 000000f000) >> 24; or WORD w4 = dw & 000000f000; w4 >>= 24; Whether you bit-shift before or after the AND operation is not important, but doing so beforehand does lend itself to more readable code. Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

Well, during the creation you just pass the SOCKET_DGRAM instead of SOCKET_STREAM. Then you might 'bind' it to the local port (selecting the client side port number - unusual in tcp). If you don't do it it will choose the port automatically as in tcp, but most udp protocol expects also known client port, so usually you have to do it. Then the usage is slightly different - on write side whatever you write it will send a packet immediatelly (no nagle alg. as in tcp) therefore if you write every byte separately, there will be separate packet for every byte (thus big overhead). You also have to specify the destination address - this is in tcp taken from the 'connect', but there's no connect, because it's connectionless socket ;). Reading part - here you can use the recvfrom or WSARecvFrom functions which returns also the address from where the datagram was sent and you can process it. That's the difference between udp and tcp - in udp you can communicate with several computers using one socket. Therefore you have to specify the address in write and receive it in read. Another issue with udp is that it's not reliable - it's only best effort service, so during design of the protocol you have to think about the fact, that the packets (data) can be lost - this is normally controlled by tcp and in that case the data are resend, but it's not valid in udp, here it's up to you. That's just brief description of udp-tcp differences. I hope it's not too much confusing ;-)

I assume you know how to connect and send data to the server 1 number at at time. Convert the user delay value into milliseconds. Then before your Send() function call Sleep(userTime). Here is a link that talks about the accuracy of sleep: http://www.codeproject.com/system/sleepstudy.asp[^] I hope this answer is not too simplistic. I get the idea you want more but I am not sure what. John

Search for the text "PreTranslateMessage" on this page: http://www.widgetware.com/faqsub.htm[^] and use the VK_ENTER code. /ravi Let's put "civil" back in "civilization" Home | Articles | Freeware | Music ravib@ravib.com

The MSDN Scribble example goes a long way in showing the many facets of an MFC application. I suggest you study it in detail.

The CFileDialog does not create the file, nor does it open it. All the dialog does is give you a standard interface for choosing a file. You have to create the file afterwards. First you construct the dialog. When you call DoModal(), the dialog appears. When the user clicks open, the dialog returns IDOK. At this point your code can access the path to the file selected by the user using the GetPathName() member function. CFileDialog InputDlg(TRUE, "*.txt", "Message.txt", NULL, "Text Files (*.txt)|*.txt", NULL); if(IDOK==InputDlg.DoModal()){ CString filename = InputDlg.GetPathName(); //create the file here } I suggest you have a look at the documentation for CFileDialog on the MSDN. It will tell you about some other member functions you can use and also about a little error with the file filter you had in the constructor. Lorenz Prem Microsoft Corporation

Hello, the following should work: In the dialog class add the following: private: VarType m_Var; public: VarType GetVar() {return m_Var;} In the other classes at a point where you want to use the var add // can only appear in functions and constructors VarType var = YourClass.GetVar(); this should do the trick! Good luck! :) A student knows little about a lot. A professor knows a lot about little. I know everything about nothing.

The only actual "numbers" in the computer are semi-conductor gates that are either on or off. That is fine for the computer, but most people need something visual to help us understand what is going on. To the computer, all numbering base sytems look the same - binary. It is only when outputting the graphical representation of those numbers that you need to worry about data types and base. So, the number 255 is represented in the coputer by 8 logic gates being on: 11111111 If you, the human, wants to see that number in hexadecimal, then you tell your program to format that number in base 16 and you see "FF". Now, the characters "FF" are represented by the ascii code for the letter 'F' - which is 70 or x40 - so if you looked at the raw bits for the characters "FF" you would see 70 70 or the bits 01000110, 01000110. So what happened??? You started with 11111111 and ended up with 01000110, 01000110! The confusion comes from figuring out what format the reciever of the data is expecting. That is what function headers are for. They define how to interperet the bits that are being sent.

Suppose you have the following: class ClassB { public: void ActionB(); }; class ClassA { public: ClassB* m_pB; void ActionA(); }; Then you can access ClassB from ClassA using the following: ClassA a; //create an instance of each ClassB b; a.ActionA(); //call methods from A directly a.m_pB = &b; //pass a pointer to the instance of B to A a.m_pB->ActionB(); //call B through A using the stored pointer This is just one of many ways of doing this. The situation dictates what you actually implement. You need to learn about objects, instances, pointers, call by value, call by reference and lots of other concepts. I suggest you get yourself a good C++ book. Lorenz Prem Microsoft Corporation