I've been on an unofficial break from developing SDWF, and am now trying to get back into it.  The next version may well be released any time in the next few weeks.

I've figured it's about time to start getting rid of the deprecated bits that have built up over time.  So I'm removing what was deprecated in version 0.3 or earlier, as well as the sdwf02comp version.

Those of you who use SDWF should have had plenty of time to modernise their code, but for any who haven't, now would be a good time.  Once you've fixed the deprecations that the compiler picks up, it might be worth having a look at

http://pr.stewartsplace.org.uk/d/sdwf/ref/deprecated.html

in case there's anything that the compiler (knowing its bugs in the deprecation field) may have missed.

Now would also be a good time to add stuff to the wish list.

http://www.wikiservice.at/wiki4d/wiki.cgi?SDWF

I'm not guaranteeing that everything that's added there will be in the next release, but something that's on the list (and is implementable at the moment) stands a higher chance of making it any time soon than something that isn't.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart,

A couple suggestions, if you're interested:

- Different name: SDWF just doesn't stick; I've always found frameworks/projects with pronounceable names easy to remember (eg. Mango, Derelict, Ares; obviously, DWT and DUI are bad examples except having 3 letters is still simpler than having 4 :) ).

- A GUI builder; I think this is one of the biggest things missing in most of the D GUI projects; having one of these for SDWF would certainly make the framework stand out even more.

All the best,

John

John Reimer wrote:
> Stewart,
> 
> A couple suggestions, if you're interested:
> 
> - Different name: SDWF just doesn't stick; I've always found frameworks/projects with pronounceable names easy to remember (eg. Mango, Derelict, Ares; obviously, DWT and DUI are bad examples except having 3 letters is still simpler than having 4 :) ).

I have wondered what to do with the name in the long run.  Two I briefly thought up are:

- DOWL or Dowel - from D + OWL (ObjectWindows Library), which is the Borland C++ library that inspired me to write SDWF.  Though this might make it sound too much like it's meant to be a carbon copy of OWL's API.

- Shaduf - as a pun on SDWF and the ancient irrigation tool, if you think of the 'W' as having a /u/ sound like in some Welsh words.  I can't make up my mind if I like the sound of that name....

> - A GUI builder; I think this is one of the biggest things missing in most of the D GUI projects; having one of these for SDWF would certainly make the framework stand out even more.

At the moment, users are encouraged to use a Windows resource editor, of which many are available.

http://www.thefreecountry.com/programming/resourceeditors.shtml

Can you think of any improvements that a GUI builder tailored to SDWF would achieve?

But something else I might write in the not-too-distant future is a tool to extract #defines from resource files and put them in a D module....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dq918g$19qg$1@digitaldaemon.com...
> - DOWL or Dowel - from D + OWL (ObjectWindows Library), which is the Borland C++ library that inspired me to write SDWF.  Though this might make it sound too much like it's meant to be a carbon copy of OWL's API.

I wouldn't make a play off of anyone's trademarked name. It doesn't have to be an acronym, anyway. Just pick a name, like a moon of Jupiter or something like that.

Stewart Gordon wrote:
> John Reimer wrote:
>> Stewart,
>>
>> A couple suggestions, if you're interested:
>>
>> - Different name: SDWF just doesn't stick; I've always found frameworks/projects with pronounceable names easy to remember (eg. Mango, Derelict, Ares; obviously, DWT and DUI are bad examples except having 3 letters is still simpler than having 4 :) ).
> 
> I have wondered what to do with the name in the long run.  Two I briefly thought up are:
> 
> - DOWL or Dowel - from D + OWL (ObjectWindows Library), which is the Borland C++ library that inspired me to write SDWF.  Though this might make it sound too much like it's meant to be a carbon copy of OWL's API.
> 
> - Shaduf - as a pun on SDWF and the ancient irrigation tool, if you think of the 'W' as having a /u/ sound like in some Welsh words.  I can't make up my mind if I like the sound of that name....


Neither ring a perfect note. DOWL sounds like dowel, which brings to mind a small round piece of wood we used to make arrows out of when I was a kid. :)

Shaduf... Brings absolutely nothing desirable to mind.  Unfortunately when I read it, it sounded like the ST*U... replace the * with an F and you got the rather unpleasant note that came to me, unfortunately :(.

Not sure what else.  But I'm sure there's a good name just waiting to be used.


>> - A GUI builder; I think this is one of the biggest things missing in most of the D GUI projects; having one of these for SDWF would certainly make the framework stand out even more.
> 
> At the moment, users are encouraged to use a Windows resource editor, of which many are available.
> 
> http://www.thefreecountry.com/programming/resourceeditors.shtml
> 
> Can you think of any improvements that a GUI builder tailored to SDWF would achieve?
> 
> But something else I might write in the not-too-distant future is a tool to extract #defines from resource files and put them in a D module....
> 
> Stewart.
> 

You're probably right about this one.  Since I haven't really investigated how your library works, I can't really comment further.  Is it easy to interface with windows resources and widget ID's from SDWF? I'll have to take a peek at how your framework works... it's been awhile.

Later,

John

In article <dq9nqa$1s5k$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dq918g$19qg$1@digitaldaemon.com...
>> - DOWL or Dowel - from D + OWL (ObjectWindows Library), which is the Borland C++ library that inspired me to write SDWF.  Though this might make it sound too much like it's meant to be a carbon copy of OWL's API.
>
>I wouldn't make a play off of anyone's trademarked name. It doesn't have to be an acronym, anyway. Just pick a name, like a moon of Jupiter or something like that.


"All these names are yours, except Europa.  Attempt no project there."

- EricAnderton at yahoo

In article <dq918g$19qg$1@digitaldaemon.com>, Stewart Gordon says... ..

>At the moment, users are encouraged to use a Windows resource editor, of which many are available.
>
>http://www.thefreecountry.com/programming/resourceeditors.shtml

In addition to providing this link, you might mention your favorite resource editor/resource compiler so that users are more insulated from the subtle little differences between them (and surely you'd have a better idea of which one is the best than someone who doesn't already have a favorite).

(By the way, your link mentions some pretty cool icon editors that I wish I had known about earlier. Awesome!)

>But something else I might write in the not-too-distant future is a tool to extract #defines from resource files and put them in a D module....

Or perhap a tool that converts a D module into #define's so that they could be imported by a resource file.

A few years ago I came up with a cute little tool (nothing fancy) called "h_to_d" that did something like what you're suggesting, but it's been so long since I've used it that I'm not certain where the latest code is anymore. (I'm sure it'll show up somewhere though it probably needs to be rewritten anyway.) ;)

(Here's a link to a discussion where I mentioned it: http://www.digitalmars.com/d/archives/18529.html)

jcc7

J C Calvarese wrote:
> In article <dq918g$19qg$1@digitaldaemon.com>, Stewart Gordon says...
> ..
> 
>> At the moment, users are encouraged to use a Windows resource editor, of which many are available.
>>
>> http://www.thefreecountry.com/programming/resourceeditors.shtml
> 
> In addition to providing this link, you might mention your favorite resource
> editor/resource compiler so that users are more insulated from the subtle little
> differences between them (and surely you'd have a better idea of which one is
> the best than someone who doesn't already have a favorite).
> 

I recommend XN Resource Editor. I think it is not in the freecountry list... http://www.wilsonc.demon.co.uk/delphi.htm

J C Calvarese wrote:
> In article <dq918g$19qg$1@digitaldaemon.com>, Stewart Gordon says...
> ..
> 
>> At the moment, users are encouraged to use a Windows resource editor, of which many are available.
>>
>> http://www.thefreecountry.com/programming/resourceeditors.shtml
> 
> In addition to providing this link, you might mention your favorite resource
> editor/resource compiler so that users are more insulated from the subtle little
> differences between them (and surely you'd have a better idea of which one is
> the best than someone who doesn't already have a favorite).

I use Resource Workshop (from Borland C++ 4.52) myself.  But that's because I've had Borland C++ for years, and haven't yet bothered to check out the more modern resource editors.

But as for resource compilers, these days I use the Digital Mars one from the Basic Utilities Package.

> (By the way, your link mentions some pretty cool icon editors that I wish I had
> known about earlier. Awesome!)

Yes.  I wanted an icon editor for quite a long time before my dad finally found and installed a few.  I wondered why M$ didn't just make one that comes with Windows.  This was before I started doing Windows programming....

>> But something else I might write in the not-too-distant future is a tool to extract #defines from resource files and put them in a D module....
> 
> Or perhap a tool that converts a D module into #define's so that they could be
> imported by a resource file. 

Why do it this way round?  Surely it makes more sense to define the IDs of resource entities as part of maintaining the resource file.

> A few years ago I came up with a cute little tool (nothing fancy) called
> "h_to_d" that did something like what you're suggesting, but it's been so long
> since I've used it that I'm not certain where the latest code is anymore. (I'm
> sure it'll show up somewhere though it probably needs to be rewritten anyway.)
> ;) 
<snip>

There have been a few attempts to write tools to convert .h files to D modules.  Joshua Cearley started one with the name H2D, which was later renamed DIGen; however, it has been apparently dead since this renaming almost a year ago.

When I programmed in C++, I would tell Resource Workshop to put the #defines in a separate .h file, which is included by both the .rc file and the C++ code files.  However, when making a resource file for a D program, I would tend to have the #defines straight in the .rc file, since D cannot use them directly anyway.  What I was planning to write is a cute little tool that extracts _only_ the #define statements and translates them into D.  Possibly even optionally converting them into named enums (with the first underscore effectively becoming a dot) in the process.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <dqg8bs$1c1u$1@digitaldaemon.com>, Stewart Gordon says...
>
>J C Calvarese wrote:
>> In article <dq918g$19qg$1@digitaldaemon.com>, Stewart Gordon says... ..
>>> But something else I might write in the not-too-distant future is a tool to extract #defines from resource files and put them in a D module....
>> 
>> Or perhap a tool that converts a D module into #define's so that they could be imported by a resource file.
>
>Why do it this way round?  Surely it makes more sense to define the IDs of resource entities as part of maintaining the resource file.

I can see advantages for doing it either way. But if I'm manually editing a source file, I'd rather work with a D source file and convert it to a bunch of #DEFINE's. D just looks more pleasant to me. Also, if someone were using the Build utility, it can automaticallly keep track of an incrementing build number and provide a D module (see http://build.dsource.org/AUTO_BUILD_NUMBER.htm#AUTO_BUILD_NUMBER)

>> A few years ago I came up with a cute little tool (nothing fancy) called "h_to_d" that did something like what you're suggesting, but it's been so long since I've used it that I'm not certain where the latest code is anymore. (I'm sure it'll show up somewhere though it probably needs to be rewritten anyway.) ;)
><snip>
>
>There have been a few attempts to write tools to convert .h files to D modules.  Joshua Cearley started one with the name H2D, which was later renamed DIGen; however, it has been apparently dead since this renaming almost a year ago.

I'm sure my little program wasn't nearly as extensive as Joshua Cearley's project. I was only concerned with simple .h files that would be used by .rc files. It was a simple project with a simple goal.

>When I programmed in C++, I would tell Resource Workshop to put the #defines in a separate .h file, which is included by both the .rc file and the C++ code files.  However, when making a resource file for a D program, I would tend to have the #defines straight in the .rc file, since D cannot use them directly anyway.  What I was planning to write is a cute little tool that extracts _only_ the #define statements and translates them into D.  Possibly even optionally converting them into named enums (with the first underscore effectively becoming a dot) in the process.

Sure, that'd be useful.

jcc7