|
No I can't.
I get an empty file, nothing more.
|
|
|
|
|
For verification, first you check whether the file is existing or not. If existing make sure that the file does not have the read-only attributes (or system attribute).
- NS -
|
|
|
|
|
Are you using Vista?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi everybody! I have a question.
If there are two mouses(A,B) pluged in a computer, I wonder how to distinguish A from B.
plz help me 
|
|
|
|
|
Are you able to use two mice at a same time???
Sreedhar DV
[Real success is having courage to meet failure without being defeated.]
|
|
|
|
|
To answer your question Sreedhar, yes, case in point laptops which come with a stupid touchpad which remains active when I plugin a respectable USB mouse.
To answer Charles, the only way you can do this is to use the Raw Input Model. Handle the WM_INPUT message, process the RAWINPUT structure pointed to by lParam, it contains a RAWINPUTHEADER structure which contains a hDevice that you can pass to GetRawInputDeviceInfo. NOTE: raw input is available only when the application calls RegisterRawInputDevices with valid device specifications.
|
|
|
|
|
Howdy guys,
I joined the forums several days after spending several more days exploring through all the wonderful articles posted here. I had started to teach myself c++ just about 2 months ago. Things go well at times and things go slow, I am sure you can relate to how it was starting how in the programming world.
Right now I have been trying to teach myself how to get a simple connection between two computers. My original plan was to build a basic chat client that acts as a server/client for a peer to peer type of connection. After some problems I have decided to make a very simple console server that listens on a port and prints a string that it receives.
My server listens in a port and it appears I can even make my client have an "ESTABLISHED" connection with my server. However when I send() and recv() data, nothing happends. Or it locks up.
I am concerned that I am not using the right sockets for the right job. What I guess I want is a very general clarification of what each socket will do. I have read through 4 different tutorials here and most have been extremely helpful, however due to my own incompitance I keep getting it wrong!
Right now the way I understand it.
The serverside will have two sockets.
a ListeningSocket
a ClientSocket
WIth the listeningsocket I create the socket.
ListeningSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
Bind the socket to a port and address
addr.sin_addr.s_addr = can be "INADDR_ANY" because its the server and is not targeted to connect at anything,
I bind port 8888, set the IP family type then run the BIND command
bind( ListeningSocket, (const sockaddr *)&addr, sizeof( SOCKADDR_IN ) );
using my SOCKADDR_IN struct to pass information to bind and what not
Then I listen
listen(ListeningSocket,10);
Now here I get somewhat confused
What socket does the accepting?
Right now I have setup the ClientSocket to accept the ListeningSocket
ClientSocket = accept(ListeningSocket, (sockaddr*)&addr, &len);
Is this backwards? Should I have it the otherway around with the ListeningSocket as the lhand value and accept ClientSocket? Many tutorials are pretty vague on this.
Then on the actual client side, I simply create one socket and attempt to connect to the server.
What I have now has appeared to give me a connection according to NETSTAT, however when I send() data nothing happends.
Perhaps my recv loop is setup incorrectly.
Any one have any advice? I hope my question was not to entirely vague, or another good tutorial I could follow along through. The more basic the tutorial the better!
Any help is truely appreciated!
Cliff
|
|
|
|
|
Make sure you get in the habit of checking return codes from the socket APIs.
For basic blocking sockets, your server should work ok.
accept() will block until a connection is available so if your app is a GUI app
your UI will stop responding unless the accept() call is not on the UI thread.
accept() returns a new socket, connected to the client. That's the socket you
should be receiving on. The listening socket returns to a listening state.
Make sure you set ports in the SOCKADDR_IN structs using network byte order.
What does your send code look like?
What does your "recv loop" code look like?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark I went through and rearranged all my code to output the WSAGetLastError() msg so I could then look it up. I rebuilt two programs, just simple console programs in this manner, one acting as a server, other a client.
I sent a simple char array "Hello" and vuala it worked! The error codes were a great idea, I suppose in programming I should be more responsible and use those codes! I found out one of my sockets were not being built correctly, my client socket on the server side because of the error. Once I figured it out I fired up my server and sent a message with my client. Boom it showed up on the server end. I'm so happy it works! I can finally see how it all functions now. The server side waits after the connection has been accepted to receive data.
I was afraid I would have to drop recv() in some kind of infinite loop in order to catch incoming data but I guess not! It waits untill data is received or the connection is terminated before processing any code below it! Now that I got that outa the way I can fix the code in my windows based client/server and go from there!
Thanks for the help Mark!
Cliff
|
|
|
|
|
Beaon wrote: I was afraid I would have to drop recv() in some kind of infinite loop in order to catch incoming data but I guess not!
Hi Cliff,
Note that there's a common beginner mistake with sockets when using send() and recv()
on a stream socket (like TCP).
recv() won't necessarily receive all the bytes you request. Even if a thousand bytes are
sent, only one byte could be received in a single recv() call but the call is considered successful.
That means you still have to loop calling recv() until you get the number of bytes you are expecting
or until an error occurs or the other end disconnects.
Another important reason for checking the return values 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks.
So does that entitle having my cient send() send the amount of bytes as a primary transmission? That way the receiving end knows that it should expect X number of bytes before finishing?
Thanks again for the help Mark it goes a long ways!
|
|
|
|
|
That's up to you. You're responsible for keeping track of that so both
ends stay synchronized.
How you handle it defines your protocol.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark I hate to drag it on but I got to thinking. Why wouldnt TCP ensure a reliable delivery? I understand why UDP wouldnt but TCP has me a bit stumped. I just assumed it could be considered a reliable protocl.
It was my assumption that after TCP established a connection, through the method of acknowledgement replys from the receiver and the use of sequence numbers inherit to TCP that this wouldnt be a problem. I guess I got a little confused on this. Any clarification?
Also one final question! I have created a very basic wrapper class for my little console program but now I want to incorporate it into my chat GUI. I read somewhere that by turning one of the server's sockets to a WSAasyncsock or something of that nature that I could incorporate the recv into my windows message pump. The tutorial made it clear on how and where to setup my messags but was unclear as to which socket I need to make an windows based asyncronous socket, also won't the sender side have to send those windows messages as well? Otherwise at what point does my message pump just automatically know that data is coming in?
Did I make any sense there at all? =)
Mark your an excellent help! After this I promise I won't pester you any more!
Cliff
|
|
|
|
|
TCP is indeed reliable. The thing is, it's a stream oriented protocol, so it
only understands bytes. You could send 32KB-sized "packets" but the
underlying protocol may split that however it needs to for delivery. TCP
guarantees you'll receive all the bytes sent, in order, but they won't necessarily
come in one recv() call. That's why you need to do whatever it takes so the send
and receive ends stay in sync. It's essentially a protocol on top of TCP.
Make sense?
For the UI, yes, an asynchronous socket is ideal. Event-driven socket communication
is very efficient.
On the server side, you use the socket returned by accept(). That's the socket
connected to the client.
On the client side, you already have the socket - the one you connected to the server with.
I recommend reading the docs for WSAAsyncSelect VERY carefully.
The easiest way to get started is to request notifications for FD_READ and FD_CLOSE.
Then your window will receive the message you specify whenever there's data to be "recv()"'d
from the socket, and when the connection is closed.
On any given FD_READ notification, you can read as many bytes as you need to. If all the bytes
you're expecting aren't there yet, you need to keep track of that for when you get the next FD_READ.
If more bytes than you recv() are available, you're guaranteed to get another notification.
Again....read the docs carefully 
Beaon wrote: also won't the sender side have to send those windows messages as well?
No. Both ends of the connection handle everything themselves. Basically, just
sending and receiving bytes. The notifications are available so you don't have to
sit in a loop wasting CPU cycles waiting for data.
Once a connection is established, there's no difference between the client and the server ends.
You could actually use identical code on both ends.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Your awesome buddy. Thanks alot, time to go play in some code! =)
|
|
|
|
|
Alrighty sir, I swear I wouldnt be asking if I could find the answer somewhere in a tutorial but so far no luck.
Everywhere I read says that in order to make these sockets compatible with my GUI I need to have an async socket.
I understand that, my problem is where exactly do I put the WSAAsyncSelect command?
I have tried both places.
Create Listenign Socket
Bind Listening SOcket
Listen Listening SOcket
Create Client Socket
WSAAsyncSelect(Client Socket) //Ive tried it here
Client SOcket = accept (Listening Socket)
//WSAAsyncSelect(Client Socket) //And I have tried it here.
If I try it higher up before I make the accept call, that place seems the most logical to me because it is the accept call that locks up the gui right? However when I do it the GUI locks up. If I telnet to my port, or use my little console program I made and connect to that port the GUI unfreezes and a connection is established as normal. If I try to send data nothing is received on my GUI end.
If I place the WSAAsyncSelect after the Accept command same thing. Client GUI hangs untill a connection is established. Once its established everything works however, I can even send text messages from my console program and it will output correctly on my GUI's interface.
I am guessing that I am assigning the correct socket into async mode and my windows messages are working and everything, but why would it still be locking up waiting for a connect? Perhaps I am missing something still!
I spent the last hour poken around MSDN libs and other sites and havnt been able to get a simple and descent example. Thanks again Mark, especially for your patience!
Cliff
|
|
|
|
|
Hi Cliff,
I forgot to mention....
The listening socket is separate. Once it is placed in a listening state, that's
all it does. For that socket, you'd want to use the FD_ACCEPT flag to get a window message
when a client tries to connect.
The WSAAsyncSelect() calls can be made any time after the sockets are created.
Generally, it's done something like this....
For the listening socket, call WSAAsyncSelect(...FD_ACCEPT) after you call listen(), then
return to your GUI or whatever. When you get a message indicating FD_ACcept to your
window, THEN call accept().
For the client end of the connection, call WSAAsyncSelect(...FD_CONNECT) right after you
create the socket. Then set the socket to non-blocking mode using ioctlsocket(), something like:
DWORD dwNonBlockingMode = 1;
::ioctlsocket(hSocket, FIONBIO, &dwNonBlockingMode);
Call connect() on the socket and return to the GUI - your window will receive the message when
connection is complete. When you receive the connect completion message, call
WSAAsyncSelect(...FD_READ|FD_CLOSE) on the socket to start receive and close notifications.
For the server end of the connection, when you receive an accept notification,
call accept() to create the connection socket.
Set this socket to non-blocking mode using ioctlsocket() as shown above,
then call WSAAsyncSelect(...FD_READ|FD_CLOSE) to start receive and close
notifications.
Make sense?
Mark
*EDIT* I crossed out the parts about setting the sockets to non-blocking.
Calling WSAAsyncSelct() does this for you
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It sure does. Thanks again! I got today off so as soon as I get home I will be working on this!
Thanks for everything! =)
|
|
|
|
|
Hey check this out, It works!
Mark your the man!
Thanks for all the help buddy!
I'm so excited. Now I am going to learn how to make my app look prettier then the default windows stuff.
Lots of learning to do!!! =)
Cliff
Cliff
|
|
|
|
|
Kewl! No problemo.
Have fun,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
I am trying to display non-english text on the std console. I have tried various methods like
setconsole, _wsetconsole etc.. Defined _UNICODE and UNICODE macros also used wstring, wcout thinking that wide char variant might print the non-english text. Below is my sample program
#include <iosstream>
#include <locale>
using namespace std;
int_tmain()
{
wstring nonEnglishName = _TEXT("槧雲鼻");
wcout.imbue(locale("jpn");
wcout << _TEXT("Name in japanese is = ") << nonEnglishName.c_str() << endl;
return 0;
}
The output I am getting is = Name in japanese is = ₧▀ë_ò@
My system locate is still set to US_ENGLSH and I do not want to change it.
Can anybody please guide me regarding the correct procedure for displaying non-english text on the console?
Thanks
-- modified at 13:46 Wednesday 12th September, 2007
|
|
|
|
|
Check out the SetConsoleCP and GetConsoleCP API functions.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I have a application that does some computations based on inputs from user, prints the results of the calcutaions in a file and exits. I am using ExitProcess() for exiting from the application. But while closing the application I get a error "The instruction at "0x73e6827a" referenced at "0x00157479c". The memory could not be read" .
When I use TerminateProcess() I dont get the error message eventhough TerminateProcess() is not a recommeneded method for exiting process. Why does this happen?
|
|
|
|
|
What happens if you send WM_CLOSE to that program?
|
|
|
|
|
Is it a console app or a GUI app?
You shouldn't have to call ExitProcess and definitely shouldn't have to use TerminateProcess.
Some info: Terminating a Process[^]
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
