|
You probably won't be able to get 1ms regardless of what you use in Windows - it's not a RTOS.
You may want to look at the Waitable Timer API:
http://msdn2.microsoft.com/en-us/library/ms687012.aspx[^]
e.g.
- Create a watiable timer:
HANDLE TimerHnd = CreateWaitableTimer(NULL, FALSE, NULL);
- Create a job thread
- start loop
- WaitForSingleObject(TimerHnd, INFINITE);
- send message on serial port
- continue loop
- Set the waitable timer
SetWaitableTimer(TimerHnd, &due, 1, NULL, NULL, FALSE);
...
- Kill timer: (due = 0)
SetWaitableTimer(TimerHnd, &due, 0, NULL, NULL, FALSE);
CancelWaitableTimer(TimerHnd);
- Tell thread to exit, wait for it to exit
- CloseHandle(TimerHnd);
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Hi,
I am using Winsock(only TCP) and I wondered when a client really connects to a server. With connecting I mean the whole process of establishing a TCP connection (that means Handshake, and so on). Is this done via the connect(...) function or is it every time done when the client sends data to the server by the send(...) function?
The background of my question is, that I have a client app and I make a call to the connect() function when I initialize the client app. Now the user can choose between different actions, which asks the server for some data. That means, that there is only data send when the user chooses one of this actions; actually he can do nothing all the time. Is the way I do it okay, or would it be better to connect only to the server when the user chooses a specific action and then disconnect again (doing this then for every action)?
|
|
|
|
|
With the TCP protocol, the connection is made once - during the connect() call.
You could connect for every transaction or keep a connection open. Whatever suits your needs
best.
Connecting every transaction adds the slight overhead (bandwidt/CPU) of establishing/closing the
connection. Web browsers do alot of that 
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Hmm yes I thought of something like this...
But this yields in my next question: How can I disconnect from a server? I think there doesn't exist a command like disconnect(). So how is the best way to do this?
|
|
|
|
|
FreeCastle wrote: I think there doesn't exist a command like disconnect()
They hide that information in the documentation[^] 
led mike
|
|
|
|
|
Yes I know closesocket(), but I thought that there might be a better way, because when I call closesocket() then I also have to create the socket again, before calling the connect function.
But anyway thank you both.
|
|
|
|
|
You're welcome (from led mike)
FreeCastle wrote: because when I call closesocket() then I also have to create the socket again, before calling the connect function.
That is part of the overhead of using that method.
I recommend:
Also follow led mike's link into Graceful Shutdown, Linger Options, and Socket Closure[^] for more general info.
Then check out DisconnectEx[^] for disconnecting a socket and reusing it (on XP+).
Cheers,
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Ah thank you a lot, the first link was very informative.
That DisconnectEx function looks cute, but I think I'll avoid it because it only runs on XP or higher. I think I use shutdown, and if I understood that article right, I have also to "create" the socket (by a call to socket(...)) again, when I want to "reuse" it for a new connection.
|
|
|
|
|
i have to implement the fft algorithm for comparing the image obtained from webcam with some standard image stored..
can you please help me with this...
|
|
|
|
|
try typing 'FFT' in the search box at the top of the page . there are a few articles here about FFT.
|
|
|
|
|
Hi,
How do I prevent the escape key, when pressed, from closing a dialog window?
Thanks
neil
|
|
|
|
|
By default the ESC key causes a WM_COMMAND IDCANCEL message to be sent to the dialog proc.
You could catch this message and do nothing. *EDIT* dumb answer
Maybe look for WM_KEYDOWN/WM_KEYUP messages for the ESC key and do nothing in response.
Mark
-- modified at 14:42 Thursday 22nd February, 2007
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: By default the ESC key causes a WM_COMMAND IDCANCEL
No, it doesn't.
Mark Salsbery wrote: Maybe look for WM_KEYDOWN/WM_KEYUP messages for the ESC key and do nothing in response.
What about not dispatching the message if its due to escape key pressed ? (Handling PreTranslateMessage).
|
|
|
|
|
prasad_som wrote: No, it doesn't.
I guess I was confused by the documented handling of the ESC key which states "Sends a WM_COMMAND
message to the dialog box procedure. The wParam parameter is set to IDCANCEL."
prasad_som wrote: What about not dispatching the message if its due to escape key pressed ?
Which is what I meant by do nothing.
Sorry I don't do English as good as y'all.
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: Which is what I meant by do nothing.
You talked about handling WM_KEYDOWN message. But Instaead PreTranslateMessage would be better place, I wanted to underscore that.
Mark Salsbery wrote: I don't do English as good as y'all.
No, You does, . English is not our native language.
|
|
|
|
|
prasad_som wrote: ou talked about handling WM_KEYDOWN message. But Instaead PreTranslateMessage would be better place,
You may also want to tell him clearly that WM_KEYDOWN won't help at all, with these two keys.
He is no fool who gives what he cannot keep to gain what he cannot lose.
- Jim Elliot
|
|
|
|
|
prasad_som wrote: But Instaead PreTranslateMessage would be better place, I wanted to underscore that.
I agree. The OP didn't mention MFC. I guess it's a 50-50 shot. I try not to assume
Cheers!
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: Maybe look for WM_KEYDOWN/WM_KEYUP messages for the ESC key and do nothing in response.
I don't think so. When the user presses the Esc or Enter, CDialog implementations will call EndDialog() immediately rather than passing on this message to WM_KEYDOWN handler. So the handler floats sadly in thin air. There is a lot of confusion on this and I do not find a better way than overriding the PreTranslateMessage</s>
Please read This[^] too!
Last modified: 17mins after originally posted --
The greater the difficulty, the greater the glory.
- Marcus Tullius Cicero
|
|
|
|
|
LOL I get it! The OP did not mention MFC - you all assumed that - you got it right...good for
you.
Most times that I assume that, the OP comes back and tells me "I'm not using MFC". I can't win.
I suggested eating the ESC key, exactly what Prasad did in his PreTranslateMsg handler.
You are right it won't work in an MFC OnKeyDown handler - the key has been translated at that
point so an escape key never gets there. That's why in MFC it needs to be caught in
PreTranslateMsg.
In non MFC you'd have to look for the WM_KEYDOWN and not pass it on to be translated.
Either way you're eating the keystroke
Cheers!
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
You can catch pressed key
if (key==VK_ESC)
flag=true;
and in OnClosing method you can check the flag if it's true, you can forbid closing the dialog. Or after handling VK_ESC key pressed you can change it into some other key so that program would think the ESC wasn't pressed.
|
|
|
|
|
I suppose you are using MFC ? If yes, look at the FAQ here[^]
|
|
|
|
|
NeilDevlin wrote: How do I prevent the escape key, when pressed, from closing a dialog window?
handle onCancel virtual function of CDialog Class
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote: handle onCancel virtual function of CDialog Class
If you do this, then clicking the cancel button or the close button (the X button) also won't close the dialog. Am I right?
The greater the difficulty, the greater the glory.
- Marcus Tullius Cicero
|
|
|
|
|
brahmma wrote: Am I right?
as usual you are right
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Thanks I always have wondered why there are no other good ways than handling the PreTranslateMessage to sort this 'It closes if I press the Esc button' issue out. I find handling PreTranslateMessage to be a weird way but that is the only effective way I know to do this.
Last modified: 2hrs 7mins after originally posted --
Glory follows virtue as if it were its shadow.
- Marcus Tullius Cicero
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
