|
What you are looking for is to Antialias the drawing. There are some articles on CodeProject about that.
|
|
|
|
|
GDI+ does wonders with antialiased drawing and it mixes well with existing MFC view based or just plain GDI code.
It's a bit slow(er) and has a different "feel" than MFC wrapper classes but once you get comfortable with mixing it into existing code, it eliminates the need to deal with other graphics libraries for the most common imaging and drawing operations.
Not to mention that the text output in the antialiased non-grid fit mode is so well behaved, that WYSIWYG output is possible using standard MM_ISOTROPIC mapping modes with no additional effort. You can choose to use GDI or GDI+ coordinate translation schemes depending on whether you like matrices or the traditional approach.
The .dll is already available on XP systems and there is a redistributable for earlier Windows NT/2000 based versions if you need.
|
|
|
|
|
i am working with windows xp, ndis5.1, visual c++.
i want to ask about the object identifier OID_802_11_RSSI.
i read its documentation in msdn. i test it in one of my applications. i know that it returns the signal strength . but how could i know to which ap this measured rssi belongs ?
if i have a dedicated ap that i want to measure its rssi ,can i do this using this oid ? how?
i noted that the this OID readings differs from the rssi readings of OID_802_11_BSSID_LIST. Why?
also when i test this OID in a compaq laptob with Intel(R) PRO/Wireless 3945ABG card it does not return rssi values .Why?
need help. thank you in advance.
|
|
|
|
|
I would like to "gracefully" terminate a process.
If I call TerminateProcess, the process is just yanked, and gets no notifications whatsoever, i.e. handlers in the process code attached with SetConsoleCtrlHandler() do not appear to get called. So is there a standard way to close the process (a command line process, not a GUI program), assuming I have a process handle? My gut reaction, based on searching around, is that there isn't and I'll have to dream something up (ick  ).
|
|
|
|
|
what about sending it a "gentle" WM_CLOSE first ?
|
|
|
|
|
Can't, as I mentioned it's not a GUI program, thus there's no HWND to send anything to, unless SendMessage() has started to accept process handles as a substitute for HWND's! 
|
|
|
|
|
You could try the PostThreadMessage function, although I don't know for sure if it allows interprocess communication.
You could also try a global event, see the CreateEvent() function in MSDN.
|
|
|
|
|
Jeroen Walter wrote: You could try the PostThreadMessage function, although I don't know for sure if it allows interprocess communication.
the console program doesn't have the MessageLoop associated with that.. so there no way they going to handle the window Message
"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
|
|
|
|
|
Mmmm, in that case, if they don't have the source code of the console program, the global event I suggested won't work either.
|
|
|
|
|
If you are looking at something similar to Unix signals, there is no such things on Windows. Basically, I think you'll just need to make the process listening, or even polling to a notification from the external one, and then "gracefully" kill itself.
|
|
|
|
|
Actually, there is. Look at the signal function - set a handler that signals some event that the main code periodically checks. I was using it in a console app and it caught CTRL-C just fine.
|
|
|
|
|
Unfortunately there is no way to send the process a signal from another process.
Plus the signal callback doesn't respond to all the various signal types.
|
|
|
|
|
Does GenerateConsoleCtrlEvent() help?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
UNfortunately no, because it (according to the docs) only allows 2 types of events to be sent, CTRL_C_EVENT, or CTRL_BREAK_EVENT.
|
|
|
|
|
According to MSDN (the august 2006 dvd-version, not the online msdn, as that only shows the 2 you mentioned), CTRL_SHUTDOWN_EVENT can also be sent.
So you could just try GenerateConsoleCtrlEvent with the other events too (defined in wincon.h):
#define CTRL_C_EVENT 0
#define CTRL_BREAK_EVENT 1
#define CTRL_CLOSE_EVENT 2
// 3 is reserved!
// 4 is reserved!
#define CTRL_LOGOFF_EVENT 5
#define CTRL_SHUTDOWN_EVENT 6
-- modified at 3:37 Thursday 22nd February, 2007
|
|
|
|
|
Jim Crafton wrote: ...it (according to the docs) only allows 2 types of events to be sent, CTRL_C_EVENT, or CTRL_BREAK_EVENT.
Why won't that work for you? If this console window is one you are creating via CreateProcess(), you could simply send it "exit\r\n" via its stdin handle.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
The process is started (and controlled) by a service, so I don't think I can (or want to) create a console window can I?
|
|
|
|
|
Jim Crafton wrote: ...I don't think I can (or want to) create a console window can I?
Sorry, I read your "command line process" comment to mean a window was present.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am curious about a situation I have run into. I am hacking a program that was originally meant to read/write serially (serial port) into using UDP. I'm trying to preserve as much of the original code as possible for reasons that I won't bother you with here.
The situation is that a ReadCom() function is called with a specific number of bytes that the calling function wants. For example, when the buffer to be read from has 22 bytes in it, the ReadCom() may be called asking for only 16 bytes. Another ReadCom() will be called later asking for the remainder.
When I replace the serial port reads with a recvfrom(), it looks like the entire UDP message is gone after the first read even though I only asked for a partial number of bytes.
I have two people here telling me different things. One says this should not happen - it is a FIFO, another saying that any time a recvfrom call is made, the entire UDP packet is cleared.
Which is it? The behaviour seems to match with it being cleared but I would like to know what you think.
BTW - I have tried using the ioctl with FNIOREAD to see how many bytes are available and it does say that 0 are available on the second read.
|
|
|
|
|
The second person is right on - when dealing with UDP you will get the data you ask for and any remaining data in the datagram/message/packet is lost. That is the way things work with a "unreliable protocol" like UDP.
I would suggest using a larger buffer, copying all available data to that buffer, and you can then look at that buffer for additional data if required.
Note that if the data is serial, you likely want to get it in order. If you send multiple UDP packets, they may arrive out-of-order, or some may not arrive at all. You will want to use TCP sockets if that is going to be a problem.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Thank you very much. I'm working on keeping my own copy of the data now.
I appreciate the help.
|
|
|
|
|
To add to James' excellent reply....this is from the docs:
"If the datagram or message is larger than the buffer specified, the buffer is filled with the
first part of the datagram, and recv generates the error WSAEMSGSIZE. For unreliable protocols
(for example, UDP) the excess data is lost;"
Better to recv the exact datagram size or more to make sure you get the etire datagram 
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: To add to James' excellent reply
'Danka!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: 'Danka!
de nada 
"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."
|
|
|
|
|
hOw can i cOde this Output in C using fOr lOops..
ABCDEFGFEDCBA
ABCDEF FEDCBA
ABCDE EDCBA
ABCD DCBA
ABC CBA
AB BA
A A
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
