Does c++ have an uniform class library?

[IR]

int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?

Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.


Although it is a bad design IMHO, I often saw windows that could be
used for multiple tasks, some of these tasks not requiring the
window to be displayed on screen.

An example of such (bad) design would be a WYSIWYG "preview" window
that can be driven to print a document, without the need to display
the window itself. In such a case, the window and it's contents are
fully constructed and functional even though the window is not
displayed.


The point I'm trying to make is that objects that require two-phase
construction are not in a *useable* state as long as the second
phase has not been successful.


Displaying a window is an *optional* feature.

So you can construct it, use synchronous messages to simulate user
interaction and get the desired side effects (on MS Windows the
synchronous message API is Send(Notify)Message, opposed to the
asynchronous PostMessage API which really needs an event loop), then
destroy it.

In such a case you never displayed the window, and you never entered
the event loop...


Cheers,

 

[kwikius]

Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.

OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

The problem is that for child windows AFAICS you are restricted to
(smart) pointers

struct ChildWindow{
ChildWindow(system_window_cookie parent); // child needs to have
parent cookie
};
struct ApplicationWindow_w_child {

ChildWindow m_child; // cant do this
ApplicationWindow_w_child() : m_child(???) {//* */}
};

Or am I missing something?

regards
Andy Little

 

[kwikius]

happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.

Cute!. and useful. I will probably keep that

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.

Do you mean win32GUI ?

regards
Andy Little

 

[peter koch]

kwikius skrev:

Cute!. and useful. I will probably keep that

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?



Do you mean win32GUI ?

win32gui is/was a very nice library for windows. Unfortunately it was
not maintained and when I downloaded it some month ago I could not get
it to work (I spend about two afternoons on this). A pity.
One thing I disliked about the library was the use of "magic" numbers -
Windows IDs. This and the use of the resource editor are ackward and
should be avoidable. But apart from that a potentially very nice
library.

/Peter

 

[Kaz Kylheku]

it sounds interesting that Qt and wxWidgets can be used in windows and
linux

.... and have bindings from other languages.

Python: wxPython
Common Lisp: wxCL

 

[kwikius]

happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.

Cute!. and useful. I will probably keep that

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.

Do you mean win32GUI ?

regards
Andy Little

 

[Alf P. Steinbach]

* kwikius:

Cute!. and useful. I will probably keep that

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

Yep.

I mean, have you tried extending a control in a typical GUI framework?

First that happens is that one discovers that this or that can't be done
/here/, because there's no API window yet, not there either, oh dang,
what's the actual /sequence/ of these calls? Not to mention that with
two-phase you get virtual calls down to a derived class' code before the
base class sub-object has been fully (logical level) initialized: bang
crash. And the frustrating thing is the knowledge that all this
[censored] is /unnecessary/, that it's just due to the framework
developers designing the framework for "C++ as better C", not for C++.

Do you mean win32GUI ?

*Checking the web page*

Yes.

 

[red floyd]

OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

I think he means this sort of thing.

void show_dialog()
{
CSomeDialog dlg;

// YECCCH!!! TWO-PHASE INITIALIZATION HERE!!!!!
dlg.this_item = something;
dlg.that_item = something_else;
// etc...
rc = dlg.DoModal();
}

 

[kwikius]

kwikius skrev:

win32gui is/was a very nice library for windows. Unfortunately it was
not maintained and when I downloaded it some month ago I could not get
it to work (I spend about two afternoons on this). A pity.
One thing I disliked about the library was the use of "magic" numbers -
Windows IDs.

I agree about the us of magic numbers. My reference to the system
window cookie in my other posts in this thread was merely to illustrate
an implemntation detail. You should be able to get at the cookie to
hook into the native system, but I agree that it shouldnt be exposed
unnecesarily. Nevertheless the window cookie, or window handle is the
connection point to the system so I think its important to have it as
an, as far as possible opaque, but nevertheless visible Concept.

As far as child window id's go, it is usually possible to map them to a
cookie and so to a platform independent lightweight window type (
basically one that is owned by the system) , which nevertheless
provides "the usual operations", and it is possible to generate id's
automatically internally as required.

For menus my current scheme consists of treating them basically as a
directory tree structure accessed via paths. This works well for menus
as they naturally have unique names per branch. Internally the string
id is mapped to a string_handle so that as well as accessing via text
paths one can create a path consisting of a list of ids, which may
provide faster access. Here FWIW is what my current working test app
menu construction scheme looks like. It is somewhat reminiscent of the
one in Ultimate++ AFAICS:

my_custom_app_window1::my_custom_app_window1(std::string const &
name_in)
: base_type(name_in){

this->add_popup_menu (".File");
this->add_menu_action(".File","Exit",
&my_custom_app_window1::exit_action);
this->add_popup_menu (".number");
this->add_menu_action(".number","1");
this->add_menu_action(".number","2");
this->add_popup_menu (".number","Other");
this->add_menu_action,".number.Other",
"Yep",&my_custom_app_window1::dummy_action);
this->add_popup_menu(".Help");
this->add_menu_action(".Help","About",
&my_custom_app_window1::about_command);

}
(The leading dots are optional but seem to help legibility)
it will also work on arbitrary long paths of course, and the idea is
that you can enable, disable, grey out, get state and change the
callbacks , all via the paths as above. You can also get hold of child
nodes direct if you wish to work at one level.

This and the use of the resource editor are ackward and
should be avoidable.

Personally I dont like the GUI style widget editors much,for designing
controls. IMO It is usually superior and easier to maintain, to size a
modal dialog box, say, at runtime based on the size of the text, images
and so on, so that if these change or are of arbitrary size,constant
borders, spacing and so on are calculated automatically on the fly /
and or according to some 'look and feel' function, so I am trying to
make sure this is easy to achieve programmatically in the language
rather than via custom scripts. Overall this goes for any of the
'resource' stuff. I think by default it should not be necessary to need
resources and it should be possible to create everything
programmatically.

Having created Quan physical quantities library...

http://quan.sourceforge.net/quan_matters/doc/html/index.html

.... naturally I use Quan physical length units for dialog boxes. This
may not be everyones taste but once you know the size of a text
character in mm, or whatever your favourite unit is, I find it is
satisfying to provide spacings and so on in terms of millimeters or
inches or whatever rather than pixels, which gives you a constant look
independent of display hardware.

 

[kwikius]

* kwikius:

Yep.

OK. but the drawback of this AFAICS is that you can only have pointers
(e.g boost shared_ptr) to child windows as members of a winow class I
don't see a way around that.
Nevertheless I will try implementing the single phase construction
scheme. I did a quick test of it in my current test app and lo and
behold I got an exception from a child window that wanted its parent

I mean, have you tried extending a control in a typical GUI framework?

Maybe I just got used to it. Seriously though, I have tried and often
got very frustrated in MFC . I much prefer the raw SDK in Windows.

regards
Andy Little

 

[kwikius]

* kwikius:


Yep.

If the window has a child, where does it get the informtion to
construct it?

regards
Andy Little

 

[Alf P. Steinbach]

* kwikius:

If the window has a child, where does it get the informtion to
construct it?

Huh?

In the example code I gave there were a number of child windows, but no
such problem.

At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.

It's possible that FAQ item 23.6, "Okay, but is there a way to simulate
that behavior as if dynamic binding worked on the this object within my
base class's constructor?" is relevant (although I don't know what your
question really is).

The reason I think it might be relevant: FAQ item 23.6 resulted from
considerations about mismatch of statically type safe construction (as
in C++) versus dynamically typed construction (as in e.g. Windows API
window construction). You can read my original proposal for that FAQ
item (in the proposal numbered 20.7, and with different terminology, we
now call it "dynamic binding during initialization" (Marshall's idea)
rather than "virtual construction" (my idea)) at <url:
http://home.no.net/alfps/faq_proposal/@virtual-functions.html>.

 

[kwikius]

* kwikius:

Huh?

In the example code I gave there were a number of child windows, but no
such problem.

OK. I have quickly perused your screensaver code, but not studied it in
detail. When you talk of child windows in the screensaver app are you
talkng about modal dialogs or persistent child windows?

At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.

Well if you think of a windows application as a tree with the
application window as the root, then you can deduce that as the tree
grows arbitrarily large then the number of arguments to the root window
ctor will grow to ridiculous and umanageable size.

I am interested in the one phase v two phase construction issue. I
don't see why it shouldnt be possible to provide for both paradigms,
but it does affect the structure of code dramatically afaiks.

It's possible that FAQ item 23.6, "Okay, but is there a way to simulate
that behavior as if dynamic binding worked on the this object within my
base class's constructor?" is relevant (although I don't know what your
question really is).

The reason I think it might be relevant: FAQ item 23.6 resulted from
considerations about mismatch of statically type safe construction (as
in C++) versus dynamically typed construction (as in e.g. Windows API
window construction). You can read my original proposal for that FAQ
item (in the proposal numbered 20.7, and with different terminology, we
now call it "dynamic binding during initialization" (Marshall's idea)
rather than "virtual construction" (my idea)) at <url:
http://home.no.net/alfps/faq_proposal/@virtual-functions.html>.

OK I will take a look at those links. To provide a concrete example
AFAIKS one way to create a persistent single phase child window in is
as a non member of the parent:

int main()
{
app_window w; // w gets window system cookie in ctor,
//parent knows nothing about child windows

child_window child(w); // child window has all necessary info to
construct it.

w.run();

}

Whether the creation order is a stack or a tree amounts to the same
thing

The alternative approach of making the child a member seems to me to
require ( for scaleability) two phase construction.

regards
Andy Little

 

[Alf P. Steinbach]

* kwikius:

OK. I have quickly perused your screensaver code, but not studied it in
detail. When you talk of child windows in the screensaver app are you
talkng about modal dialogs
No.


or persistent child windows?

Please define the term.

Well if you think of a windows application as a tree with the
application window as the root, then you can deduce that as the tree
grows arbitrarily large then the number of arguments to the root window
ctor will grow to ridiculous and umanageable size.

Nope. ;-)

An analogy may help.

Think of the object structure of a non-windowing program, with
single-phase construction of all objects. There's a huge collection of
objects. The number of arguments to the top-level object's constructor
(if there is a top-level object) is unaffected: the structure isn't
specified at that point.

 

[kwikius]

* kwikius:

Please define the term.

modeless in Windows terminology. You can remove focus from them and
they will persist as entities, unlike modal dialogs which keep focus (
You cant click a button in another window for example) until closed
bythe user

Nope. ;-)

Hmm. Well looking at the faq, it seems that if I rename any child
window member to child window 'factory' then everybodies happy ;-)

Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve. The aim is that a beginner can get a simple GUI app running
as easily as possible.

FWIW I did say that I had ideas to present my efforts as a standard
GUI, but I also implied I hope not to get overexcited, as from previous
experience I don't seriously expect my stuff to be acceptable. From
experience with Quan , which was presented and rejected by boost:

http://quan.sourceforge.net/quan_matters/doc/html/index.html

The outcome of that is that I think it has put physical quantity
libraries on the radar slightly, and some of the ideas in Quan have
been used in other quantities libs now in the boost vault

At the end of the day I am writing the framework primarily for myself,
hence e.g the use of Quan quantities for dialog units and so on. I am
howvere trying to use standard components where possible . No std::tree
though unfortunately :-(

An analogy may help.

Think of the object structure of a non-windowing program, with
single-phase construction of all objects. There's a huge collection of
objects. The number of arguments to the top-level object's constructor
(if there is a top-level object) is unaffected: the structure isn't
specified at that point.

Whether the tree consists of windows or not doesnt seem to be relevant
AFAICS. The only point of debate is when the tree is considered
constructed. Again call the tree a factory and everybodies happy. This
is basically the scheme I use in my menu example.

regards
Andy Little

 

[Alf P. Steinbach]

* kwikius:

[snip]
Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve.

Yes, that was the argument used to "simplify" AFX to MFC... Not that
AFX was necessarily much better, of course. But you've seen the result.

The aim is that a beginner can get a simple GUI app running
as easily as possible.

Yes, that's what simplicity, like RAII, buys you.

I'm sorry but I don't understand the rest.

It seems there is a communications gap, talking from very different
backgrounds (different experience, different assumptions?). I know that
the scheme I'm advocating is sound, doable and simple, because I've done
it, and provided a working app as a concrete example, and because others
have also done it. And I'm unable to relate the counter-arguments or
questions to anything, to get a grip on what they might really be about.

Perhaps your project is more in line with <url:
http://smartwin.sourceforge.net/>, a framework by Thomas Hansen designed
"get a simple GUI app running as easily as possible", rather than what I
envisioned?

Perhaps some collaboration there could be fruitful?

 

[kwikius]

* kwikius:

[snip]
Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve.

Yes, that was the argument used to "simplify" AFX to MFC... Not that
AFX was necessarily much better, of course. But you've seen the result.

The aim is that a beginner can get a simple GUI app running
as easily as possible.

Yes, that's what simplicity, like RAII, buys you.

I'm sorry but I don't understand the rest.

If you mean renaming windows to window 'factories':

http://smartwinlib.org/faq.php?id=4

Perhaps your project is more in line with <url:
http://smartwin.sourceforge.net/>, a framework by Thomas Hansen designed
"get a simple GUI app running as easily as possible", rather than what I
envisioned?

WEll.. I am hoping to produce something cross platform, but as regards
a standards proposal, don't hold your breath, even if I deliver it.


regards
Andy Little

 

[IR]

OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window
ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

The problem is that for child windows AFAICS you are restricted to
(smart) pointers

struct ChildWindow{
ChildWindow(system_window_cookie parent); // child needs to have
parent cookie
};
struct ApplicationWindow_w_child {

ChildWindow m_child; // cant do this
ApplicationWindow_w_child() : m_child(???) {//* */}
};

Or am I missing something?

I rather thought of an inheritance tree, something along the
lines...

struct Window // base class for all windows
{
system_cookie cookie;
Window(system_cookie parent)
: cookie(0)
{
cookie = create_system_window( /*...*/ );
//...
}
};

struct MyChildWindow : public Window
{
MyChildWindow(system_cookie parent) : Window(parent) { /*...*/ }
};

struct MyAppWindow : public Window
{
MyChildWindow m_child;
MyAppWindow()
: Window(0), // top level, has no parent
m_child(Window::cookie) // cookie is valid here
{ /*...*/ }
};

Or am I the one missing something important?

For better encapsulation, I'd even pass a pointer to a Window object
instead of exposing the raw system cookie in the constructors, but
this is a mere detail here.



I also know of a GUI library (namely, Borland's VCL) which provides
on-demand "cookie construction".
I'm not sure this very design changes anything to the problem we are
discussing, but I thought I'd mention it.

Roughly,

class Window
{
system_cookie m_cookie;
system_cookie m_parent; // see comment below
public:
system_cookie cookie()
{
if (!m_cookie)
{
cookie = create_window( /*...*/ );
//...
};
return m_cookie;
}
Window(system_cookie parent)
: m_cookie(0),
m_parent(parent)
{
// leave m_cookie alone until really needed
}
};

The drawback IMHO with this latter approach is that one needs to
maintain a copy of a window's parameters in the Window class (eg.
the window's parent must be stored so that it is available to the
cookie() method, etc).


Cheers,

 

[kwikius]

I rather thought of an inheritance tree, something along the
lines...

<.. cut examples>

hmm... Clearly I need to try out these scenarios. On reflection I can
see the benefits of single phase construction and I hadnt really
thought about it prior to this discussion, so I will see what I can
come up with in my testbed toolkit

regards
Andy Little