Moving on from console

[ballpointpenguin]

Hello everyone!

This is my first post on these forums, and I'm guessing it won't be my last. Unfortunately though, at the moment I'm frustrated beyond belief. I've been jumping in and out of C++ for a while now, and I finally decided to buckle down and really try to learn the language. I've bought more books than anyone should own on a single subject, but I've learned of one painful truth that exists between all of these books: They never do anything to bridge the gap between programming console applications and actually learning an API.

I've learned quite a bit about C++ already, and I feel fairly confident in my abilities... unfortunately they're limited to outputting text in a simple box. So I guess my question is: What is the next step? I would LOVE to learn how to actually make an application someone would like to use, but at the same time I'd like to avoid "wrappers" and other things that just water down the experience.

I've tried learning the Win32 API, and I do think that's the right way to go, but it just seems so far beyond anything I've learned... I know a part of the problem is probably the fact that I refuse to use anything I don't fully understand; I'm guessing I'm not expected to fully "Get it" yet, and I should just start screwing around, but that's completely against my usual M.O.

Does anyone have any suggestions at all? I'm at my wit's end.

[helios]

LOL books. People still use those to learn programming?

But seriously, now. Of course they won't teach you how to use a library. They're books about the C++ language. It's well beyond their scope to teach any particular library.

I'm curious about what you have against the console and exactly how much you've coded to have outgrown it. I've been writing console-only programs for three years and just last week I've found that I need to do something with GUI. It's possible to write very powerful and complex applications that produce text-only or binary output. For example, the other day I wrote a short app (around 600 lines) that fetches webpages from a list of servers in an SQLite database and extracts data from them, which is added to the database. Naturally, any sort of GUI would be completely unnecessary, and probably annoying to use (since the only user input is starting the program).
Another example? A program that searches a list of directories taken from a config file and tries to find duplicate images.
A wallpaper switcher that runs in the background and is controlled through commands, config files, and global keyboard shortcuts.

I'd like to avoid "wrappers" and other things that just water down the experience.

Hey, here's an idea: send data straight to the graphics driver! Why waste time with abstraction layers when it's much more fun to write code that will work on your machine alone? Reinventing the wheel is always more fun than actually getting work done!
Unless you have very specific needs, abstraction layers are a Good Thing. For instance, you wouldn't write a GUI using the WinAPI directly. You'd use a toolkit like Qt, GTK+, or wxWidgets so that if you ever want to port that horrible mess of yours ("yours" is being used generically. I'm not talking about you specifically), you don't need to rewrite the whole thing from scratch.

[ballpointpenguin]

Hey, here's an idea: send data straight to the graphics driver!

I actually had a friend who was going to teach me assembly just so I could have a better grasp of how to do just that :P

Of course that was just to expand my knowledge, I wasn't planning on actually trying to do that, I just wanted to understand it better so I could be a more efficient trouble-shooter. :P

I've always been a bit of a control-freak. If I don't know exactly why something is working I get really really angry.

The main reason I want to work on gui programs is the same reason everyone does: It's just cooler! :D (Cooler looking at least)

Personally I may or may not have made a World of Warcraft bot in console. I don't even play, but it was just a proof of concept thing. But I'll be damned if it wouldn't have actually been worth distributing if it had a GUI.

You don't think it'd be a good idea to learn Win32 API? I just want full control over what's going on. It's not very likely that that would put me at a disadvantage... just as long as I learn the thing. I would eventually use a wrapper, I'd just feel better if I made the wrapper. :P

Edit: Also, I know the books have no place talking about a library, what I'm saying though is that the books about the API's seem far beyond my knowledge, and that it seems like there's a huge gap between working in the console and actually being able to have some nice gui elements.

[helios]

But I'll be damned if it wouldn't have actually been worth distributing if it had a GUI.

I shared prototype versions of my web crawler as source code. There's nothing more fun than denying user requests ("Boo-hoo. We want binaries!"). If they really want to use it, they'll learn.

You don't think it'd be a good idea to learn Win32 API?

No. It's crap. There's nothing fun about passing over 9000 NULLs and setting up almost as many structures just to open a connection. And don't get me started with threading. The only part that's endurable is file access.
Also, I think it defeats the purpose of using a portable language. If you're going to use the WinAPI, you might as well use VB.

I would eventually use a wrapper, I'd just feel better if I made the wrapper.

You need to shed that way of thinking. Reinventing the wheel is okay if you're doing it as a learning experience. In any other situation, it's jst a waste of time. If someone did it already, it's better to use their solution for two reasons: a) it's less work for you, so it's also faster; and b) since it's been done before, by the time you use it the code base will likely be so mature that it'd take you years to get to that point, which is another way of saving time.
Of course, there are times when a complete rewrite is the only solution (the last time it happened to me, it cost me 19175 lines and still growing).

[ballpointpenguin]

Reinventing the wheel is okay if you're doing it as a learning experience.

That is, essentially, my goal. If you could set help me get a foot in the right direction I would appreciate it endlessly. But while we're at at, what would you suggest as a simple means of getting a very bare-bones GUI running, where I could maintain a reasonable level of freedom over what I could do with it?

over 9000

I hope that was intentional, if you have no idea what I'm talking about, just please disregard it.

[ballpointpenguin]

Also, I do eventually want to learn DirectX and OpenGL. I'd love to start making simple games at some point, but I do understand that it's an incredibly complex undertaking.

[firedraco]

over 9000

Required Link:
http://www.youtube.com/watch?v=SiMHTK15Pik

[chrisname]

You guys just made me lose the game. Now you all lost the game too. Hah.

Anyway, yeah, here's a link to a tutorial on GUI programming.
http://www.rohitab.com/discuss/lofiversion/index.php/t11408.html

Also, here's a little preview of a GUI app that does absolutely nothing:
#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

static char sClassName[] = "MyClass";
static HINSTANCE zhInstance = NULL;

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
WNDCLASSEX WndClass;
HWND hwnd;
MSG Msg;

zhInstance = hInstance;

WndClass.cbSize = sizeof(WNDCLASSEX);
WndClass.style = NULL;
WndClass.lpfnWndProc = WndProc;
WndClass.cbClsExtra = 0;
WndClass.cbWndExtra = 0;
WndClass.hInstance = zhInstance;
WndClass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
WndClass.hCursor = LoadCursor(NULL, IDC_ARROW);
WndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
WndClass.lpszMenuName = NULL;
WndClass.lpszClassName = sClassName;
WndClass.hIconSm = LoadIcon(NULL, IDI_APPLICATION);

if(!RegisterClassEx(&WndClass)) {
MessageBox(0, "Error Registering Class!", "Error!", MB_ICONSTOP | MB_OK);
return 0;
}

hwnd = CreateWindowEx(WS_EX_STATICEDGE, sClassName, "db Tutorial", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT,

CW_USEDEFAULT,
320, 240, NULL, NULL, zhInstance, NULL);

if(hwnd == NULL) {
MessageBox(0, "Error Creating Window!", "Error!", MB_ICONSTOP | MB_OK);
return 0;
}

ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);

while(GetMessage(&Msg, NULL, 0, 0)) {
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}

return Msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
switch(Message) {
case WM_CLOSE:
DestroyWindow(hwnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, Message, wParam, lParam);
}
return 0;
}


That is how ridiculous they are...

[helios]

Curiously enough, only the English version says "9000". All the other versions, including Japanese, say "8000", and not nearly as loud.
Of course, there's a very nice feeling in hearing the voice actor you grew up with saying today's memes.
"¡Es de más de ocho mil!"


But getting back on topic,

But while we're at at, what would you suggest as a simple means of getting a very bare-bones GUI running, where I could maintain a reasonable level of freedom over what I could do with it?

Pretty much the post above. You can write GUIs like that until you're sick of it. When you're done and finally decide you want to get some work done, Google any of the GUI toolkits I mentioned earlier. Qt is my personal favorite and is very feature-rich. For example, it includes, among other things, SQL access, DirectX and OpenGL, and a web rendering engine.