I'm rather uncertain as to how you go from making programs which churn values on the Dos screen to actual graphics. I'm not asking for a lesson on this, but I am confused as to how a c++ program creates/manipulates graphics. Is it all done through widgets or is there another method I haven't come across yet?

Thanks
Danny2000

Recommended Answers

All 18 Replies

graphics are almost always done with specialized libraries in C++. These libraries, like opengl, directx, and sdl, have their own frameworks all completely designed toward graphics. You have to learn a lot about the library to use it well, but that's how games and other graphics stuff is made. :)

Sounds like he was asking more about GUI type stuff rather than 3d graphics? In linux, there are a couple of main GUI libraries like QT and GTK. I'm not sure about windows. They usually have some kind of graphical designer that you can layout buttons and textboxes and whatnot, then they use some variation on the idea of "callbacks" - an event gets triggered when the user does something in the GUI and then you have to "handle" the event in the code.

Sorry, I don't know anything about windows GUIs in c++.

Good luck.

Dave

There is freeware Qt for Windows now (from April 2009). There are some other freeware GUI libs for Windows - as usually, they are portable too.

The difference between the DOS command line and the GUI is due to alot of things.

If you are programming in windows, you would use the Windows Application Programming Interface (WinAPI).

The libraries and namespaces:
GUI programs dont use the std:: namespace, because that is designed for DOS output like cin and cout. Instead of including things like <iostream>, it is <windows.h>, <commctrl.h>.
The graphics are actually controls (widgets), that are defined by window, all you do is have to call CreateWindow() or CreateWindowEx(), and store the value from that in a HWND variable. like: HWND hwnd = CreateWindow(...blah blah blah...);

You can learn more about CreateWindowEx() at: http://msdn.microsoft.com/en-us/library/ms632680.aspx

There is actually alot more to it though, but once you get started it isnt too confusing.

Take for instance, Instead of int main(int arg, char arg[]), it is
int WINAPI WinMain

The proccess goes like:

Create all global variables and processes

WinMain
--->Register the window class
--->Create the window
--->Recieve messages from the windows and controls (like when they are clicked, typed in, ect.) and send them to WndProc

WndProc
--->Process the messages, and do something with them.

You can learn how to program GUI applications using the Windows API at: http://www.winprog.org/tutorial/

I hope this helps you understand the concept of, and gets you into programming GUI applications using the Windows API. :)

>If you are programming in windows, you would use the Windows Application >Programming Interface (WinAPI).
And always get struck with windows and make unportable GUIs. Well, there is a very cute library which is called wxWidget. Learn it. It will save you time as it is portable, so would not have to learn a new toolkit when porting your application to other platform.
Even QT and GTK+(which comes with the binding gtkmm for c++) are good alternative.
But please don't settle with windows MFC or any other platform-dependent toolkit.

The beauty of wxWidget is that it uses the native API for the particular platform: like WinAPI when in Windows, GTK+ when in Linux GNOME, QT when in Linux KDE. So, you always get the native feel.

>And always get struck with windows and make unportable GUIs.
siddhant3s, you don't have to take a strike at my integrity just because you don't like my approach. I was just telling him what the jump from command lin to Windows GUI.

WinAPI is the most commonly used and best documented API there is. Just because of a few compromises doesn't mean it has to be taken out of the equation completely.

It is a matter of oppinion, let him decide which he would like to choose. Also, with QT (like another suggested) you dont really code it yourself, its approach is completely indirect. I actually don't recommend it even for beginners, because if you start with it, then you will be reluctant to ever go back to hard coding.

Like when I started with visual basic, I was completely overwhelmed when I moved on to C++.

But there is 2 sides to this, because on the otherhand, if you start with a visual drag 'n drop program, it can ease you into hard coding.

You see siddhant3s, there is problems with both.

Either way it is your choice (@ the thread owner).

>siddhant3s, you don't have to take a strike at my integrity just because you don't
>like my approach.
"strike at my integrity"..... what does that means? I never 'stroked' at your integrity.
Your approach? Which approach?
>GUI programs dont use the std:: namespace, because that is designed for
>DOS output like cin and cout.
I thought toolkits don't use std namespace so that they won't clash with the names with those of std ( which is exactly why namespaces are invented).
Also, std is not designed for command-line output. It is implemented to contain the standard names.


>WinAPI is the most commonly used and best documented API there is.
I can bet you would find more documentation for QT and GTK+. Naturally, M$ cannot compete us( the open-source hackers community). So, you would never find as much quality docs as you would for an opensource toolkit.

>Just because of a few compromises doesn't mean it has to be taken out of the >equation completely.
You call non-portability a minor compromise? I would never use a proprietary toolkit and become a slave of a private firm.

>Also, with QT (like another suggested) you dont really code it yourself, its
>approach is completely indirect.
I don't code? Then who do? And its approach is perfectly fine. It is open-source. You can proceed further development of QT itself; can you proceed the development of any WinAPI yourself? No, you can't as only M$ hired developers are given the source code and not the public. You loose.

>I actually don't recommend it even for beginners, because if you start with it,
>then you will be reluctant to ever go back to hard coding.
Let me tell you one thing: hard coding isn't sexy. QT, GTKmm and wxWidget provide abstracted interface on all platform so you don't need to know what is inside. Which is a good thing. This is all encapsulation is all about. And if you want to see the inner code, you are always invited.

So, there is actually no problem. You learn a good, free, open-source toolkit and start programming GUIs on all platforms.
Yes, of course the choice is of OP.

>No, you can't as only M$ hired developers are given the source code and not the public.
I have every single source code file of the windows API, provided by Dev-Cpp under the Open Source lisence.
The files were not created by MS, they are created by BloodShed developers, see this code from <windows.h>:

/*
	windows.h - main header file for the Win32 API

	Written by Anders Norlander <anorland@hem2.passagen.se>

	This file is part of a free library for the Win32 API.

	This library is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

*/
#ifndef _WINDOWS_H
#define _WINDOWS_H
#if __GNUC__ >=3
#pragma GCC system_header
#endif

/* translate GCC target defines to MS equivalents. Keep this synchronized
   with winnt.h. */
#if defined(__i686__) && !defined(_M_IX86)
#define _M_IX86 600

Siddhant, what I meant by strike at my integrity was that you were saying my approach had downsides, but yet yours did and you didn't even explain what they were, thus basically saying that any WinAPI approach was the worst ever way to go possible, so disregard anything killdude69 says. I have tried QT, it is like visual basic, you wouldn't tell a C++ programmer to go back down to VB programming would you?

I think people shouldn't be so reluctant to try and learn something new, rather than use these programs that program for you like QT. It is not a good thing if you actually plan to stick with it forever. Yes they are good for multiple OSs, but you should also learn how to design the UI yourself without the aid of Drag 'n Drops.

What if everybody didn't know how to hard code, and always used QT? Nobody would actually know how to use C++ in its native form, only being able to code with help from a program that provides indirect functionality.

People should learn multiple APIs and kits. Not just stick with a drag and drop interface that does everything for you.

If you dont know what is inside, then it is more difficult to utilise its full potential.

You can't claim you can win a race if you dont know whats under the hood. All I am saying is if you are ACTUALLY serious about programming then use something that doesn't do everything for you.

Yes, the WinAPI always has its issues, but so does every other API and kit.

>I have tried QT, it is like visual basic, you wouldn't tell a C++ programmer to go back down to VB programming would you?
Are you sure that it looks like VB?

MainWindow::MainWindow()
{
  spreadsheet = new Spreadsheet;
  setCentralWidget(spreadsheet);
  createActions();
  createMenus();
  createContextMenu();
  createToolBars();
  createStatusBar();
  readSettings();
  findDialog = 0;
  setWindowIcon(QIcon(":/images/icon.png"));
  setCurrentFile("");
}
...
bool MainWindow::okToContinue()
{
  if (isWindowModified()) {
    int r = QMessageBox::warning(this, tr("Spreadsheet"),
                 tr("The document has been modified.\n"
                 "Do you want to save your changes?"),
                 QMessageBox::Yes | QMessageBox::Default,
                 QMessageBox::No,
                 QMessageBox::Cancel | QMessageBox::Escape);
    if (r == QMessageBox::Yes) {
        return save();
    } else if (r == QMessageBox::Cancel) {
        return false;
    }
  }
  return true;
}
...
void MainWindow::updateRecentFileActions()
{
  QMutableStringListIterator i(recentFiles);
  while (i.hasNext()) {
    if (!QFile::exists(i.next()))
    i.remove();
  }
  for (int j = 0; j < MaxRecentFiles; ++j) {
    if (j < recentFiles.count()) {
      QString text = tr("&%1 %2")
                     .arg(j + 1)
                     .arg(strippedName(recentFiles[j]));
      recentFileActions[j]->setText(text);
      recentFileActions[j]->setData(recentFiles[j]);
      recentFileActions[j]->setVisible(true);
    } else {
      recentFileActions[j]->setVisible(false);
    }
  }
  separatorAction->setVisible(!recentFiles.isEmpty());
}

I am talking about the programming interface ArkM, it is drag and drop just like VB.

I didn't say the syntax was the same, I'm not blind or stupid. And I am insulted that you seem to think I am.

I'm out of this thread, tired of being treated like a dumbass. I get enough of that already.

>I am talking about the programming interface ArkM, it is drag and drop just like VB
>I'm out of this thread, tired of being treated like a dumbass.
I hope now you will have a time to read Qt documentation: Qt Creator (probably it's that damned drag and drop interface) is an optional tool in Qt SDK. You (and me) can create Qt GUI applications without any visual add-ons...

commented: Thank you ArkM, for not doing like Siddhant and slandering my oppinion just because you didn't like it. Although your comment may have been passive aggressive, you did it in a way that wasn't too disrespectful. For that, I give you respect. +1

QT Creator, as ArkM said, is optional. Just like GLADE for GTK+. And it is no-where VB-like. When we say a thing X is Y-like, usually Y is the pioneer and X has inherited from it. This is not the case with VB.

>I have every single source code file of the windows API, provided by Dev-Cpp
>under the Open Source lisence.
The file you posted is the definition my dear, not the implementation file. Implementation file comes compiled from the OS provider(M$) and thus you won't find its source code.
BloodShed Dev- Has provided you with the definition file so that you can see what all interface is available to you.

>What if everybody didn't know how to hard code, and always used QT?
>Nobody would actually know how to use C++ in its native form, only being
>able to code with help from a program that provides indirect functionality.
Fine, then stop using the STL. Stop using the windows.h and program everything yourself. Stop using the compiler, hard code yourself. Stop using your OS, hard code yourself. Would you?
Look, if your with hard coding, open-source toolkit will provide better control.
I used GTK+ in which I usually had to hard-code( Though, I never felt I was hard coding) while I was making a C app. Here is a Hello World:
[I realized that posting the code would make the thread bloated so here is the link for the same http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD ]

>People should learn multiple APIs and kits.
Very Bad advice. Cross platform toolkit are invented so that you can stick with the famous Unix philosophy " Do one thing; and do it well."
There is no point in learning every other native library for different platforms. Rather Master one cross-platform library ( like wxWidget, QT or GTK) and stay happy.

>If you dont know what is inside, then it is more difficult to utilise its full potential.
Many great programmer don't know whats inside STL, yet they utilize its full potential. This is the key to abstraction.

>All I am saying is if you are ACTUALLY serious about programming then use
>something that doesn't do everything for you.
Fine. So, do you know what is running behind the WInAPI. You cannot, since it is not open source. But our programs are open-source. Hence, you cannot apply your principle to your software as better as you can apply it to ours.
This is the Power of open-source.

WinAPI has a serious issue: It doesn't run on anything other than Windows ;).

commented: Passive aggressive. Not useful. Is not an oppinion, it is a statment to slander ones oppinion. You should have learned that everyone has their own oppinion in kindergarden. +0
commented: Very good post siddhant3s ! +7

I wasn't going to continue this debate, but I am now since I am fed up with this passive aggressive bullshit. Also, I have nothing better to do at the moment.

Just shut up, you don't have to be an ass just because you don't like my oppinion. I treated your oppinion, like an oppinion. Not some type of objective to seek out and destroy. I was trying to be mature, but if you aren't willing then I am not either.

"Fine, then stop using the STL. Stop using the windows.h and program everything yourself. Stop using the compiler, hard code yourself. Stop using your OS, hard code yourself."

Stop doing that, YOU FUCKING KNOW WHAT I MEANT, you are just making an invalid point that doesnt even apply to what I was saying.


>you cannot apply your principle to your software as better
I never once said that it was better, try actually reading my post rather that making it up. They all have flaws, they all have overcomings.

I am just saying that if you are running on windows then learning the WinAPI might be worth your while. Then in the long run you

>WinAPI has a serious issue: It doesn't run on anything other than Windows
No shit sherlock, that is why it is called "WinAPI", Not "LinuxUnixMacWinAPI".

I am sorry for my outburst, but I don't like passive aggressive atittudes like the one from the following quote:
>Very Bad advice.
and
>The file you posted is the definition my dear

commented: Do you know what Daniweb is? It's an IT discussion community, if you're afraid of discussions, then you shouldn't be here, just stop acting as an idiot, the only problem with you is that you don't accept someone else's good advices :angry: !! -1

Thanks very much for all your responses. This really is helpful and has certainly given me an understanding as to where I might find a starting point in this area.

I really do appreciate the help.

Cheers
Danny2000

IMO (= In my opinion) (yea killdude, it's an opinion) you shouldn't use WinAPI for Graphics Programming, it's unportable (as already said by siddhant3s), and there are a lot of better and easier to learn Graphic/GUI Libraries available for cross-platform development, if you write your program, making use of such a library, then you can easily port your application to a wide range of operating systems (And in case of wxWidgets it still uses the OS' native API by default) :)

killdude>The files were not created by MS, they are created by BloodShed developers, see this code from <windows.h>
Wrong, this file was created by the developers of MinGW, the compiler where the Dev-C++ IDE relies on.

Wrong, this file was created by the developers of MinGW, the compiler where the Dev-C++ IDE relies on.

Oh, my bad. :)

On windows, you don't need anything.
Just use Win32 API (GDI, COM, etc).
You can do everything easily

commented: What do you think the whole discussion was about: Not using win32API. If you disagree, give arguments about it. Don't just move your mouth. -2
commented: No!! -1

killdude69, the only way you could hold on to your argument is to talk on situations in which portability has no value. Say, while developing vertical solutions to a non IT based company which uses windows environment, there is no point in providing portability as a feature cause it means nothing to your customer(the customer uses only windows and wouldn't like the distribution of the software to other companies, as in the licence agreement)

In such cases, it is better to exploit tools provided by Microsoft, even if its exactly what Microsoft wants.

In the end its your choice. Be a slave to microsoft or not.

But, I much prefer programs that run on Linux than on windows cause I am a linux lover. Linux is a life saver to people like me who cannot afford to buy windows and who do not want to pirate:$

And you can't deny the fact that you were wrong when you said that you know the source code of win32 api.

To be ignorant is not a big problem, but not to be able admit mistake and learn from it is a problem.

Cheers:)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.