|
The second parameter for ScrollWindow, yAmount must be a negative value to scroll up.
My idea is to take a member var which stores the previous pos, compare to see the direction and write code accordingly.
HTH,
Murali Krishna
|
|
|
|
|
Hi all, this is my first message. i want to configure system timer for say 1msec exact, how to achive the perfact timing requirement in VC++, i have to transmit some message at every 1msec, at serial port. can anyone suggest how to do this.
|
|
|
|
|
|
Your link is broken.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
shriram_ch wrote: i have to transmit some message at every 1msec, at serial port
I'm almost positive that you can't possibly send discreet messages this fast, especially over a COM port. Your control code will need time to execute, and we're talking at least 3ms just to iterate the loop and send the message.
shriram_ch wrote: i want to configure system timer for say 1msec exact, how to achive the perfact timing requirement in VC++
Since the Sleep() function doesn't have that kind of granularity (depending on the platform, the best you can get out of it is about 25ms), you're going to need a higher-resolution timer.
There are a couple of articles here on CP that talk about high resolution timers.
http://www.codeproject.com/cpp/precisetimer.asp[^]
http://www.codeproject.com/datetime/perftimer.asp[^]
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
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.
|
|
|
|