Can anybody recomend a book or website that provides a help on using the debugger? I'm uneducated in the debug features and I feel this is a big boundry in my programming.
Can anybody recomend a book or website that provides a help on using the debugger? I'm uneducated in the debug features and I feel this is a big boundry in my programming.
"Hence to fight and conquer in all your battles is not supreme excellence;
supreme excellence consists in breaking the enemy's resistance without fighting."
Art of War Sun Tzu
The debugger with .Net is not really worth using. There are many of third party debuggers that are much better. However the simple thing of it is, is to run your program in the debugger after setting a break point and then step through the code and view the results in the output pane. That is the essence of what to do.
While you're breakin' down my back n'
I been rackin' out my brain
It don't matter how we make it
'Cause it always ends the same
You can push it for more mileage
But your flaps r' wearin' thin
And I could sleep on it 'til mornin'
But this nightmare never ends
Don't forget to call my lawyers
With ridiculous demands
An you can take the pity so far
But it's more than I can stand
'Cause this couchtrip's gettin' older
Tell me how long has it been
'Cause 5 years is forever
An you haven't grown up yet
-- You Could Be Mine - Guns N' Roses
I have a book called Using Visual C++. It has one chapter on using the debugger.
My copy is outdated (MSVC++ 5?), and I really didn't get much out of the book, because it uses MFC, and all the wizards to sort-of write your application for you... and I wanted to "get under the hood" and learn the WinAPI. But, there are a few interesting gems that should be in a MSVC++ user manual!
Doug, you might want to consider spending your time with something other than MFC. It looks like you're interested in Windows programming and with the coming of Longhorn, you'll be learning an entirely new API. I wouldn't spend too much time on something which will be out of date in a few years. Maybe consider checking out the .NET framework instead.
Thanks CompiledMonkey, but like I said: "I really didn't get much out of the book, because it uses MFC... and I wanted to... learn the WinAPI."
I do have Petzold's book, and Schildts's similar book. I don't see how the Longhorn API can be THAT much different. If Longhorn doesn't run the existing applications (written with the Win32 API), they aren't going to sell very many copies!!! Win32 is more entrenched than Win16 was when Windows95 was introduced.
Obviously Longhorn will run older applications, but it will be in a managed container I'm sure. The whole idea behind Longhorn is managed code. I've been told by a MS developer that Longhorn will have 30k APIs for use by a .NET developer. I was also told about 97% of the operating system itself will be written in managed code. I would seriously spend my time working with the .NET framework and VS.NET instead of MSVC++ 6.0 and current Windows APIs.Originally posted by DougDbug
Thanks CompiledMonkey, but like I said: "I really didn't get much out of the book, because it uses MFC... and I wanted to... learn the WinAPI."
I do have Petzold's book, and Schildts's similar book. I don't see how the Longhorn API can be THAT much different. If Longhorn doesn't run the existing applications (written with the Win32 API), they aren't going to sell very many copies!!! Win32 is more entrenched than Win16 was when Windows95 was introduced.
ehm, do you mean that the current Win32 API isn't going to be the main API for programming Windows in Longhorn?
BTW, Longhorn was delayed till 2006.
From what I understand, no it will not. Basically everything from now onward from MS will be .NET. I know Longhorn was delayed and I actually hope they never set a release date. I'd rather have it RTM when it is done. Not be rushed out.Originally posted by glUser3f
ehm, do you mean that the current Win32 API isn't going to be the main API for programming Windows in Longhorn?
BTW, Longhorn was delayed till 2006.
