About SDWFAbout SDWFSDWF is a fairly thin layer over the Windows API. This in itself makes for much simplicity over higher-level GUI libraries. But even then, I have seen the source code of OWL 2.5, which is similarly a thin layer, but while it is indeed simple in places, it seems somewhat bloated in others. OK, so SDWF is still at an alpha stage, but as it develops I hope it will continue to be competitive with other GUI frameworks in simplicity and conciseness.
Some GUI libraries cut out such things as the resource file, meaning that such things as menus and dialogs are defined either in the program code itself or in an associated RAD tool (e.g. MS Visual Basic, Borland C++Builder). This tends to mean that they are constructed at run time, rather than at compile time.
But some programmers, such as myself, would prefer to use the native Windows system of resources when writing a native Windows application. SDWF preserves the approach of having the programmer create a resource file (either using a resource editor or by hand-coding), and writing code to use what is defined there.
Also, losing the resource file means losing the ability to embed bitmaps, etc. in the executable. Maybe I'm wrong, and some high-level GUI libraries/RAD tools support this in some way or another. SDWF retains support for bitmaps based on the standard Windows approach.
A D library wouldn't be much of a D library if it didn't take advantage of the features of D. SDWF makes good use of such D features as properties, associative arrays and DBC. This doesn't mean that I will find an excuse to exploit every feature of D, simply that if using a D feature seems the best way of doing something, chances are I'll use it.
As has been said already, programs that explicitly allocate and deallocate memory often have memory leaks somewhere in them. Windows programs can also leak system resources. Indeed, some of my early Windows creations leaked resources like crazy! SDWF classes representing system resources (such as GDI objects) and device contexts have destructors to automatically clean up after themselves.
There are some places where superficially similar concepts have different handling in the Windows API. For example, although the various ways of closing a window (Exit command, Close button, shutting down Windows) generally have the same effect, the API handles them in different ways, with no built-in way of handling them all together. I have seen poorly-written applications whose programmers overlooked this detail. SDWF eliminates the need to worry about this, by providing methods that handle all these ways out in one place.
SDWF is intended for:
SDWF is not for:
The following are some of the things for which I hope to implement support, once I've figured out how:
The following are some of the things I'm probably not going to implement, at least in the near future:
Apart from these, please feel free to suggest new features.