C++

Forum

 
How do you make Applications That Have a GUI?

adn258 (73)
So I have Been making decent console applications for awhile now but there is something about trying to understand The general concepts that leaves me not only confused but unaware of where to begin learning how to make programs with a graphical user interface.

I didn't have this problem of learning where to start in what tools I needed when I wanted to create C++ console applications, but I have this problem now because I fear I am very confused.

First of all, when I open up Microsoft visual C+ there are two options CLR applications and win32 applications. The CLR applications are the only ones that assist you with boxes that you can actually make bigger and add buttons too just dragging things, why is this and what code is this that does this?

I was reading about the win 32 application programming interface but this whole API thing really bothers my brain. What is an API; yes I know it means application programming interface but what are they? Why language do they use? If I wrote a C++ program using the win 32 API would the win 32

Code to be in C++ or something else? What about all these other things people have been saying I can use like WX widgets; what is WX widgets? What do you have to memorize and where do you begin to learn these APIs? If I used WXWIDGETS pretend would that be in C++ too i.e. requiring functions etc. How about QT what's that all about?

After doing hours of research on the Internet for some reason even though I'm good with google I've found it very hard to find information on APIs and in graphical user interfaces for the C++ language. I don't mean to ask so much at once but if someone could just give me a good run around of what all this is/means it would really help me.

Are the CLR applications just simply Microsoft .net also what is Microsoft .net? Is this the application programming interface to? I don't get any of this and I don't know where to begin. I'm hoping somebody here can help me with the above questions

As you can see I'm very confused? Also does pretend I wanted to create a program using WX widgets where it be the first place to begin? What needs memorizing etc.? Lastly if I wanted to port my console applications that I've already made

into a graphics interface what would be the easiest method? Note: most of them are simple programs but they all use the fundamentals of C++ such as functions, classes, name spaces, etc. etc. but I don't get the rest of this.


I know this was long but I really do appreciate anyone that can help me with this whole API\GUI programming thing it's really driving my brain crazy and for some reason I can't find any concrete research on it from google.

I think this is because I'm such a beginner at this that I literally don't know WHAT TO SEARCH FOR OR WHERE TO BEGIN.

Thank you so much

Austin.

freddie1 (1838)
The techniques involved in creating GUI apps are not specific to C++. Almost all the folks doing Windows programming started with Charles Petzold's Books. They are old but still valid. Here is a link to his last book on Windows Programming (before he started writting books on .NET)...

http://www.amazon.com/Programming-Windows-Microsoft-Charles-Petzold/dp/157231995X/ref=sr_1_1?ie=UTF8&s=books&qid=1290484754&sr=8-1

If that book is too expensive for you his Windows 95 book would serve just as well and can be obtained for the price of postage.

Also, a very common link given to these kinds of questions is the Forger's Win32 Api Tutorial....

http://www.winprog.org/tutorial/

Also, I've posted tutorials here...

http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0

It takes a long time to learn Windows programming using the low level Api and C++ so brace yourself for an ordeal. However, its great fun!
freddie1 (1838)
Tomorrow if I have time I'll write a short console program and its counterpart in C++ GUI and post it for you.
freddie1 (1838)
Austin,

Windows, Unix, and Linux were written in C back in the early 80s before C++ was even developed. The lowest level interfaces to these operating systems, that is, their Application Programming Interfaces ( APIs ), are C based; not C++ based. Early Windows programmers used C to write Windows programs. By 1991 Microsoft developed Visual Basic and that allowed for drag and drop Windows Graphical User Interface (GUI) development. On the C++ front, also by 1990, it was realized that C++ object creation capabilities could be used to ‘wrap’ the low level direct Api of Windows into class ‘wrappers’ that hide many of the low level and boiler plate type code from the coder; hopefully making it easier. These are termed ‘Class Frameworks’. There are a lot of them in both the Windows world and the Unix/Linux world. A list of some of them would be Microsoft Foundation Classes (MFC), Object Windows Library (OWL), .NET, wxWidgets, Qt, ad infinitum. These last mentioned are ‘cross platform’, in that GUI programs developed with them can be compiled for either Windows or Unix/Linux. You have to understand though that there is no fundamental ‘C++’ way of writing GUI programs. Any Class Framework you use makes C based calls to the underlying API of the host operating system. In other words, a Class Framework is an ‘abstraction layer’ that sits on top of the underlying API, in the same sense as the ‘methods’ of your classes are an abstraction layer on top of the procedural code you compiler generates (but you never see) when you compile your classes.

When you want to get started writing GUI programs (for any operating system) you have to decide what fits your personality, inclinations, and needs. If you are a fast results type person and you want to leverage as much as possible off other programmer’s code, that is, you don’t care so much how it works, only that it works, then perhaps one of the class frameworks that hide a lot of low level details is right for you. The positives of this choice are that you can get your program written quicker; oftentimes with drag and drop type programming environments. The negatives of this style are that the programs tend to be somewhat slow, they are oftentimes massive in terms of code size (a lot of library code compiled into them), and what’s considered the ‘best’ framework changes every couple years. The various frameworks come into and fall out of favor fairly rapidly.

On the other hand, if you’ve got a lot of time to sink into your code, you like to know how things work ‘under the hood’, so to speak, or you need to do some specialized things that aren’t easily or even possible to do through the class framework code, then you need to use an operating system’s API directly. That’s basically what the ‘Win32’ choice is in Visual Studio or Code::Blocks specifically. The advantages of this approach are extremely small fast code. Also, it tends to be stable and the underlying APIs don’t change very frequently. The down side of course is its fairly steep learning curve.

I personally take this latter choice. I write strictly Win32 code. However, I compile all my programs as C++ programs, and use classes for ‘business objects’, that is, if OOP makes sense for the computations I’m doing or whatever, I use it. However, my GUI interfaces are strictly low level Api C based. And there is anoter point I want to make, and that is that the C Api of Windows was designed in a very object oriented manner. Windows on the screen are themselves ‘objects’, that is, members of a ‘class’, and they have mutators, constructors, and destructors; albiet all C based.

You want to convert your C++ console programs to GUI programs, so lets start with that concept. Here is CBox1, a typical and simple console C++ program a beginner might make. It calculates the volume of a box…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
//Cbox.h
#ifndef CBox_h
#define CBox_h

class CBox
{
 public:
 CBox(double,double,double);  //Constructor
 ~CBox();                     //Destructor
 double GetLength();          //m_Length accessor
 double GetWidth();           //m_Width accessor
 double GetHeight();          //m_Height accessor
 double Volume();             //Returns Volume() of Box

 private:
 double m_Length;
 double m_Width;
 double m_Height;
};
#endif 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
//CBox.cpp
#include "CBox.h"

CBox::CBox(double dblLength, double dblWidth, double dblHeight)
{
 this->m_Length=dblLength;
 this->m_Width=dblWidth;
 this->m_Height=dblHeight;
}

CBox::~CBox()
{
 //destructor
}

double CBox::GetLength()
{
 return this->m_Length;
}

double CBox::GetWidth()
{
 return this->m_Width;
}

double CBox::GetHeight()
{
 return this->m_Height;
}

double CBox::Volume()
{
 return m_Length*m_Width*m_Height;
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
//Main.cpp
#include <iostream>
#include "CBox.h"
using namespace std;

int main()
{
 CBox Box(2.0,3.0,4.0);

 cout << "Box.GetLength() = " << Box.GetLength() << endl;
 cout << "Box.GetWidth()  = " << Box.GetWidth() << endl;
 cout << "Box.GetHeight() = " << Box.GetHeight() << endl;
 cout << "Box.Volume()    = " << Box.Volume() << endl;

 return 0;
}


/*
Compiling: main.cpp
Linking console executable: CBox1.exe
Output size is 270.50 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

Box.GetLength() = 2
Box.GetWidth()  = 3
Box.GetHeight() = 4
Box.Volume()    = 24
*/


Using Code::Blocks this program compiles to 270.50 K which is atrocious, reprehensible, disgusting, unfortunate, and unnecessary. Here is the exact same program (Cbox2 this time) without the miserable, ridiculous, and bloated iostream library…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
//Cbox.h
#ifndef CBox_h
#define CBox_h

class CBox
{
 public:
 CBox(double,double,double);  //Constructor
 ~CBox();                     //Destructor
 double GetLength();          //m_Length accessor
 double GetWidth();           //m_Width accessor
 double GetHeight();          //m_Height accessor
 double Volume();             //Returns Volume() of Box

 private:
 double m_Length;
 double m_Width;
 double m_Height;
};
#endif 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
//CBox.cpp
#include "CBox.h"

CBox::CBox(double dblLength, double dblWidth, double dblHeight)
{
 this->m_Length=dblLength;
 this->m_Width=dblWidth;
 this->m_Height=dblHeight;
}

CBox::~CBox()
{
 //destructor
}

double CBox::GetLength()
{
 return this->m_Length;
}

double CBox::GetWidth()
{
 return this->m_Width;
}

double CBox::GetHeight()
{
 return this->m_Height;
}

double CBox::Volume()
{
 return m_Length*m_Width*m_Height;
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
//Cbox2 – Main.cpp
#include <stdio.h>
#include "CBox.h"

int main()
{
 CBox Box(2.0,3.0,4.0);

 printf("Box.GetLength() = %3.2f\n",Box.GetLength());
 printf("Box.GetWidth()  = %3.2f\n",Box.GetWidth());
 printf("Box.GetHeight() = %3.2f\n",Box.GetHeight());
 printf("Box.Volume()    = %3.2f\n",Box.Volume());

 return 0;
}

/*
Compiling: main.cpp
Linking console executable: CBox2.exe
Output size is 19.50 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

Box.GetLength() = 2.00
Box.GetWidth()  = 3.00
Box.GetHeight() = 4.00
Box.Volume()    = 24.00
*/


As can be seen this compiles to 19.5K instead of 270.5K. I’d say that’s considerably more decent and no harder. Now lets convert that to a Win32 GUI program. I’m using Code::Blocks because it follows my philosophy of being more lightweight and easier to use than the massive bloatware Microsoft product Visual Studio, but I do use VS for my Embedded programming. If you are using Visual Studio set up a Win32 ‘Empty Project’. Also, you might have to tell VS not to use Unicode because I wanted to spare myself from the aggravation of the _T() macros and such. So here is the above program converted to classic Win32 (next post)…
Last edited on
freddie1 (1838)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
//Cbox.h
#ifndef CBox_h
#define CBox_h

class CBox
{
 public:
 CBox(double,double,double);  //Constructor
 ~CBox();                     //Destructor
 double GetLength();          //m_Length accessor
 double GetWidth();           //m_Width accessor
 double GetHeight();          //m_Height accessor
 double Volume();             //Returns Volume() of Box

 private:
 double m_Length;
 double m_Width;
 double m_Height;
};
#endif 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
//CBox.cpp
#include "CBox.h"

CBox::CBox(double dblLength, double dblWidth, double dblHeight)
{
 this->m_Length=dblLength;
 this->m_Width=dblWidth;
 this->m_Height=dblHeight;
}

CBox::~CBox()
{
 //destructor
}

double CBox::GetLength()
{
 return this->m_Length;
}

double CBox::GetWidth()
{
 return this->m_Width;
}

double CBox::GetHeight()
{
 return this->m_Height;
}

double CBox::Volume()
{
 return m_Length*m_Width*m_Height;
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
 
//Main.cpp
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include "CBox.h"

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch (msg)
 {
  case WM_PAINT:
  {
    PAINTSTRUCT ps;
    HDC hDC;
    HFONT hFont,hTmp;
    CBox Box(2.0,3.0,4.0);
    char szBuffer[128];
    hDC=BeginPaint(hwnd,&ps);
    SetBkMode(hDC,TRANSPARENT);
    hFont=CreateFont(20,0,0,0,FW_BOLD,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,PROOF_QUALITY,DEFAULT_PITCH,"Courier New");
    hTmp=(HFONT)SelectObject(hDC,hFont);
    sprintf(szBuffer,"Box.GetLength() = %3.2f",Box.GetLength());
    TextOut(hDC,75,40,szBuffer,strlen(szBuffer));
    sprintf(szBuffer,"Box.GetWidth()  = %3.2f",Box.GetWidth());
    TextOut(hDC,75,60,szBuffer,strlen(szBuffer));
    sprintf(szBuffer,"Box.GetHeight() = %3.2f",Box.GetHeight());
    TextOut(hDC,75,80,szBuffer,strlen(szBuffer));
    sprintf(szBuffer,"Box.Volume()    = %3.2f",Box.Volume());
    TextOut(hDC,75,100,szBuffer,strlen(szBuffer));
    SelectObject(hDC,hTmp);
    DeleteObject(hFont);
    EndPaint(hwnd,&ps);
    break;
  }
  case WM_DESTROY:
  {
    PostQuitMessage (0);
    break;
  }
  default:
    return DefWindowProc(hwnd,msg,wParam,lParam);
 }

 return 0;
}

int WINAPI WinMain(HINSTANCE hIns, HINSTANCE hPrevIns, LPSTR lpszArgument, int iShow)
{
 char szClassName[]="CBox3";
 WNDCLASSEX wincl;
 MSG messages;
 HWND hWnd;

 wincl.hInstance=hIns;
 wincl.lpszClassName=szClassName;
 wincl.lpfnWndProc=WndProc;
 wincl.style=CS_DBLCLKS;
 wincl.cbSize=sizeof (WNDCLASSEX);
 wincl.hIcon=LoadIcon(NULL,IDI_APPLICATION);
 wincl.hIconSm=LoadIcon(NULL, IDI_APPLICATION);
 wincl.hCursor=LoadCursor(NULL,IDC_ARROW);
 wincl.lpszMenuName=NULL;
 wincl.cbClsExtra=0;
 wincl.cbWndExtra=0;
 wincl.hbrBackground=(HBRUSH)COLOR_BACKGROUND;
 RegisterClassEx(&wincl);
 hWnd=CreateWindow(szClassName,szClassName,WS_OVERLAPPEDWINDOW,200,100,400,350,HWND_DESKTOP,0,hIns,0);
 ShowWindow(hWnd,iShow);
 while(GetMessage(&messages,NULL,0,0))
 {
  TranslateMessage(&messages);
  DispatchMessage(&messages);
 }

 return messages.wParam;
}

/*
Compiling: main.cpp
Linking executable: CBox3.exe
Output size is 22.00 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
*/


As you can see, we’re up to 22.0K from the 19.5K of the console program. That’s not too bad. If you use MFC you’re over a megabyte. If you use .NET you are dependent on the whole .NET framework, and it’ll run slowwwww. Likewise wxWidgets and Qt programs will be massive.

The way I coded that program isn’t the way I’d actually do it if it was a real program of mine. However, I wanted to show you classic Win32 Api style, and what goes into converting a console program to Win32 Gui, as you expressed that interest. I’ll enhance the program further later.
Computergeek01 (5613)
@fredie1: These posts are very well written and informative. I would like to point out to you that this site has an area for articles and I would say that what you have here more then qualifies to be in that section. As a frequent user of this site I would ask that you consider writing an article that everyone now and in the future can use them and your contribution won't fall into oblivion.

EDIT: In defence wxWidgets calling the programs it outputs massive in the same paragraph as calling .NET slow is very misleading. wxWidgets adds noticable overhead to simple programs yes but when you start using multiple libraries for more complex programs that hardley becomes noticable.
Last edited on
freddie1 (1838)
Hi Computergeek01!

Just looked there for the 1st time! I'll have to consider that like you said. Anyway, I had a few minutes today to modify my above CBox3 example to show how to do OOP with the C oriented Win Api. Here is CBox4 with comments (hopefully useful) and the style I typically use. I'll not bother posting CBox.cpp and CBox.h as they are exactly as in the above program. This one compiles to about 22.5K with CodeBlocks...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
//Main.h

typedef struct    WindowsEventArguments
{
 HWND             hWnd;
 WPARAM           wParam;
 LPARAM           lParam;
 HINSTANCE        hIns;
}WndEventArgs, *lpWndEventArgs;


struct EVENTHANDLER
{
 unsigned int    Code;
 long            (*fnPtr)(lpWndEventArgs);
};


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
 
//Main.cpp                                   //C++ Object Oriented Program using native
#include <windows.h>                         //Windows C Api to display the dimensions
#include <stdio.h>                           //and volume of a class CBox object.
#include "Main.h"
#include "CBox.h"                            //Note that this program contains no global
EVENTHANDLER  EventHandler[3];               //variables.  EventHandler is an array of
                                             //function pointers.

long fnWndProc_OnCreate(lpWndEventArgs Wea)  //When the window object is created, create
{                                            //a CBox object and store/set a pointer to
 CBox* pBox=NULL;                            //in the Window Class struct.  If the
                                             //memory allocation (new) fails, return -1
 pBox=new CBox(2.0,3.0,4.0);                 //and program initialization will halt and
 if(pBox)                                    //WinMain() will exit.  A WM_CREATE message
    SetWindowLong(Wea->hWnd,0,(long)pBox);   //is received one time on Window creation.
 else                                        //The CreateWindow() call in WinMain() won't
    return -1;                               //return until this procedure returns.

 return 0;
}


long fnWndProc_OnPaint(lpWndEventArgs Wea)   //Windows will send a WM_PAINT message to
{                                            //a window when any part of the window
 CBox* pBox=NULL;                            //becomes 'invalid' and needs to be
 HFONT hFont,hTmp;                           //repainted.  This will occur at program
 PAINTSTRUCT ps;                             //start up and any time the window is
 HDC hDC;                                    //uncovered by another window.  A pointer
                                             //to the window's CBox object is stored
 char szBuffer[128];                         //in the window's Class Extra Bytes
 hDC=BeginPaint(Wea->hWnd,&ps);              //( .cbWndExtra ), and is here accessed
 SetBkMode(hDC,TRANSPARENT);                 //using the Api function GetWindowLong().
 hFont=CreateFont                            //To draw to a window in a WM_PAINT...
 (
  28,0,0,0,FW_HEAVY,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,      //handler one may use
  CLIP_DEFAULT_PRECIS,PROOF_QUALITY,DEFAULT_PITCH,"Courier New" //TextOut(), but that
 );                                                             //function requires a
 hTmp=(HFONT)SelectObject(hDC,hFont);                           //handle to a device
 pBox=(CBox*)GetWindowLong(Wea->hWnd,0);                        //context obtainable
 sprintf(szBuffer,"Box.GetLength() = %6.2f",pBox->GetLength()); //with BeginPaint().
 TextOut(hDC,25,30,szBuffer,strlen(szBuffer));                  //The C Runtime func
 sprintf(szBuffer,"Box.GetWidth()  = %6.2f",pBox->GetWidth());  //sprintf can be used
 TextOut(hDC,25,60,szBuffer,strlen(szBuffer));                  //to output a text string
 sprintf(szBuffer,"Box.GetHeight() = %6.2f",pBox->GetHeight()); //to an output buffer,
 TextOut(hDC,25,90,szBuffer,strlen(szBuffer));                  //and then TextOut()
 sprintf(szBuffer,"Box.Volume()    = %6.2f",pBox->Volume());    //will draw the text.
 TextOut(hDC,25,120,szBuffer,strlen(szBuffer));                 //A FONT is a GDI object
 SelectObject(hDC,hTmp);                                        //and needs to be
 DeleteObject(hFont);                                           //released to prevent
 EndPaint(Wea->hWnd,&ps);                                       //memory leaks.  Finally
                                                                //EndPaint() needs to be
 return 0;                                                      //called to terminate use
}                                                               //of the device context.


long fnWndProc_OnDestroy(lpWndEventArgs Wea) //When you click the 'x' button in the
{                                            //window's title bar Windows will send
 CBox* pBox=NULL;                            //WM_CLOSE and WM_DESTROY messages (among
                                             //others) to the window's Window Procedure.
 pBox=(CBox*)GetWindowLong(Wea->hWnd,0);     //This program needs to delete the CBox
 if(pBox)                                    //object a pointer to which is stored in
    delete pBox;                             //the program's .cbWndExtra bytes.  Then
 PostQuitMessage(0);                         //PostQuitMessage() needs to be called so
                                             //the message pump in WinMain() will exit
 return 0;                                   //and the program will end.
}


void AttachEventHandlers(void)         //This procedure maps windows messages to the
{                                      //procedure which handles them.
 EventHandler[0].Code=WM_CREATE,       EventHandler[0].fnPtr=fnWndProc_OnCreate;
 EventHandler[1].Code=WM_PAINT,        EventHandler[1].fnPtr=fnWndProc_OnPaint;
 EventHandler[2].Code=WM_DESTROY,      EventHandler[2].fnPtr=fnWndProc_OnDestroy;
}


LRESULT CALLBACK fnWndProc(HWND hwnd, unsigned int msg, WPARAM wParam,LPARAM lParam)
{
 WndEventArgs Wea;                  //This procedure loops through the EVENTHANDER array
                                    //of structs to try to make a match with the msg parameter
 for(unsigned int i=0; i<3; i++)    //of the WndProc.  If a match is made the event handling
 {                                  //procedure is called through a function pointer -
     if(EventHandler[i].Code==msg)  //(EventHandler[i].fnPtr).  If no match is found the
     {                              //msg is passed onto DefWindowProc().
        Wea.hWnd=hwnd, Wea.lParam=lParam, Wea.wParam=wParam;
        return (*EventHandler[i].fnPtr)(&Wea);
     }
 }

 return (DefWindowProc(hwnd, msg, wParam, lParam));
}


int WINAPI WinMain(HINSTANCE hIns, HINSTANCE hPrevIns, LPSTR lpszArgument, int iShow)
{
 char szClassName[]="CBox4";
 WNDCLASSEX wc;
 MSG messages;
 HWND hWnd;

 AttachEventHandlers();
 wc.lpszClassName=szClassName;                wc.lpfnWndProc=fnWndProc;
 wc.cbSize=sizeof (WNDCLASSEX);               wc.style=CS_DBLCLKS;
 wc.hIcon=LoadIcon(NULL,IDI_APPLICATION);     wc.hInstance=hIns;
 wc.hIconSm=LoadIcon(NULL, IDI_APPLICATION);  wc.hCursor=LoadCursor(NULL,IDC_ARROW);
 wc.hbrBackground=(HBRUSH)COLOR_BTNSHADOW;    wc.cbWndExtra=4;
 wc.lpszMenuName=NULL;                        wc.cbClsExtra=0;
 RegisterClassEx(&wc);
 hWnd=CreateWindowEx(0,szClassName,szClassName,WS_OVERLAPPEDWINDOW,100,100,400,300,HWND_DESKTOP,0,hIns,0);
 ShowWindow(hWnd,iShow);
 while(GetMessage(&messages,NULL,0,0))
 {
    TranslateMessage(&messages);
    DispatchMessage(&messages);
 }

 return messages.wParam;
}
freddie1 (1838)

In defence wxWidgets calling the programs it outputs massive in the same paragraph as calling .NET slow is very misleading. wxWidgets adds noticable overhead to simple programs yes but when you start using multiple libraries for more complex programs that hardley becomes noticable.


Its a very tough call what frameworks to use in writting GUIs and I doubt many are experts in them all. I know I'm not and I have my biases and opinions. In the future I'll try to tone down my rhetoric.

I could clean this up and post it as an article. Does it have to be or should it be proof read by anyone first or can I just post it?
adn258 (73)
I want to say that I really appreciate all the help in here from the programming geniuses I'm not kidding, you guys are great thank you so much for the quick responses and help.

Austin
freddie1 (1838)

First of all, when I open up Microsoft visual C+ there are two options CLR applications and win32 applications. The CLR applications are the only ones that assist you with boxes that you can actually make bigger and add buttons too just dragging things, why is this and what code is this that does this?


I'll elaborate further on this, although I touched on the topic already.

The tools programmers use to create applications have become exceedingly sophisticated and complicated over the years. Back in the 1980s if you wanted to create a program you typed text in very simple text editors (even simpler than today's Notepad.exe), then at the command line executed a command line statement to invoke a compiler to compile your program such as...

C:>cl MyProg.c

Then in the late 80s compiler vendors wrote programming editors to automatically invoke the compiler through drop down menu items. This was the beginning of IDEs - 'Integrated Development Environments'. Borland's Turbo C and Microsoft's QuickBasic were the beginning of this. By the early 90s these large vendors figured out how to graphically display 'tookboxes' on the screen with small icons for the various GUI widgets such as buttons, text boxes, etc., that one could drag onto a design time representation of a window, and when run would look like the design time representation. The development environment writes the code automatically for the user of such a tool. This is all well and good, but it has spawned a generation of coders who can't write code anymore (I work alone; I've only heard of this, so I'm expressing hearsay on this topic). So I guess if you want to use such tools to create apps you ought to try to learn what the tool is doing on your behalf.

I'm expressing my opinion here too, but I prefer not to use such tools. I like to write all my own code. Actually, I copy/paste a lot. But at least its code I originally wrote,so I know how it works.

As an aside, every new programmer should learn how to compile programs from the command line. Later I'll post a description of how to compile those programs I posted further up in this thread from the command line. Its fun to do occasionally.
Last edited on
adn258 (73)
Very interesting Fred Yes I am starting to get the hang of this a little bit. I agree! I think it's very important to especially know the basics VERY WELL such as the tutorials on the main page of this site. I have been using QT a bit and while you still have to know SOME CODE" like how to use a function etc. you certainly wouldn't have to probably be a Ken Jennings from Jeopardy uhahah! Just kidding. In seriousness though he was supposed to be a software programmer. In any case for now I will use QT but I do try to figure out what the code means since that's of interest to me one and two, I don't even have all the basics down pat yet from this site to make good console programs.

In total I am finding that I enjoy making console programs more than GUI programs. IS that a bad thing? While there isn't a lot of money in it anymore there's nothing a console program really can't do right? I think most people these days are just easily intimidated too by having to type a few things ; they want happy things to click instead.

Peace
freddie1 (1838)
Glad to hear you are making progress. No, there isn't anything at all wrong with console programs. I make more of them actually than GUI programs. The Windows Api has a whole host of functions implemented in kernel32.dll that do quite a bit more than the standard C or C++ libraries for dealing with consols. For example, you can make mouse driven point and click console programs even. However, console programs are wonderful for exploring and testing various things. All the kinds of things that give programmers headaches aren't exclusively GUI related.
Topic archived. No new replies allowed.