[ann] WIN32GUI - v1.5.1 released

[John Torjo]

Hi all,

Version 1.5.1 of WIN32GUI has been released.
Get it from: http://www.torjo.com/win32gui/


Win32GUI is a FREE generic library for GUI programming on the Windows
platform, developed in parallel to "Win32 GUI Generics" column in
C/C++ Users Journal.

It is portable, and currently can be compiled with gcc3.3+, vc7.1,
como 4.3.4+ and vc8 (experimental)

Features:
* (v1.5) tooltips. So easy to use, and they work for *menus* too!
* (v1.5) bitmap buttons (they can be set at dialog design time)
Works for push-like check-boxes and radio button as well
You can easily set "hot tracking" for a certain bitmap button
And, they work on MessageBox too!!!
* (v1.5) added hyper_links at dialog design time
* (v1.5) lite HTML class (also, you can set at design time)
* (v1.5) tab dialogs - and you can also set them at dialog design time
(much better than MFC property pages!)
* (v1.5) message reflection
* dialog design time splitters
* easy to create a dialog on a dialog
* thread-safe
* (v1.4+) save_dlg - true binding of your data to UI controls!!!
* very easy to subclass controls/dialogs
* very easy to deal with windows generically (finding out all
children/windows
of a given type, finding out windows that match a certain criteria)
* GUI RAII (as a window gets created on screen, its C++ object gets
created; as it gets destroyed from screen, the C++ object gets
destroyed as well)
* revolutionary simple event handling (no message maps)
* thin yet powerful wrappers over all standard controls
(button,edit,...toolbar,rebar,etc.)
* easy menu command manipulation (menu commands that behave like
checkboxes/radio buttons)
(you'll find examples in sub-directory examples/menus)
* tray window

And much more!

And last but not least, 40+ examples and counting!

Best,
John

 

[Roland Pibinger]

Version 1.5.1 of WIN32GUI has been released.
Get it from: http://www.torjo.com/win32gui/


Win32GUI is a FREE generic library for GUI programming on the Windows
platform, developed in parallel to "Win32 GUI Generics" column in
C/C++ Users Journal.

Just out of curiosity ...
- Why do you write a library for the legacy Windows-API?
- Why don't you use "modern" approaches like XUL, XAML, ...?

Best regards,
Roland Pibinger

 

[John Torjo]

Just out of curiosity ...
- Why do you write a library for the legacy Windows-API?

I wouldn't call it legacy. It's quite a nice piece of work, with the
right wrapper on top of it

- Why don't you use "modern" approaches like XUL, XAML, ...?

Indeed "modern"
As I understand, XUL only allows for scripting, and its event model is
quite simplistic.

(note: I'll touch the event handling in the docs quite these days - so
check it out
Also, stay tuned for the Dec '04 issue of CUJ - you'll be pleasently
surprised.)

As for XAML, just a new M$ "technology".
There are a *very* few things I like about it - painting mostly. Other
than that, just another high-level specification (a little better than
..rc files) - but quite unflexible, if you ask me.
And from what I've read, I really don't like the way it handles
events. I failed to see how can you actually listen to all events that
get triggered by an application.

But most of all, I hate "Avalon", since it deprecates Standard C++.


I will certainly deal with Longhorn, when it comes out

Best,
John


John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[Kelsey Bjarnason]

[snips]

Win32GUI is a FREE generic library for GUI programming on the Windows
platform...

It is portable...

So which is it? Is it for Windows only, or is it portable? Good; where
can I get it for, say, X under Linux? Or the Amiga?

 

[Graeme Prentice]

Thanks,John,It's an excellent job!
IMO,Win32 GUI is the most elegant GUI lib so far.

Do you mean the C++ code and dezign is elegant or the user interface
stuff is elegant. How does it compare with WTL, Microsoft's Win32 C++
template GUI library?

Graeme

 

[Paul Mensonides]

[snips]

Win32GUI is a FREE generic library for GUI programming on the Windows
platform...

It is portable...

So which is it? Is it for Windows only, or is it portable? Good;
where can I get it for, say, X under Linux? Or the Amiga?

Portability can also mean from compiler to compiler or from one OS version to
another.

Regards,
Paul Mensonides

 

[Ioannis Vranos]

Hi all,

Version 1.5.1 of WIN32GUI has been released.
Get it from: http://www.torjo.com/win32gui/

I do not want to stop your effort, however doesn't .NET already do the
same things?


Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
Win32.

Win32 will not be developed any more and will remain for compatibility
purposes, the same way Win16 is today.

 

[John Torjo]

Do you mean the C++ code and dezign is elegant or the user interface
stuff is elegant. How does it compare with WTL, Microsoft's Win32 C++

I would say both - but that definitely makes me biased

template GUI library?

So I gather you haven't read CUJ

I guess you can compare it yourself. As a matter of fact, I'm working
on the docs right now
(which you can get from http://sf.net/projects/win32gui/).
I'm posting docs versions daily - and welcome all feedback.

Also, you can check out the examples to get you started - there's 41
of them so far.

Best,
John


John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[20thCenturyBoy]

I do not want to stop your effort, however doesn't .NET already do the
same things?


Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
Win32.

Win32 will not be developed any more and will remain for compatibility
purposes, the same way Win16 is today.

Win32 will be around for a long time. Not everyone will move to
Longhorn immediately. There are some things you can't do easily in
..NET today.

 

[Ioannis Vranos]

Win32 will be around for a long time. Not everyone will move to
Longhorn immediately. There are some things you can't do easily in
.NET today.

Win32 will be around for a long time, for backwards compatibility. All
newer facilities will be provided in WinFX/.NET only.

 

[John Torjo]

I do not want to stop your effort, however doesn't .NET already do the
same things?

And by the way, could you please point me to how .net + threading +
GUI interact?
Since it seems to me that they interact kind of badly...

On my small C# project I made, it seems that if I do something like

static void other_thread1() {
g_form.txt.Text = "other thread -1";
}


and, make sure I catch the text_changed event:

private void changed_txt(object sender, System.EventArgs e)
{
int i = 0;
}

I catch this in the context of the other thread, as opposed to the
main thread (which is what I would expect). Thus, I need to make my
whole class thread-safe, just because I want to manipulate one of its
controls from another thread.

This strikes me as very bad, compared to Win32 programming, where all
messages are sent on the context of the thread that created the
control, not on the context of the caller.

Best,
John

John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[John Torjo]

I do not want to stop your effort, however doesn't .NET already do the
same things?

I would say that compared to .net, the overhead is much smaller. You
don't need .net to be installed in your machine (what about making
install kits?). Not to say that I find .net very inflexible. And it
seems I'm not the only one...

As the other thread (CLI draft) showed, the C++/CLI does have a while
until it will catch on, etc. win32gui works *now*. Not to say that I
intend to provide advanced subclassing, which as far as I know - is
quite impossible under the .net.

Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
Win32.

I've read about it.

Win32 will not be developed any more and will remain for compatibility
purposes, the same way Win16 is today.

That remains to be seen. From what I've read, I see *no* advantages of
using Avalon, other the GDI.

If Avalon proves to catch on, there won't be anything to stop me from
porting win32gui to it In fact I might consider allowing the user
of the library to choose between using or not using Avalon (of course,
this is just a thought, for now)

Best,
John


John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[Ioannis Vranos]

And by the way, could you please point me to how .net + threading +
GUI interact?
Since it seems to me that they interact kind of badly...

On my small C# project I made, it seems that if I do something like

static void other_thread1() {
g_form.txt.Text = "other thread -1";
}


and, make sure I catch the text_changed event:

private void changed_txt(object sender, System.EventArgs e)
{
int i = 0;
}

I catch this in the context of the other thread, as opposed to the
main thread (which is what I would expect). Thus, I need to make my
whole class thread-safe, just because I want to manipulate one of its
controls from another thread.

I do not understand C#, so can you make it C++?


In C++ with "managed extensions" the threads go like this:


__gc class SomeClass
{
// ...

public:
void SomeMethod();
};

// ...

SomeClass *obj= new SomeClass;



Thread *thread1= new Thread( (new ThreadStart(obj,
&SomeClass::SomeMethod) );


thread1->Start();

 

[Glen Low]

And by the way, could you please point me to how .net + threading +

GUI interact?
Since it seems to me that they interact kind of badly...

On my small C# project I made, it seems that if I do something like

static void other_thread1() {
g_form.txt.Text = "other thread -1";
}


and, make sure I catch the text_changed event:

private void changed_txt(object sender, System.EventArgs e)
{
int i = 0;
}

I catch this in the context of the other thread, as opposed to the
main thread (which is what I would expect). Thus, I need to make my
whole class thread-safe, just because I want to manipulate one of its
controls from another thread.

In your other thread code, you need to ask the form to InvokeAsync a
delegate you provide. If the delegate is fairly arm's length, and can
be fired and then forgotten, you don't need any other thread
synchronization mechanisms. Also, the text changed event executes in
the context of the form's thread not your other thread.

In any case, the point is moot. Win32 uses the same mechanism; each
thread has its own message queue and only in the context of the main
UI thread is it safe to do UI stuff. If another thread needs to change
the text of a control or something more complicated, you do a
PostMessage to the UI thread queue, which is equivalent to
InvokeAsync. No doubt if you've properly wrapped the message passing
in your library, then your library has cleaner syntax than .NET --
however, when you need to get information back from a control e.g. the
text of a control, when you're in a different thread you would either
have to code a wait or get the control to PostMessage you back, so
there's that thread safety issue again.

Mac OS X is similar. You have a main GUI thread; if another thread
needs to muck around with the GUI, you have to post a message to it. I
don't know if any GUI system freely allows any thread to perform GUI
operations.

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

 

[John Torjo]

That remains to be seen. From what I've read, I see *no* advantages of
using Avalon, other the GDI.

That was a little strong...

There are a lot of good things about Avalon, I just find a quite too
"high level" (that is, it makes me wish for a lower level API). It's
still too early to tell...
Besides, I'd really like it if I could do CLI/C++ coding for Avalon -
which at this time I don't think is possible.

Best,
John

 

[Seanairt]

But most of all, I hate "Avalon", since it deprecates Standard C++.

How can it possibly "deprecate" the standard? Further, wouldn't that mean
their current work with VC 7.x is time/money wasted? They've put all this
work into making the current series of the IDE their most
standard-compliant yet. Indeed, this is the chief reason I bought 7.1. I
rarely code against .Net, having a large # of projects coded against MFC
and/or ATL.
IOW, I realize how they may encourage (and push and prod) you into coding
against the .Net/Avalon sctuff, but wouldn't the standard still be there
underneath (and indeed, supporting) it all?

 

[Ioannis Vranos]

That was a little strong...

There are a lot of good things about Avalon, I just find a quite too
"high level" (that is, it makes me wish for a lower level API). It's
still too early to tell...
Besides, I'd really like it if I could do CLI/C++ coding for Avalon -
which at this time I don't think is possible.

"Avalon" (a subset of WinFX) will be equally accessible from all .NET
languages, especially C++/CLI, so I do not know what you mean exactly
with the above.

 

[John Torjo]

And by the way, could you please point me to how .net + threading +
GUI interact?
Since it seems to me that they interact kind of badly...

On my small C# project I made, it seems that if I do something like

static void other_thread1() {
g_form.txt.Text = "other thread -1";
}


and, make sure I catch the text_changed event:

private void changed_txt(object sender, System.EventArgs e)
{
int i = 0;
}

I catch this in the context of the other thread, as opposed to the
main thread (which is what I would expect). Thus, I need to make my
whole class thread-safe, just because I want to manipulate one of its
controls from another thread.

I do not understand C#, so can you make it C++?


In C++ with "managed extensions" the threads go like this:
[...]

That was not the point. The point is: the context in which you catch
notifications (that is, in the thread that created the window, or in
the thread they occur?)

In other words:
I'm in another thread, and do this:

g_form.txt.Text = "other thread -1";

I would expect to catch the text_changed notification in the main
thread (the thread that created g_form).

Best,
John


John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[John Torjo]

In your other thread code, you need to ask the form to InvokeAsync a

how can I invoke async:

g_form.txt.Text = "other thread -2";

I'm not sure I follow...

delegate you provide. If the delegate is fairly arm's length, and can
be fired and then forgotten, you don't need any other thread
synchronization mechanisms. Also, the text changed event executes in
the context of the form's thread not your other thread.

that's what I hoped for. But the 'Call Stack' showed me something
else...


WindowsApplication1.Form1.changed_txt(sender =
{System.Windows.Forms.TextBox}, e = {System.EventArgs}) Line 123 C#
[<Non-user Code>]
WindowsApplication1.Form1.other_thread1() Line 30 C#

In any case, the point is moot. Win32 uses the same mechanism; each

If that were true... Which it seems not.

If I'm correct, Win32 is much better (see below)

thread has its own message queue and only in the context of the main
UI thread is it safe to do UI stuff. If another thread needs to change
the text of a control or something more complicated, you do a
PostMessage to the UI thread queue, which is equivalent to

In fact, you can still do SendMessage (check the SDK) between threads.
The OS will change the context to the thread that created the window,
wait for it to process this, and then return.

In fact, I've made a small sample to show how easy it works using
win32gui:
http://www.torjo.com/code/multiple_threads3.zip

InvokeAsync. No doubt if you've properly wrapped the message passing
in your library, then your library has cleaner syntax than .NET --
however, when you need to get information back from a control e.g. the
text of a control, when you're in a different thread you would either
have to code a wait or get the control to PostMessage you back, so
there's that thread safety issue again.

Nope. You can, again, use SendMessage (check out the code)
For instance:
w->text("some text");
or
std::string = w->text();
will work correctly, no matter on which thread w was created on.

Mac OS X is similar. You have a main GUI thread; if another thread
needs to muck around with the GUI, you have to post a message to it. I
don't know if any GUI system freely allows any thread to perform GUI
operations.

And yet, Win32 seems to just fit the bill....


Best,
John


John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
+ bitmap buttons, tab dialogs, hyper links, lite html

 

[Glen Low]

how can I invoke async:

g_form.txt.Text = "other thread -2";

I'm not sure I follow...

Define a method and delegate

void ChangeText (TextBox box, String newText) { box.Text = newText; }
public delegate void ChangeTextDelegate (TextBox box, String newText);

then in your other thread, do

g_form.Invoke (new ChangeTextDelegate (ChangeText), new object []
{box, newText});

(Sorry about misleading you about the InvokeAsync, that was a holdover
in my gray cells from the old WFC days, it should be just Invoke...
BTW, all this works equivalently in Managed C++, so it's still on
topic...)

Admittedly the syntax is clunky, especially for simple methods. But if
your method needs to do a lot of work the syntactic overhead is not
much, since you would have to do the equivalent with PostMessage and
packing and unpacking the arguments yourself.

that's what I hoped for. But the 'Call Stack' showed me something
else...


WindowsApplication1.Form1.changed_txt(sender =
{System.Windows.Forms.TextBox}, e = {System.EventArgs}) Line 123 C#
[<Non-user Code>]
WindowsApplication1.Form1.other_thread1() Line 30 C#

Ooo.. that would mean that you made the text change directly in your
non-GUI thread, a definite no-no.

In fact, you can still do SendMessage (check the SDK) between threads.
The OS will change the context to the thread that created the window,
wait for it to process this, and then return.

Yes you can, but this hides the latency behind the SendMessage. When
your other thread calls SendMessage, it blocks as the GUI does its
work, and also waits for the function return. In a typical threaded
design, you want the other thread to continue to do work while the GUI
updates e.g. if the other thread is reading a giant file from the
network or busy rendering something. Excessive use of SendMessage then
causes both threads to be serialized, and you might as well just use
one thread instead of two.

Therefore, a lot of developers who use Win32 strictly seperate GUI and
non-GUI functionality in their threads. Then if the non-GUI thread
needs to get the GUI to do something, they define a custom message on
the GUI thread that does all of what they want, then they PostMessage
the custom message to it to get it to work. The thread boundaries are
much clearer and little serialization occurs, the GUI remains
responsive and the non-GUI thread works at almost full speed.

Now this pattern (I wonder if there is a GOF term for it) is almost
exactly the same as the .NET delegate + control invoke async. Except
that the .NET version does the argument packing and custom message
number allocation for you.

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com