GUI Programming for Windows

T

TGOS

How do C programmers create a good-looking Windows GUI?

Using a cross-platform API would be cool, but gtk+ is out of question,
as it does not look really native on Windows (there is a "skin" that
makes it pretty native, but that it's like using Java Swing: Looks close
to native, but not really native and doesn't "feel" native to the user).

Using the Win32 API directly is *painful*.

wxWidgets is cool, but it's only C++. Qt is also very native from the
feeling, but also only C++.

Further it would be great if I don't have to "program" the GUI. In the
age of GUI editors, creating a GUI programatically will almost always
lead to a sub-optimal result. 90% of all GUIs in MacOS X are created
with the Interface Builder, a drag'n drop GUI editor (the easiest I
know) and the results are gigantic.

MS Visual C++ has such an editor, but it creates MFC Code, this is C++
again.

Regarding the choice of programming language: I like OO languages, I
really do. But I think C++ sucks, so does Smalltalk and C# (out of
question anyway, cause user must have .NET Framework installed, that is
not even part of WinXP unless you download the 21 MB and install it).

What I like is Java (out of question, JRE is equal to .NET Framework,
again not installed by default and a big download) and Obective-C
(almost only used for MacOS X. GCC can compile it, but GUI design
outside of MacOS is ugly, as the GUI looks worse than Motif).

For most tasks OO is overkill and C cuts it quice nicely. However what
if you need a GUI? Isn't there a programmer friendly API for creating
native Windows in plain C, that is nicer than the Win32 API, that is
free and maybe portable (whereby this is not really a demand)?

Any ideas?
 
B

Ben Pfaff

TGOS said:
How do C programmers create a good-looking Windows GUI?

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.
 
T

TGOS

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

Yes, it is such a narrow topic, that it does not include Linux kernel
linked lists, still you answered that question. Just for the records,
your honor.
 
J

Joona I Palaste

Yes, it is such a narrow topic, that it does not include Linux kernel
linked lists, still you answered that question. Just for the records,
your honor.

IIRC the message about Linux kernel linked lists was about standard C.
The code just happened to be in the source of the Linux kernel. So
answering it was well within the topic of comp.lang.c.
 
J

jacob navia

Within your message you say you try to avoid the Win32 API.
Actually, this API is very easy to understand and use, and it
has several advantages over any framework.

1: It has remained stable since at least 15 years. You can compile
today a program written for windows 3.1 wth minimal changes after
more than 10 years
2: Since all windows is based on it, it is unlikely to change, and
it is a very stable base to build. Take, for instance, the IDE of
the lcc-win32 compiler system. It was written for windows 3.1 and
has remained the same in all this years of development.

To master the API is just mastering some general principles and
then just reading the docs. For an introduction, read the windows
part of the lcc-win32 tutorial at

http://www.cs.virginia.edu/~lcc-win32


jacob
 
J

Joona I Palaste

jacob navia said:
Within your message you say you try to avoid the Win32 API.
Actually, this API is very easy to understand and use, and it
has several advantages over any framework.

It's also off-topic for comp.lang.c.
 
F

Flash Gordon

jacob said:
Within your message you say you try to avoid the Win32 API.
Actually, this API is very easy to understand and use, and it
has several advantages over any framework.

1: It has remained stable since at least 15 years. You can compile
today a program written for windows 3.1 wth minimal changes after
more than 10 years

So what about the additions in Win32s, and the additions after that in
Win95...

A small quote from the Visual Studio help where it is talking about
porting and upgrading...

The key areas of 16-bit code affected by the changes are:
o Window procedure declarations
o Near and far type declarations
o Data types
o Messages
o Calls to API functions
o WinMain function

Other bits it says are that you have to examine every usage or the WORD
type to see if it should be something else.

Another quote:
But you may need to revise your code if you call API functions in any
of the following categories:
o Graphics functions
o Functions accessing "extra" window data
o MS-DOS system calls
o File Operations
o Far-pointer functions
o Functions getting list and combo box contents

Not forgetting the code that was broken by Windows XP SP2
2: Since all windows is based on it, it is unlikely to change, and
it is a very stable base to build.

Well, MS seem to think there are more potability problems between Win
3.x and 32 bit windows than you do.
> Take, for instance, the IDE of
the lcc-win32 compiler system. It was written for windows 3.1 and
has remained the same in all this years of development.

So you only use the simple stuff. There is a lot that has changed as
well, and if you want to take advantage of newer versions there is a lot
of stuff added.
To master the API is just mastering some general principles and
then just reading the docs. For an introduction, read the windows
part of the lcc-win32 tutorial at

http://www.cs.virginia.edu/~lcc-win32

All of which is off topic. Talk about Windows stuff in Windows groups or
your own groups. This group is for standard C not misinformation about
Windows (which I use regularly and for which I have an MSDN
subscription) nor for pushing your compiler.
 
M

Mark McIntyre

Yes, it is such a narrow topic, that it does not include Linux kernel
linked lists,

Actually, it does include linked lists. For the record.

And by the way, you may want to consider how foolish it is to get upset
when people point out you're in the wrong queue. Its not their fault you
stood at the wrong bus-stop.
 
M

Mark McIntyre

Posting falsely attributed quotes to usenet is as good a way as any to
recieve an AUP breach complaint to your ISP.
 
M

Mark McIntyre

jacob navia wrote:

So what about the additions in Win32s, and the additions after that in
Win95...

to be fair, Win32s was released over 12 years ago, and the Win95 more than
a decade back, which marries with JN's dates. Since then the core API has
been pretty stable. Many Win31 programmes will compile relatively easily
under Win32. But this is all offtopic here.
All of which is off topic. Talk about Windows stuff in Windows groups or
your own groups.

Absolutely. But since its offtopic here, its not really fair to make
postings criticizing JN's views on Win32, especially since one's own view
may also be inaccurate and can't really be corrected due to lack of
topicality..... or something....
 
J

Joona I Palaste

Actually, it does include linked lists. For the record.
And by the way, you may want to consider how foolish it is to get upset
when people point out you're in the wrong queue. Its not their fault you
stood at the wrong bus-stop.

Had the message TGOS mentioned been titled "C program linked list help!"
or even "Homework linked list help!", no one would have batted an
eyelid. But because of its title, people like TGOS see the words "Linux
kernel" and immediately scream "off topic!" without bothering to check
if the question, and its answer, actually include or even concern
system-specific code.
 
K

Kenny McCormack

Posting falsely attributed quotes to usenet is as good a way as any to
recieve an AUP breach complaint to your ISP.

Removing one's pants, then carefully reaching back and giving it a good
twist is as good a way as any to remove a stick from one's ass.
 
C

CBFalconer

Mark said:
.... snip ...

Actually, it does include linked lists. For the record.

And by the way, you may want to consider how foolish it is to get
upset when people point out you're in the wrong queue. Its not
their fault you stood at the wrong bus-stop.

I can remember wishing I had been told that early and often, when I
had to ride 30 miles in the wrong direction on the wrong train, and
was missing an assignation. Haven't missed any of those lately
though, which may be connected with the lack of assignations.
 
C

CBFalconer

Kenny said:
Removing one's pants, then carefully reaching back and giving it
a good twist is as good a way as any to remove a stick from one's
ass.

However if ones large gray long-eared four-footed animal really
wants the stick, and is in a bad mood, the above action is likely
to result in balefully bitten buttocks. I see no upside. I put
this action in the same class as using gets().
 
T

TGOS

IIRC the message about Linux kernel linked lists was about standard C.

No, it was about how these linked list works and these lists are not
part in any C standard or part of any C library, they are part of the
Linux kernel and the only relevance to this group is that they are
written C; so is the win32 API or GTK.
 
J

Joona I Palaste

No, it was about how these linked list works and these lists are not
part in any C standard or part of any C library, they are part of the
Linux kernel and the only relevance to this group is that they are
written C; so is the win32 API or GTK.

They might be part of the Linux kernel, but the point is, THEY - ARE -
WRITTEN - IN - STANDARD - C. A lot of the Linux kernel is system-
specific code, but THAT - PARTICULAR - PART was 100% standard C. Did you
even READ the code?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp
 
T

TGOS

They might be part of the Linux kernel, but the point is, THEY - ARE -
WRITTEN - IN - STANDARD - C. A lot of the Linux kernel is system-
specific code, but THAT - PARTICULAR - PART was 100% standard C. Did you
even READ the code?

Ah, sorry, I forgot that the Win32 API or GNOME are written in Ancient
Traditional C-.
 
J

Joona I Palaste

Ah, sorry, I forgot that the Win32 API or GNOME are written in Ancient
Traditional C-.

The situation with Win32 API and GNOME is the exact same. Parts of them
are in standard C, other parts in system-specific code.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top