In SDWF 0.3 and below, the Window.windowClass member is a callback, designed to be overridden to return a WindowClass object that the window will use.  For example:

    override WindowClass windowClass() {
        WindowClass c = new WindowClass(application());
        c.icon = 1;
        c.background = COLOUR.APPWORKSPACE;
        return c;
    }

But it's come to my attention that a newbie who hasn't discovered how this works will try to do something like

    windowClass.icon = 1;
    windowClass.background = COLOUR.APPWORKSPACE;

which of course won't work in the current incarnation.

Making Window.windowClass a callback was really just an OWLism, with OWL being the Windows programming library I grew up with and hence the main inspirer of SDWF.  But it doesn't really need to be a callback at all - indeed, being able to specify window class attributes in a constructor is just as good as having a method to override.

I therefore plan to change the infrastructure a bit so that Window.windowClass can be used as a regular callforward property.  I see that I can do this while retaining backward compatibility with the current callback mechanism.

The WindowClass object would probably be pre-constructed, although there would also be a windowClass setter to facilitate reuse in multi-window applications.  (Maybe even a constructor that allows one to be passed in.)

What does everyone think?  I suppose when this is done, there won't be much reason to continue using windowClass as a callback, and so this use might as well be deprecated.  (Of course D doesn't seem to have a way to deprecate overriding of a method at the moment, but at least it would be deprecated at the documentation level.)

This is basically to clarify how it works at the moment (yes, I know looking at the examples would do the same!), and how it might be changed.  If nobody convinces me otherwise, I'll probably implement the changes in 0.4.

Stewart.

Stewart Gordon wrote:
> 
> In SDWF 0.3 and below, the Window.windowClass member is a callback, designed to be overridden to return a WindowClass object that the window will use.  For example:
> 
>      override WindowClass windowClass() {
>          WindowClass c = new WindowClass(application());
>          c.icon = 1;
>          c.background = COLOUR.APPWORKSPACE;
>          return c;
>      }
> 
> But it's come to my attention that a newbie who hasn't discovered how this works will try to do something like
> 
>      windowClass.icon = 1;
>      windowClass.background = COLOUR.APPWORKSPACE;
> 
> which of course won't work in the current incarnation.
> 
> Making Window.windowClass a callback was really just an OWLism, with OWL being the Windows programming library I grew up with and hence the main inspirer of SDWF.  But it doesn't really need to be a callback at all - indeed, being able to specify window class attributes in a constructor is just as good as having a method to override.
> 
> I therefore plan to change the infrastructure a bit so that Window.windowClass can be used as a regular callforward property.  I see that I can do this while retaining backward compatibility with the current callback mechanism.
> 
> The WindowClass object would probably be pre-constructed, although there would also be a windowClass setter to facilitate reuse in multi-window applications.  (Maybe even a constructor that allows one to be passed in.)
> 
> What does everyone think?  I suppose when this is done, there won't be much reason to continue using windowClass as a callback, and so this use might as well be deprecated.  (Of course D doesn't seem to have a way to deprecate overriding of a method at the moment, but at least it would be deprecated at the documentation level.)
> 
> This is basically to clarify how it works at the moment (yes, I know looking at the examples would do the same!), and how it might be changed.  If nobody convinces me otherwise, I'll probably implement the changes in 0.4.

I've not yet had to time to look into SDWF, although it is on my list.
So I can't really comment on your change. Nobody will know better than you.

But the topic of Windows "window" properties I'd like to comment on, because it is really an example how to create a bad API.

A window has perhaps 30-40 properties, that a user might want to influence,
like e. g. background color:
  - position, size, frame type, frame icons, callback windows procedure
  - resizability, menu, local menu, showmode, scrollbars, modality,
  - popup or child status, object reference and data area, ...
These properties are an incredible mess if you want to controll them.
Many of them have special and complicated interfaces or interactions.
Some of them are bound to the windows class and you have a hard time
to change them. Some are pretty unchangeable. Some important properties
are simply missing (like abstract scroll state information / "canvas" size)

The best way to cope with this is to build an enhanced window
object, that offers simple access to its properties, either procedural

  WindowSetBackgroundColor(hwnd,colorref);

or OO

  window.setBackgroundColor(colorref);

every other type of interface is illogical and will force the programmer to step into the Win32 API mess sooner or later. Only few will prepared for the monsters they will find in that jungle.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> or OO
> 
>   window.setBackgroundColor(colorref);
> 

and please note that there is the updating problem that has to be consistently handled too. It won't help you, if you change a property but it doesn't become visible or does become only partially visible depending on circumstances.

Also note that the window background color (class default, but setable) is one of the most useless window properties, because the paint code will have to handle that anyway except in the most rudimentary cases.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
<snip excessive quote>
> But the topic of Windows "window" properties I'd like to comment on,
> because it is really an example how to create a bad API.
> 
> A window has perhaps 30-40 properties, that a user might want to influence,
> like e. g. background color:
>   - position, size, frame type, frame icons, callback windows procedure
>   - resizability, menu, local menu, showmode, scrollbars, modality,
>   - popup or child status, object reference and data area, ...

It really boils down to this:
- Class properties: class name, class style, window procedure, class/window extra bytes (whatever they're for), application instance, icon, small icon, cursor, background brush, default menu
- Window creation properties: caption text, style, extended style, caption text, size/position rectangle, parent, menu, application instance
- Window state properties: accelerators, maximized/restored/minimized state, scroll bar position, DC state information, probably many others....

> These properties are an incredible mess if you want to controll them.
> Many of them have special and complicated interfaces or interactions.
> Some of them are bound to the windows class and you have a hard time
> to change them. Some are pretty unchangeable. Some important properties are simply missing (like abstract scroll state information / "canvas" size)

Indeed, it is a bit of a mess.  But SDWF's principle is to be a thin layer over the Windows API, and sometimes it's useful or necessary to compromise on cleanliness of design.

OTOH, there are places where a clean design over and above the Windows API is feasible, and SDWF does this.  An example is confirmClose, eliminating the need to handle the Exit command, WM_CLOSE and WM_QUERYENDSESSION separately.

> The best way to cope with this is to build an enhanced window
> object, that offers simple access to its properties, either procedural
> 
>   WindowSetBackgroundColor(hwnd,colorref);
> 
> or OO
> 
>   window.setBackgroundColor(colorref);
> 
> every other type of interface is illogical and will force the programmer to step into the Win32 API mess sooner or later. Only few will prepared
> for the monsters they will find in that jungle.

You mean it's illogical to use D properties for what they're there for?

Of course, the ideal is being able to set all window properties via one object.  As it happens, I'm not sure how many of the window class properties are also settable for a window after creation; providing a means of setting these would enable users to only concern themselves with the properties of Window.  But WindowClass would still be available for those who want to set those properties only once for different windows.

Stewart.

Hi Stewart,

I'm not really following the issues, but I am concerned this will delay availability of SDWF ver 0.4. Speaking only for my narrow interests, a TreeView control would be great to have sooner rather than later. Pursuit of excellence "real soon now" can be at odds with "good enough" today.

The best is the enemy of the good. ~ Voltaire ~

Maybe I'm the only one, but I can cope with less than ideal designs if there is sample code available and forums. The Win32 api (and MFC) is certainly "hold your nose" stuff to work with, but is usable ... today ... with examples and cooperative forum members. The availability of CodeGuru, CodeProject, and ExpertsExchange covers a multitude of sins. Justin C. is doing a great job with organizing tutorials at dsource.org, and Brad's participation is much appreciated.  THX!

My 2¢



"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ckj1cu$2n30$1@digitaldaemon.com...
> In SDWF 0.3 and below, the Window.windowClass member is a callback, designed to be overridden to return a WindowClass object that the
window
> will use.  For example:
>
>      override WindowClass windowClass() {

In article <ckjd17$31e5$1@digitaldaemon.com>, Lynn Allan says...
>
>Hi Stewart,
>
>I'm not really following the issues, but I am concerned this will delay availability of SDWF ver 0.4. Speaking only for my narrow interests, a TreeView control would be great to have sooner rather than later.

Not that I know what I'm talking about but...
"How hasrd can it be?"
Can't you just code your own in a couple of hours until
Stewart comes up with the definitive solution?
if SDWF is just a thin layer over the window API
the diferences can't be that important that would make the
conversion to the final version difficult.
If you make I good job send it to Stewart, maybe I he can use it.
(maybe I'm completly off...)

Ant

Lynn Allan wrote:
> Hi Stewart,
> 
> I'm not really following the issues, but I am concerned this will
> delay availability of SDWF ver 0.4.

Have no fear, it would be a very small change that I've pretty much worked out how I'd do already.

> Speaking only for my narrow
> interests, a TreeView control would be great to have sooner rather
> than later. Pursuit of excellence "real soon now" can be at odds with
> "good enough" today.
<snip>

Does this mean the TreeView prototype I tried to send you didn't get through, or that you're eager for it to get into an actual release?

I was rather pressured to release 0.3, but hoped to get more done for 0.4.  Still, I guess it's time to get the new features I have been writing ready for release....

Stewart.

Hi Stewart,

> Does this mean the TreeView prototype I tried to send you didn't get through, or that you're eager for it to get into an actual release?

Sorry ... didn't receive it ... I tried to respond to an earlier post (on dsource?) that may have not been transmitted ok?

> I was rather pressured to release 0.3, but hoped to get more done
for
> 0.4.  Still, I guess it's time to get the new features I have been writing ready for release....

Release early, release often :-)

> From Ant:
> "How hasrd can it be?"
> Can't you just code your own in a couple of hours until

The TreeView control is a complicated widget, at least to this aging newbie. My "proof of concept" toy app uses a TreeView with win32 gui-api calls, but I consider that to be a flawed approach for the longer term.  The std.c.windows.windows.d doesn't yet include the "advanced" widgets beyond the basics (button, checkbox, textedit, etc.) Core32 has some of the constants and structures for the IE 3.0 controls, but is missing most of those related to IE 4.0 from the Win95 time frame (ListControl, TreeView, common-dialogs, etc.).

My 2¢ worth

Lynn Allan wrote:
> Hi Stewart,
> 
>> Does this mean the TreeView prototype I tried to send you didn't get through, or that you're eager for it to get into an actual release?
> 
> Sorry ... didn't receive it ...

Well, I've just tried sending it again.  I presume the email address you're posting under is right?

> I tried to respond to an earlier post (on dsource?) that may have not been transmitted ok?

Not sure what you're talking about.  But my only post on dsource was on the proposed DDoc project.

>> I was rather pressured to release 0.3, but hoped to get more done
>> for 0.4.  Still, I guess it's time to get the new features I have
>> been writing ready for release....
> 
> 
> Release early, release often :-)
<snip>

Maybe you're right.  Maybe I should've used two-digit minor version numbers from the start....

Stewart.