www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [SDWF] Thoughts about Window.windowClass

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Oct 13 2004
next sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
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
Oct 13 2004
next sibling parent Helmut Leitner <helmut.leitner wikiservice.at> writes:
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
Oct 13 2004
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Oct 13 2004
prev sibling parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
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() {
Oct 13 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
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
Oct 13 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Oct 13 2004
parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
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
Oct 13 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Oct 13 2004