Pelles C forum
C language => Beginner questions => Topic started by: Cnoob on April 28, 2015, 12:05:58 PM
-
Hi
Can anyone advise as to the easiest (for a noob) GUI lib to use with Pelles?
T.I.A.
-
Plain WinAPI?
#include <windows.h>
#include <stdio.h> // needed for fopen
#pragma comment(linker, "comdlg32.lib") // needed for GetOpenFileName
#pragma comment(linker, "gdi32.lib") // needed for GetStockObject
#pragma warn(disable:2216) // retval never used
#pragma warn(disable:2118) // parameter .. is not referenced
#define winX 200 // main window x, y, width and height
#define winY 200
#define winW 700
#define winH 700
HWND hEdit; // global handle to the edit control
HINSTANCE hInst; // global instance handle
void ReadFile2EditControl(char* filename) { // does what its name says
FILE *ofp = fopen(filename, "rb");
if (ofp) {
fseek(ofp, 0, SEEK_END); // GetFileSize() won't work, so let's do it the archaic C way
int fLen=ftell(ofp); // position at end equals length of file
fseek(ofp, 0, SEEK_SET); // go back to start
PSTR pstrBuffer=malloc(fLen+1); // buffer includes a zero delimiter
if (pstrBuffer) {
fread (pstrBuffer, 1, fLen, ofp); // read content into buffer
pstrBuffer[fLen] = '\0'; // set the delimiter explicitly
SetWindowText (hEdit, pstrBuffer) ; // put text into the edit control
free (pstrBuffer) ;
}
fclose (ofp) ;
}
}
LRESULT CALLBACK WndProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg) {
case WM_CREATE:
{
int htMenu=0;
#define mOpen 101
#define mSave 102
#define hasmenu 1 // 0 = no menu
#if hasmenu
HMENU hMenu, hSubMenu;
hMenu=CreateMenu(); // create the main menu
hSubMenu=CreateMenu(); // create a sub-menu
AppendMenu(hMenu, MF_POPUP, (int)hSubMenu, "&File"); // add it to the main menu
AppendMenu(hSubMenu, MF_STRING, mOpen, "&Open"); // and add
AppendMenu(hSubMenu, MF_STRING, mSave, "&Save"); // two items
SetMenu(hwnd, hMenu); // attach menu to main window
htMenu=GetSystemMetrics(SM_CYMENU);
#endif
hEdit=CreateWindowEx(WS_EX_CLIENTEDGE, "edit", NULL,
WS_CHILD | WS_VISIBLE | WS_BORDER | WS_VSCROLL | ES_MULTILINE,
2, 1, winW-12, winH-htMenu-33, hwnd, (HMENU)103, hInst, NULL); // we have added an edit control
SendMessage(hEdit, EM_LIMITTEXT, 0, 0); // no limit
SetFocus(hEdit); // make sure you can start typing right away
SendMessage(hEdit, WM_SETFONT, (int)GetStockObject(ANSI_FIXED_FONT), 0); // SYSTEM_FIXED_FONT is bold and larger
}
break;
case WM_COMMAND:
if ((short)wParam==mOpen)
{
char fileName[MAX_PATH]="\x0000";
OPENFILENAME ofn;
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFilter ="Sources and Headers\0*.c;*.h;*.as?\0\0";
ofn.lpstrFile = fileName;
ofn.nMaxFile = MAX_PATH;
ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
if (GetOpenFileName(&ofn)) ReadFile2EditControl(fileName);
}
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
MSG msg;
WNDCLASS wc;
HWND hwnd;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.lpszClassName = "MyClass";
wc.hInstance = hInstance;
wc.hbrBackground = (HBRUSH) (COLOR_BTNFACE+1);
wc.lpszMenuName = NULL;
wc.lpfnWndProc = WndProc;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
RegisterClass(&wc);
hInst = hInstance;
hwnd = CreateWindow(wc.lpszClassName, "Hello World",
WS_OVERLAPPEDWINDOW | WS_VISIBLE,
winX, winY, winW, winH,
NULL, NULL, hInstance, NULL);
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (int) msg.wParam;
}
-
Hi jj2007
You must be joking, although I really appreciate you taking the time to reply, look at that code from a noob's perspective.
There is just too much when compared to something like GTK+
#include <gtk/gtk.h>
int main( int argc, char *argv[])
{
GtkWidget *window;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_show(window);
gtk_main();
return 0;
}
Which creates:
(http://zetcode.com/img/gui/cgtk/simple.png)
I understand that the example in GTK+ is much simpler than the one you provided but it is much easier than the standard API, surely you agree?
Since posting my original question, continued to look at all the GUI libraries available and GTK+ looks about the simplest, just not sure how well it's supported with Pelles.
-
I understand that the example in GTK+ is much simpler than the one you provided
Indeed. Add an edit control, a menu that works, a file open dialog and the ability to read the content of the chosen file into the edit control.
Then compare the two codes, and the sizes of the executables.
-
I have no doubt that the resulting file size will be greater but it's a trade-off between simplicity and file size, within reason of course.
Have a look at this example: ( from here http://zetcode.com/tutorials/gtktutorial/gtkwidgetsII/ (http://zetcode.com/tutorials/gtktutorial/gtkwidgetsII/) )
#include <gtk/gtk.h>
int main( int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *label1;
GtkWidget *label2;
GtkWidget *hseparator;
GtkWidget *vbox;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
gtk_window_set_title(GTK_WINDOW(window), "GtkHSeparator");
gtk_window_set_resizable(GTK_WINDOW(window), FALSE);
gtk_container_set_border_width(GTK_CONTAINER(window), 20);
label1 = gtk_label_new("Zinc is a moderately reactive, blue gray metal \
that tarnishes in moist air and burns in air with a bright bluish-green flame,\
giving off fumes of zinc oxide. It reacts with acids, alkalis and other non-metals.\
If not completely pure, zinc reacts with dilute acids to release hydrogen.");
gtk_label_set_line_wrap(GTK_LABEL(label1), TRUE);
label2 = gtk_label_new("Copper is an essential trace nutrient to all high \
plants and animals. In animals, including humans, it is found primarily in \
the bloodstream, as a co-factor in various enzymes, and in copper-based pigments. \
However, in sufficient amounts, copper can be poisonous and even fatal to organisms.");
gtk_label_set_line_wrap(GTK_LABEL(label2), TRUE);
vbox = gtk_vbox_new(FALSE, 10);
gtk_container_add(GTK_CONTAINER(window), vbox);
hseparator = gtk_hseparator_new();
gtk_box_pack_start(GTK_BOX(vbox), label1, FALSE, TRUE, 0);
gtk_box_pack_start(GTK_BOX(vbox), hseparator, FALSE, TRUE, 10);
gtk_box_pack_start(GTK_BOX(vbox), label2, FALSE, TRUE, 0);
g_signal_connect_swapped(G_OBJECT(window), "destroy",
G_CALLBACK(gtk_main_quit), G_OBJECT(window));
gtk_widget_show_all(window);
gtk_main();
return 0;
}
(http://zetcode.com/img/gui/cgtk/separator.png)
How does the straight WinAPI method compare?
I don't mean it in a GTK is better way, I'm just looking for the simplest way.
Since both the GTK and API methods will have plenty of a certain amount of code as standard (per widget/dialog) maybe putting some/most of it
in a macro or an include file is one way to go?
For example, take the line:
gtk_container_set_border_width(GTK_CONTAINER(window), 20);
Could become:
#define SetBorderWidth(w) gtk_container_set_border_width(GTK_CONTAINER(window), (w))
So we only need:
SetBorderWidth(20);
Could do this with lots more and save the macros in a separate include file.
-
I think that the GUI programming as the language choice is a personal preference, you can discuss for months, but there will always be good points for one and the other side ;D
Don't forget that the main reason for GTK, and similar, anyway is the necessity to have a GUI system that can be used on different platforms (the same GUI desing will work on Linux or Windows or else). :)
-
Hi frankie
You are right in what you say and people will have their own choices about what they use.
As for me, I don't think that GTK is fantastic, it just looks the easiest to start with especially when combined with simplifying macros.
As JJ2007 wrote, there will be an overhead in file size and possibly even speed but that is the price to pay for something simpler.
By simpler I mean easier to start with, certainly not simpler as far as all the extra dependencies go.
-
UPDATE:
Compiled the code in reply #4 and it came to 19KB, very acceptable.
-
Compiled the code in reply #4 and it came to 19KB, very acceptable.
That is indeed not much. Rumours say a "small" QT executable is about 10MB, so 19k is nothing compared to QT.
As Frankie wrote, the main reason for such packages is cross-platform compatibility. If being able to run it on Linux (1.5% of the market) and MacOS (8%) is an argument, ok, consider GTK.
If you are targeting Windows anyway, consider that the pure WinAPI example I posted does quite a bit of user interaction, with the menu and the file dialog. The gtk example just paints a static text. Here is one that does roughly the same:
GuiParas equ "Hello jj2007", x200, y200, w360, h80
include \masm32\MasmBasic\Res\MbGui.asm
Event Paint
GuiText 3, 3, "Zinc is a moderately reactive, blue gray metal"
GuiEndA full-fledged Windows GUI application in five lines that displays a text but does otherwise nothing (it's not even C, it's assembler).
Complexity comes in when you start interacting with the user. How do you handle a mouse click, or keyboard input? How do you handle menus? What happens if you have a button in the upper right corner, and the user decides to resize the window?
One point to take into account is documentation. The Windows message loop may look a bit complicated at first sight, but when you google e.g. for WM_LBUTTONDOWN, you'll get 150,000+ hits, most of them code examples. Try to find the equivalent for gtk... ok, here is the official gtk tutorial for event handling (http://www.gtk.org/tutorial1.2/gtk_tut-23.html#ss23.2) 8)
-
Hi jj2007
Without a doubt that there will be much more information available on the WinAPI then that for GTK.
The problem with the API method, is not that each line is complicated, it's the sheer number that is required.
From a noob's perspective, it's complicated enough trying to learn C without the extra need to remember
the whole sequence of commands and functions required to draw a simple text screen in a GUI.
This is where (IMO) GTK comes in, it simplifies things and one can even take it one step further and use macros.
However, it must be said that it's important not to over use macros and make it decidedly not very C like.
After all the whole idea is to learn C, so the GUI should be a customizable and easy layer on top of that whilst maintaining the C syntax as much as possible.
As for QT, uuurggh, I'm sure it has it's benefits but I see it as a clumsy brontosaurus trying to ride a mono-cycle
Have also heard that Nokia contributed code to it, well if that code is anything like they used in their phones (prior to the microsoft take-over), that alone
should be reason enough to stay well clear of QT at all costs.
I have pretty much decided that despite it's disadvantages, GTK is the way to go, or at least in the beginning as when used with macros, the whole GUI layer thing
becomes much more palatable.
This route has two other advantages, firstly as I create the macros, I'm learning C (and the joys of the pre-processesor ;D ) and if ever need to do GUIs in Linux,
GTK will already be familiar territory so to speak.
-
As a side consideration only.
If you want learn C just produce console programs.
If you want learn Win programming use WinAPI, masking the more or less complex mechanisms that are behind using a surrogate is not effective: What you need to learn is how things works, how messages rotates, how they are handled, etc. ;)
-
:D or just to make up complex gui apps with minimum efforts.... if so - you probably should change the langauge...C is not proper choice for
-
From a noob's perspective, it's complicated enough trying to learn C without the extra need to remember
the whole sequence of commands and functions required to draw a simple text screen in a GUI.
That's the core of the problem right here. Don't take two steps at once, do one at a time. First learn to properly code in C, understanding how pointers work, etc...
And only once you got the gist on that one, then start programming for a GUI. That's a complete different issue all together, regardless of the OS. And regardless of what kind of library/framework you are using...
Ralf
-
And only once you got the gist on that one, then start programming for a GUI. That's a complete different issue all together, regardless of the OS. And regardless of what kind of library/framework you are using...
Ralf
Even so - C usage for GUI programming-POOR choice regardless any framework (exept some simple cases or very special requirements upon).
-
Even so - C usage for GUI programming-POOR choice regardless any framework (exept some simple cases or very special requirements upon).
Nonsense. The whole Windows API is accessible to C, GUI-wise there is absolutely nothing you couldn't do in C. My personal editor's source is 16k lines, if that is possible in assembler, it certainly works also in C. Give me one example of a GUI feature that can't be implemented in C...
-
Nonsense. The whole Windows API is accessible to C, GUI-wise there is absolutely nothing you couldn't do in C. My personal editor's source is 16k lines, if that is possible in assembler, it certainly works also in C. Give me one example of a GUI feature that can't be implemented in C...
Nonsense that is what you are making for me - "Give me one example of a GUI feature that can't be implemented in C..." - i told the another thing of! and very good example to illustrate my words is... PellesC IDE itself.... as IDE it is not too complicated (by comparing with modern homemade ide's )... more over, the interface had not much of changings since v6... , but the last release still is shipped with childish bugs.
-
And only once you got the gist on that one, then start programming for a GUI. That's a complete different issue all together, regardless of the OS. And regardless of what kind of library/framework you are using...
Ralf
Even so - C usage for GUI programming-POOR choice regardless any framework (exept some simple cases or very special requirements upon).
Well,...
Why are you then looking into programming with (Pelle's) C in the first place?
It's all a matter of what you are used to and what your goals/priorities are...
Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...
Ralf
-
Why are you then looking into programming with (Pelle's) C in the first place?
It's all a matter of what you are used to and what your goals/priorities are...
Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...
Ralf
It is simple - Frankie was the best at describing the situation:
If you want learn C just produce console programs.
I teach the first-year students to basic algorithmisation (programming for beginners)
If you want learn Win programming use WinAPI, masking the more or less complex mechanisms that are behind using a surrogate is not effective: What you need to learn is how things works, how messages rotates, how they are handled, etc. ;)
So do my colleagies after me (the students specialization is system programming).
More over...I long time worked at creation of the complex GUI apps.. though my interests shift into another topics at present ,i daresay know what i am talking about. Concerning my comment adressed to you - I just state very obvious (for me) thing- ANY bundle consisted from LOW level language+framework will concede (except some cases) to advanced one (consisted from HIGH level language +framework). It is due to the nature of the low level language (like C), do not mention of the C's peculiar design issues yet.
-
Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...
Ralf
Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?
-
Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...
Ralf
Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?
Popularity doesn't have anything to do with being useful. A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her. While at the bottom line, it doesn't really bring anything new to the table that is really providing a benefit...
Ralf
-
A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her.
Ralf
Ralf what''s really nice is that old and new languages are written in 'C' ;D ;D ;D ;D
Yes Os's, languages, base utilities and everything that have to be fast and efficient are written in 'C' ! ::) ::)
VB, C#, etc, that are very popular this days, are usefull because they lets you write your apps much faster, but not always more efficiently (please note the 'not always' before complain...).
Last the 'managed code' that has a lot of benefits (the intermediary language, the common language runtime, etc..,), has the biggest benefit of all: you cannot make thinks that are not allowed by the managed code platform: means that who created the platform can be lazy and simply block you before you get out of the path. But if a hole will ever be exposed ...
-
Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?
You put the thing in your head for reason unknown for me... i tell another thing of
-
Popularity doesn't have anything to do with being useful. A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her. While at the bottom line, it doesn't really bring anything new to the table that is really providing a benefit...
Ralf
your notion about "benefit" looks rather onelegged and outdated.
-
Ralf what''s really nice is that old and new languages are written in 'C' ;D ;D ;D ;D
Yes Os's, languages, base utilities and everything that have to be fast and efficient are written in 'C' ! ::) ::)
VB, C#, etc, that are very popular this days, are usefull because they lets you write your apps much faster, but not always more efficiently (please note the 'not always' before complain...).
Last the 'managed code' that has a lot of benefits (the intermediary language, the common language runtime, etc..,), has the biggest benefit of all: you cannot make thinks that are not allowed by the managed code platform: means that who created the platform can be lazy and simply block you before you get out of the path. But if a hole will ever be exposed ...
and what? ;D ;D ;D
My reasons are very simple - just try to bite them:
Even if you use most advanced framework there will be some work connected with interactions between the interface elements (more complicated interfaces result in more works of the such kind). That works are HIGH LEVEL works. and C is not well suited for.... (weaker typization, poor compiler messages, missed calling by reference, side effects, akward syntax, poor modularity, poor data encapsulation...).
Does not mention of the "efficiency" notion, wich changed since the time where typical apps user computer had 8mb RAM and 2gb HDD space ruled by 200 mhz CPU... ('twas just 20 years ago) :)
-
My reasons are very simple - just try to bite them:
Even if you use most advanced framework there will be some work connected with interactions between the interface elements (more complicated interfaces result in more works of the such kind). That works are HIGH LEVEL works. and C is not well suited for.... (weaker typization, poor compiler messages, missed calling by reference, side effects, akward syntax, poor modularity, poor data encapsulation...).
No reason to bite. ;D ;D
C exists to create such complex systems ;D ;D ;D
Does not mention of the "efficiency" notion, wich changed since the time where typical apps user computer had 8mb RAM and 2gb HDD space ruled by 200 mhz CPU... ('twas just 20 years ago) :)
20 years ago, HDD were at most 400Mb, and Athlon CPU was running 220MHz the software was not less efficient than now.
Then they understood that a GB HDD and GHz CPU can produce a lot of ... sprites, images and special effects (Oh yes than was necessary to have GPU's for 3D Hw acceleration...).
;D ;D ;D ;D ;D ;D ;D ;D ;D
-
No reason to bite. ;D ;D
C exists to create such complex systems ;D ;D ;D
;D ;D ;D ;D 'twas 20 years before , now just very simple-minded individuals will use C for end-user apps with rich interface without VERY serios reasons upon ;)
The example of the such REALLY BAD decision - Pelles C IDE. I wonder if there will be time when it will shrugg off its childish bugs ;)
Frankie, we really speak about quite different things.. :) :)
20 years ago, HDD were at most 400Mb, and Athlon CPU was running 220MHz the software was not less efficient than now.
Then they understood that a GB HDD and GHz CPU can produce a lot of ... sprites, images and special effects (Oh yes than was necessary to have GPU's for 3D Hw acceleration...).
;D ;D ;D ;D ;D ;D ;D ;D ;D
;D ;D ;D ;D ;D i spoke of typical Pentium I (i had such), but you forget to say that at present there is almost no need to use C for such tasks (exept some cases), moreover advanced frameworks itself prefer to make in high-level languages (Qt for example,and then make bindings to C)
-
was 20 years before , now just very simple-minded individuals will use C for end-user apps with rich interface without VERY serios reasons upon ;)
Be able to make advanced engineered products using trivial tools require superior capabilities, this seems a little bit contraddicting ;)
But nobody is saying that could be more 'productive' (not 'efficient') to write end-user apps using other more appropriate GUI tools..
The example of the such REALLY BAD decision - Pelles C IDE. I wonder if there will be time when it will shrugg off its childish bugs ;)
Frankie, we really speak about quite different things.. :) :)
Still can't understand why you waste your time about such a defective product... 8)
PellesC is a good non commercial product, so it is what it is... When Pelle has time he improve something...
You can like it or not, but it is so. :P
i spoke of typical Pentium I (i had such), but you forget to say that at present there is almost no need to use C for such tasks (exept some cases), moreover advanced frameworks itself prefer to make in high-level languages (Qt for example,and then make bindings to C)
But we are incurably good old time lovers .... ;D ;D ;D ;D ;D
-
Be able to make advanced engineered products using trivial tools require superior capabilities, this seems a little bit contraddicting ;)
But nobody is saying that could be more 'productive' (not 'efficient') to write end-user apps using other more appropriate GUI tools..
it may look like an arguments for cnoob... but i were quite aware that old Fortran (for the instance) was BOTH more efficient and productive for numerical calculations even 30 years ago. And even were aware of some reasons for it :D . so let us leave such stories for a childs or newbies...
Still can't understand why you waste your time about such a defective product... 8)
PellesC is a good non commercial product, so it is what it is... When Pelle has time he improve something...
You can like it or not, but it is so. :P
For it suits well for my student's EDUCATIONAL tasks (not of MINE) as I see them ... yet I deliberatory took into the account many factors (and trying competative ide's) before making the final decision... - wich is none of the obvious...
yet I told of the bags in Pelles C IDE (childish ones, REAL ones) and still I'm wondering what are you talking about... ;)
But we are incurably good old time lovers .... ;D ;D ;D ;D ;D
Agreed but I am still believing that the cnoob is worthу to get the just and impartial answer :)
-
I am still believing that the cnoob is worthу to get the just and impartial answer :)
I fully agree, I really didn't intended to influence anyone :), and this discussion for me was between serious and lazy, and, to be honest, maybe I would not even partecipate should I not have been mentioned. ;D
My opinion is that mentioned earlier (and that you quoted), and remain the same. ;D ;D ;D ;D
-
For a SUDOKU solver, I once used Python with TK GUI. It worked well; the exe package was pretty fat but OK. This changed when I wanted to add a grid generator - ah! ah!
Performance was terrible. Some members think that performance and efficiency are no more a problem - it is true when you use a computer as a display or a low thtoughput device, but if you use it as a calculator, it may be very different.
For my grid generator, I had to add a C DLL to my Python...
And now, I agree with most members here. With C, we have a chance of plenty of powerfull libaries (Intel IPP, libharu,...) - and the windows API should be the right choice for the GUI, but it is not. The many reasons come from Microsoft. Everything is possible, but have you ever tried to use a blue button? Too much effort is required: Microsoft do not like developpers.
So, I decided to add to the Win32(64) API a simple layer with the following goals:
- hide most of the stuff
- provide a structured architecture (thanks to callback functions)
- provide an object architecture (inheritance)
- provide scalability (zooming)
- do not manage the application data: let the application programmer do that
- do not draw simple things: let the application programmer do that
- keep everything possible
It is called SGL and within few weeks I hope it will be available.
An example is already posted here http://forum.pellesc.de/index.php?topic=6656.0 (http://forum.pellesc.de/index.php?topic=6656.0) may 19th reply.
-
I don't really understand the discussion here, but with the right support code, in-memory dialogs are easy to code and use. Note that none of the following code has been thoroughly tested, and that I had to remove a lot of the commenting to keep the size below the post limit.
imdialog.c:
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>
#include <richedit.h>
#include <commctrl.h>
//---------------------------------------------------------------------
// This module provides a quick and easy method of creating a dialog
// box template in allocated memory and creating a modal or modeless
// dialog from the template.
//
// The dialog box template consists of a single DLGTEMPLATE structure
// followed by three or four variable-length arrays, followed by zero
// or more DLGITEMTEMPLATE structures each followed by three variable-
// length arrays. The DLGTEMPLATE structure and the associated arrays
// define the dialog window, and the DLGITEMTEMPLATE structures and
// the associated arrays define the controls in the dialog.
//
// The variable-length arrays consist of WORD (16-bit) elements.
//
// The first three arrays following the DLGTEMPLATE structure specify
// the menu, class, and title for the dialog. The three arrays
// following each DLGITEMTEMPLATE structure specify the class, title,
// and creation data for the control. Each of these arrays will have
// at least one element, and the system will interpret the contents
// of the array based on the value of the first element. For the
// dialog menu, class, and title arrays, and the control creation
// data array, if the first element is zero then the array is
// effectively empty and there are no other elements. For the dialog
// menu and class arrays, and the control class and title arrays, if
// the first element is FFFFh then the second element contains the
// ordinal value of a resource or a predefined class, and the array
// contains no other elements. For the dialog menu, class, and title
// arrays, and the control class and title arrays, if the first
// element is any value other than zero or FFFFh then the array is
// assumed to be a null-terminated Unicode string. Depending on the
// array, this Unicode string can specify the name of a menu resource,
// a registered class, the dialog title, or the initial text for a
// control. For the control creation data array, if the first element
// is non-zero then it contains the length, in bytes, of the creation
// data that follows. The fourth array following the DLGTEMPLATE
// structure, which the system expects to be present when the dialog
// style includes DS_SETFONT, specifies the font point size value in
// the first element, followed by the name of the typeface as a null-
// terminated Unicode string.
//
// This implementation does not permit a menu or class specification
// for the dialog, or creation data for the controls.
//
// The DLGTEMPLATE and DLGITEMTEMPLATE structures must be aligned
// on a DWORD (32-bit) boundary. The variable-length arrays that
// follow the structures must start on a WORD boundary, but with
// WORD-size elements and the structure sizes and alignment
// requirements, this should be automatic.
//---------------------------------------------------------------------
#ifndef TEMPLATE_BUFFER_KB
#define TEMPLATE_BUFFER_KB 20
#endif
LPDLGTEMPLATE g_lpdt;
LPWORD g_lpw;
void GenUString( LPCSTR lpAnsiString )
{
int lenWstr;
if(lpAnsiString)
{
lenWstr = MultiByteToWideChar( CP_ACP,
MB_PRECOMPOSED,
lpAnsiString,
-1,
(LPWSTR)g_lpw,
0 );
g_lpw += MultiByteToWideChar( CP_ACP,
MB_PRECOMPOSED,
lpAnsiString,
-1,
(LPWSTR)g_lpw,
lenWstr );
}
else
{
g_lpw += 1;
}
}
INT_PTR CreateModalDialog( HWND hwndParent,
DLGPROC lpDialogProc,
LPARAM dwInitParam )
{
INT_PTR nResult;
GlobalReAlloc( (HGLOBAL)g_lpdt,(int)g_lpw - (int) g_lpdt + 1,0 );
nResult = DialogBoxIndirectParam( GetModuleHandle(NULL),
g_lpdt,
hwndParent,
lpDialogProc,
dwInitParam );
GlobalFree( g_lpdt );
return nResult;
}
HWND CreateModelessDialog( HWND hwndParent,
DLGPROC lpDialogProc,
LPARAM dwInitParam )
{
HWND h;
GlobalReAlloc( (HGLOBAL) g_lpdt,(int)g_lpw - (int)g_lpdt + 1, 0 );
h = CreateDialogIndirectParam( GetModuleHandle(NULL),
g_lpdt,
hwndParent,
lpDialogProc,
dwInitParam );
GlobalFree( g_lpdt );
return h;
}
void Dialog( LPCSTR lpTitle,
DWORD style,
short x,
short y,
short cx,
short cy,
short pointSize,
LPCSTR lpTypeFace,
short controlCount )
{
g_lpdt = GlobalAlloc( GMEM_FIXED | GMEM_ZEROINIT,
1024 * TEMPLATE_BUFFER_KB );
g_lpdt->style = style;
g_lpdt->cdit = controlCount;
g_lpdt->x = x;
g_lpdt->y = y;
g_lpdt->cx = cx;
g_lpdt->cy = cy;
g_lpw = (LPWORD) (g_lpdt + 1);
g_lpw += 1;
g_lpw += 1;
GenUString(lpTitle);
if( pointSize && lpTypeFace )
{
g_lpdt->style |= DS_SETFONT;
*g_lpw = pointSize;
g_lpw += 1;
GenUString( lpTypeFace );
}
}
void Control( LPCSTR lpClass,
LPCSTR lpTitle,
DWORD style,
short x,
short y,
short cx,
short cy,
short resourceID,
WORD controlID )
{
LPDLGITEMTEMPLATE lpdit;
unsigned int ui;
ui = (ULONG)g_lpw;
ui += 3;
ui &= -4;
g_lpw = (LPWORD)ui;
lpdit = (LPDLGITEMTEMPLATE) g_lpw;
lpdit->style = WS_CHILD | WS_VISIBLE | style;
lpdit->x = x;
lpdit->y = y;
lpdit->cx = cx;
lpdit->cy = cy;
lpdit->id = controlID;
g_lpw = (LPWORD)(lpdit + 1);
GenUString( lpClass );
if(resourceID)
{
*g_lpw = 0xffff;
g_lpw += 1;
*g_lpw = resourceID;
g_lpw += 1;
}
else
{
GenUString( lpTitle );
}
g_lpw += 1;
}
void PushButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "BUTTON",
lpCaption,
BS_PUSHBUTTON | style,
x,
y,
cx,
cy,
0,
controlID );
}
void DefPushButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "BUTTON",
lpCaption,
BS_DEFPUSHBUTTON | style,
x,
y,
cx,
cy,
0,
controlID );
}
void AutoCheckBox( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "BUTTON",
lpCaption,
BS_AUTOCHECKBOX | style,
x,
y,
cx,
cy,
0,
controlID );
}
void AutoRadioButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "BUTTON",
lpCaption,
BS_AUTORADIOBUTTON | style,
x,
y,
cx,
cy,
0,
controlID );
}
void GroupBox( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "BUTTON",
lpCaption,
BS_GROUPBOX | style,
x,
y,
cx,
cy,
0,
controlID );
}
void EditText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "EDIT",
lpText,
style,
x,
y,
cx,
cy,
0,
controlID );
}
void LText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "STATIC",
lpText,
SS_LEFT | style,
x,
y,
cx,
cy,
0,
controlID );
}
void RText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "STATIC",
lpText,
SS_RIGHT | style,
x,
y,
cx,
cy,
0,
controlID );
}
void CText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "STATIC",
lpText,
SS_CENTER | style,
x,
y,
cx,
cy,
0,
controlID );
}
void ListBox( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID)
{
Control( "LISTBOX",
0,
style,
x,
y,
cx,
cy,
0,
controlID );
}
void ComboBox( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "COMBOBOX",
0,
style,
x,
y,
cx,
cy,
0,
controlID );
}
void ScrollBar( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( "SCROLLBAR",
0,
style,
x,
y,
cx,
cy,
0,
controlID );
}
//--------------------------------------------------------------
// This for Rich Edit version 2/3, LoadLibrary("RICHED20.DLL");
//--------------------------------------------------------------
void RichEdit( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID )
{
Control( RICHEDIT_CLASS,
0,
style,
x,
y,
cx,
cy,
0,
controlID );
}
void InitCommonCtrls( void )
{
INITCOMMONCONTROLSEX iccex = {sizeof(INITCOMMONCONTROLSEX),
ICC_ANIMATE_CLASS | \
ICC_BAR_CLASSES | \
ICC_COOL_CLASSES | \
ICC_DATE_CLASSES | \
ICC_HOTKEY_CLASS | \
ICC_INTERNET_CLASSES | \
ICC_LISTVIEW_CLASSES | \
ICC_PAGESCROLLER_CLASS | \
ICC_PROGRESS_CLASS | \
ICC_TAB_CLASSES | \
ICC_TREEVIEW_CLASSES | \
ICC_UPDOWN_CLASS | \
ICC_USEREX_CLASSES | \
ICC_WIN95_CLASSES };
InitCommonControlsEx( &iccex );
}
imdialog.h:
void GenUString( LPCSTR lpAnsiString );
INT_PTR CreateModalDialog( HWND hwndParent,
DLGPROC lpDialogProc,
LPARAM dwInitParam );
HWND CreateModelessDialog( HWND hwndParent,
DLGPROC lpDialogProc,
LPARAM dwInitParam );
void Dialog( LPCSTR lpTitle,
DWORD style,
short x,
short y,
short cx,
short cy,
short pointSize,
LPCSTR lpTypeFace,
short controlCount );
void Control( LPCSTR lpClass,
LPCSTR lpTitle,
DWORD style,
short x,
short y,
short cx,
short cy,
short resourceID,
WORD controlID );
void PushButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void DefPushButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void AutoCheckBox( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void AutoRadioButton( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void GroupBox( LPCSTR lpCaption,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void EditText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void LText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void RText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void CText( LPCSTR lpText,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void ListBox( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID);
void ComboBox( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void ScrollBar( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void RichEdit( LPCSTR junk,
DWORD style,
short x,
short y,
short cx,
short cy,
WORD controlID );
void InitCommonCtrls( void );
simple.c:
#include <windows.h>
#include <richedit.h>
#include <commctrl.h>
#include "imdialog.h"
INT_PTR CALLBACK DialogProc( HWND hwndDlg,
UINT uMsg,
WPARAM wParam,
LPARAM lParam )
{
switch ( uMsg )
{
case WM_INITDIALOG :
return 1;
case WM_COMMAND :
if ( wParam == IDCANCEL || wParam == 101 )
EndDialog( hwndDlg, 0 );
break;
case WM_CLOSE :
EndDialog( hwndDlg, 0 );
}
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd)
{
Dialog("Test",WS_OVERLAPPED|WS_SYSMENU|DS_CENTER,0,0,100,80,10,"comic sans ms",2);
EditText("",WS_BORDER|WS_TABSTOP,10,10,77,10,100);
PushButton("OK",WS_TABSTOP,29,40,40,10,101);
CreateModalDialog(0,DialogProc,0);
exit(0);
}
-
For me, and as far as GUI programming is concerned, the most obvious inconvenience is that C does not directly support OOP (GUI and OOP go hand by hand for decades). That's also IMO the main problem with Win32 API. However, frameworks like GTK+ are implemented in a fully OO mindset, thus overcoming most of the potential inconveniences when the GUI gets too complicated.
GTK+ and its dependencies are kind of a "beast", but they provide everything (or almost everything) you expect from a modern GUI framework (for example, it even lets you style your widgets using css if you choose so). Its learning curve is not harder than Win32 API's and (always IMO) it's a much more fun and productive framework. Glade can also prove quite handy as a RAD tool for the initial design of the GUI.
-
Many questions for a simple GUI projects in C.
Win32 is almost perfect, but...
I tried to fill the gap for casual programmers
with SGL - a simple layer on top on Win32 as I told
on may 21th.
Now it is released, see here :
http://forum.pellesc.de/index.php?topic=6788.0 (http://forum.pellesc.de/index.php?topic=6788.0)
As told by mifg1, "GUI and OOP go hand by hand for decades".
That is why SGL is somewhat OOP, ie. :
- a widget can be duplicated,
- callback functions are defined per object (not per Window class).
And more: SGL does not interfere with your data.