I have been learning windows API from online and PDF books but I hear of people using sdk and visual studio programs. What should i do? API I'd create but extremely complex. Would I benefit from learning the API or should I get a sdk or program that writes to code for me? I have msc++e but I don't think it comes with those benifts
You definitely want to use Visual Studio over using the Windows SDK directly for GUI programming. You can download Visual Studio Express edition to try it out first.
If you want something simpler you can take a look into .NET programming, or if you want to stay with C++ that's fine as well and you can use straight Win32 API or MFC programming. In most cases you probably don't want direct Win32 GUI programming nor MFC but if you do, consider buying a book from Charles Petzold (on Win32) or Jeff Prosise (on MFC).
Although learning the raw Windows API certainly has its usefulness, I'd suggest you learning a toolkit like Qt (http://qt.nokia.com).
The best answer to your question can depend on many things.
I've been developing applications for the Microsoft Windows platform for nearly twenty years, and I've utilized everything from straight Windows API, Turbo Pascal, MFC, Borland C++ builder, and Visual Basic.
I've tried many cross-platform toolkits including as wxWidgets and QT and these most certainly have their place and are excellent options for creating apps that will run on more than just Windows.
In general, if you're ONLY wanting to target the Windows platform (Mono Project notwithstanding), IMHO using the C# language to target the .NET platform with Visual Studio is probably the easiest and full-featured environment you will find for building Windows apps today.
You get an excellent set of tools and a wealth of documentation and probably most importantly a very large base of experienced programmers to draw upon when you have questions.
.NET also supports C++ and a variety of other languages to suit your needs. If you need low level access to the Win32 API, you can access the APIs directly using pinvoke. If you need even lower level control you can reference managed or unmanaged DLLs from your .NET application.
In the case of windows, the SDK and the Win32 API refer to pretty much the same thing. The SDK is all the crap you need to target the API (this is always what an "SDK" is). When you're using a non-VC compiler on windows (or a cross-compiler) you have to download the SDK in order to write win32 programs.
There's very few situations in which targeting the Win32 API itself is useful. You usually want to work at a higher level with an API like MFC, WTL, or WX (I include WX because for windows it's actually a wrapper for Win32). There are also libraries that do their own thing and just draw everything themselves (all owner drawn windows) like Qt, GTK, etc.
If you're working with a windows specific library you'll still end up touching the Win32 API occasionally but only small parts of it. You'll save a LOT of time just letting those parts turn up instead of actually trying to learn the API itself. Nobody that isn't insane or being tortured into submission writes raw Win32.
I know fewer and fewer people writing native apps, especially for a single platform, and especially when that platform is Windows. While there's obviously still demand for this, I'm not sure I'd want to invest a lot of effort today in learning the particulars of the Windows API.
I'd look at something like Titanium that let me use web tools. It's pretty high-level, it's fast enough for pretty much anything I do, it's open-source, and it's cross-platform (even onto the web). I've seen apps (before Titanium) that are written as webpages that ship with their own rendering and javascript engine, too.