|
True, these are just the opinions of the reviewers, though often the reviewers are themselves experts in the field and thus are able to point out flaws that less-experienced people might not be able to notice. For example, when a new math paper/theory comes out, it must be peer-reviewed by other experts in the field, and not by random people who just happen to have a casual interest in math.
However, in Schildt's case, it has been documented[1,2] that there are many factually inaccurate and sometimes blatantly wrong statements in his books, and much of the code he presents teaches bad style or dangerous practices. If someone is trying to learn, then he most likely will not be able to distinguish good practice and bad practice, and thus is likely to learn bad habits, which might never be corrected.
So, take the reviews with a grain of salt. If someone is able to gain useful knowledge from a "bad" book, then that's great. However, if a person reads this book and then believes what he is doing is correct when there are much better, safer ways to do the same, wouldn't you like to know about it, and help people to avoid that mistake?
--
Marcus Kwok
|
|
|
|
|
Fair enough. I only read one of his books (dated 198x). I can't remember the exact title, but it was an awesome book filled with all sorts of neat stuff. Sparked my interest greatly.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Cool. While I'm sure that not all of his stuff is bad (and one of the reviewers that rated his book as "not recommended" even commented that Schildt's writing style was very good), the issues that I have pointed out above have made me wary of his books. But, this is my personal opinion. You know what they say about opinions... they're a lot like a**-holes: everyone has one, and they all stink 
--
Marcus Kwok
|
|
|
|
|
Ivor Horton would probably be the best book coming from Turbo C++ 3.0 since his "Beginning Visual C++ 6.0" book covers the language and command line programming in part 1, and Windows programming using MFC in the second half.
It's still in print (or at least it was last I checked 4 weeks ago)
For Win32, Petzold would be a good place to start your migration.
|
|
|
|
|
Please suggest me how to draw curves with smooth edges. I tried Arc, ArcTo, AngleArc etc. They draw curves with jiggs.
Regards
The Best Religion is Science.
Once you understand it, you will know God.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
