• Welcome to Jose's Read Only Forum 2023.

SDK or Dialog main window

Started by James C. Fuller, December 01, 2016, 04:09:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

James C. Fuller

Dialog or SDK Windows?
  There are a number of issues and gotcha's along the way especially if you are striving for a DPI aware application.

José does not approve of Dialogs at all. He REALLY likes to type lots of source :) Only kidding! His CWindow is still tops on my list and gives me the flexibility to use full c++ STL or go the almost tiny route with TCLib.
Patrice also does not use dialogs but his coding direction is primarily in the display arena.
Fred ???

I started using Dialogs as my main window back before PowerBASIC's DDT. I was using the Borland 5.0 reource editor and found it easier to create windows using the WYSIWYG approach.

I have waffled back and forth over the last few years but I have never REALLY found a reason NOT to use Dialogs. I just hobby code now but back in my commercial days most of the code I wrote was translating old GWBasic calculation algorithms to PowerBASIC and creating data input screens. Dialog based windows worked just fine.

Fast forward to the world of high dpi monitors and I find dialogs scale and work just fine. Fuzzy fonts can be eliminated with a simple manifest addition or a call to SetProcessDPIAware. One of the items that I knew but am now fully grasping is that the  dialog size is determined by the font and font size in the resource script. Not only the dialog but all the controls size and placement on the dialog. A WS_SETFONT message is sent to all the controls by the dialog engine. You do need to be careful in the design stage as the resource editors I am familiar resize your dialog and controls if you change the font and size.

With SDK you need to send a WM_SETFONT message to all your controls and nothing is resized automagically.
Yes you have more control.....

If you are seeking the "holy grail of tiny" resource dialogs in conjunction with Fred's TCLib is the way to go.


Frederick J. Harris

Dialogs and I have always had a funny relationship.  Like most folks or at least a pretty lot I used Petzold to learn Windows Api coding back in the 90s.  It would have been with Petzold's Windows 95 book.  When I started I knew C pretty good, but of course I struggled pretty hard with the complicated topics.  After getting through about the first half of the book, which would be about chapter 10, I was anxious to start trying to apply my knowledge to my work area which is forestry.  Like you Jim I was at first most interested in data entry screens, as a lot of what I do is recording tree information, i.e., species codes tree diameters, merchantable heights, defect deductions, ad a few others.  So I spent a lot of time at that writting some really poor and unwieldly code.  And up to that point I didn't even know much about dialog boxes as they were covered in chapter 11 of Petzold's book.  I know I did skim that chapter with an eye to figuring out how to get Open File and Save File dialog boxes working, but in those cases one didn't even have to deal with resource scripts. 

When I did finally get to looking through Petzold's Dialog Box chapter in detail my main concern was to learn how to create very simple things like PowerBASIC's InputBox() function, which I think was always Microsoft's idea of where Dialog Boxes fit into the whole picture of Windows Application programming, that is, supporting objects to a main SDK application.  Of course Petzold did cover in some detail using a dialog box as the main application window.  I think it was a calculator program or something like that.  I recall him stating something to the effect that he considered it a somewhat lazy way of doing things.

For a long time though I did 'look down' on dialog boxes as a poor way to going about the Windows Application Development Enterprise.  But extremely competent folks such as yourself, Gary Beane, Chris Boss, and Bob Zale himself kind of cured me of that.  You've all forced me to think it over and try to be objective about it.   And I think I've succeeded in that.  You won't here me bad mouthing dialog boxes anymore.  I know you've asked many times for someone to argue the point and state just how SDK style Windows with a Window Procedure are better than Dialog Box Windows with a Dialog Box Procedure and you don't ever get any takers.  About the only thing I can cay about it is that in my early data entry programs I tended to use the [ENTER] key to move between data entry fields (text boxes), whereas that idea was pretty well subverted with dialog boxes.  I came slow to the idea of using the [TAB] key.

The only other thing that comes to mind is that I always associate data needed by the various windows my programs has with the WNDCLASSEX::cbWndExtra bytes.  I kind of prefer that to Window Properties and Get/SetProp(), although that's fine too.  I'm not even sure you can do that with Dialog Boxes.  Probably can, its just I'm so unfamiliar with the intricacies of dialog boxes.

So where I'm at now with dialog boxes is that I regard them as simply a 'style' of coding I don't do.  I don't consider them better or worse than SDK Windows.  I know I'm not as inclined as you to keep looking for better or easier ways to do things.  When I decide to learn how to do something, I tend to stick to the way I first learned how to do it, rather than looking for a second or third way to do it that might be easier.  That's a failing of mine, I know.  I've got lots of failings, unfortunately.

I will admit I got exasperated over the years with the PowerBASIC site and Dialogs.  After getting started with Windows Api coding in C I discovered PowerBASIC and was astounded that I could code that way in another language which I preferred greatly over the C family languages.  Basic family languages were always my first love in programming languages.  I always took C family languages 'like medicine'.  You know - tasted bad but were supposed to be good for you. 

I discovered that I could code in PowerBASIC like in C with PowerBASIC's 'Hello World' SDK app in the SDK samples directory.  Then I discover the translations of Petzold's programs to PowerBASIC.  But at the PowerBASIC site everything was dialogs, dialog, dialogs without end it seemed.  But I guess in retrospect its to be understood.  I'm sure this is a terrible generalization, but I suspect there may be some truth to it.  Folks who take a liking to basic over C are likely looking for the easiest (quickest and dirtiest I'm hesitant to say!  I really don't want to offend anyone!   :)  ) way to get something done, i.e., maximum possible output from minimal input, and Dialog Boxes fit in nicely in that context.  And its hard to argue with that I think.  Time is money and all that. 

But just in terms of general philosophy, in my life at least I've usually not done well with taking shortcuts.  I've found it often times costs me more in the end.  So I've just accepted that, for me at least, given a choice between the hard way to do something and the easy way, I usually choose the hard way.  I rationalize it by telling myself it'll make a better man out of me, but I fear that oftentimes it just wears me out.

So over the course of the past several years whenever I revisit code where I've used dialog boxes and *.rc files I tend to remove them and redo the code SDK style, i.e., create my own dialog boxes and menus with SDK code.  To me now its just a matter of style rather than based on feeling of one way being inferior or superior to the other.   


José Roca

Dialog boxes were designed as an auxiliary tool to retrieve user input. There is nothing wrong to use them for that purpose, although I prefer not to use them at all because I like to always use the same techniques and not two very different. I also prefer to have full control, even if it takes more work. Because of the lack of full control and its limitations, I don't find dialog boxes very suitable for all purposes.

Like DDT, CWindow eases the creation of the main window and controls, but unlike DDT it is 100% SDK compatible. And if I have used a class, it is because it is a neat way to encapsulate its functionality, not because I'm a OOPer (I'm not). Notice that I haven't written classes to deal with Windows controls just for the sake of using the dotted syntax. I don't care if I have to use ComboBox_AddString or even SendMessage instead of pComboBox.AddString. One thing is to use classes when they offer an adavantage and another to write classes for everything, even to access the members of an UDT, as I sometimes have seen. That obsession to wrap everything with classes is what have made MFC and some libraries for Pascal bloated monsters.

Anyway, this is a matter of preference. If you like to use dialogs, it's your business. But you aren't going to convince me about the convenience of using them. I'm afraid you will end feeling alone. Maybe you will find somebody using resource scripts in some assembler forum.

James C. Fuller

  Thank you for your view on dialogs. Very enlightening.
My experience begins a bit earlier than yours :)


Patrice Terrier

CreateWindowEx... is my Swiss army knife ;)
Patrice Terrier
GDImage (advanced graphic addon)

Frederick J. Harris

There is another somewhat philosophical issue here too that just occurred to me that I feel is important.

It concerns OOP.  When Microsoft knew it had to come up with a windowing operating system, like in the early 80s, the ideas of Object Oriented Programming were well known through the writings of Alan Kay, and the pioneering work at Xerox and what was it – Palo Alto Park in California.  At that time though there wasn't a lot of mainstream language support for OOP.  C had some history to it but C++ was just getting thought out.  So Microsoft used mostly C and some assembler in creating Windows.  But they were trying to adhere to the ideas of Object Oriented Programming I think.  Petzold even mentions this in one place in his books where he states that it is a type of Object Oriented Programming that is being done in Win32 Api coding.  But it is being done in C - not C++.  I think this is a cause of confusion for some new C++ coders who are trying to learn this stuff.  They are looking to see the types of things they learned in their C++ books and lectures and not recognizing it is indeed there in C Win Api coding - they just are not recognizing it in that form.

But that's a bit of a digression.  Getting back to the main topic, in Object Oriented Programming you instantiate objects based on the idea of a Class.  Many programs have multiple actions or behaviors and it is considered good style to create separate classes for each separate modality/action/behavior to be implemented.  In the case of SDK style apps one declares an object of type WNDCLASS or WNDCLASSEX.  Note the very object name contains the Class identifier.  It is indeed a class.  It encapsulates both data and code.  Some of the instance variables are simple integral quantities.  Others are function pointers, which is a C ism for a C++ member function.  In my mind the most critical member is the WNDCLASS::fnWndProc member, because that member requires a separate Window Procedure of each Class of object - not for each instance, but rather for each class.  And its the code in the Window Procedure which uniquely implements the functionality of each instance of the class.

So what's the deal with Dialog Boxes?  They kind of don't fit in somehow to the overarching OOP paradigm.  One can certainly create apps with many windows and with many Dialog Box Procedures.  But they are all of the same system dialog box Class - what is it - 32761 or whatever.

My argument above could perhaps be countered with the idea that its not important.  In PowerBASIC's DDT statement or the Api calls to create dialogs one can specify the Dialog Box Procedure which handles messages for the object being instantiated.  Why bother having the extra baggage of the WNDCLASS variable/object?

But for me I tend to accord the underlying OOP theory as being meaningful.  I like to have a uniquely specified description through the WNDCLASS object of each Class I use in an app.

I'm totally with Jose on his pragmatic ideas of how OOP should be used in an app.  I'm also appalled at the code I regularly see in C++ Forums and elsewhere where everything is wrapped up as much as possible in class plumbing.  Its almost like folks are trying to write as much code as possible to do as little as possible.  Its like why write one line to do something when you can write 10 lines to do the same thing?   

I even have a theory about it.  I think its some kind of religious phenomenon.  According the the pioneering work done a hundred and fifty years ago on the Sociology of Religion ("The Elementary Forms Of Religious Life")...


Emile Durkheim (of France) ...


...stated that the most fundamental dichotomy or distinction the human mind is capable of making is the distinction between the sacred and the profane.  A fundamental idea of religions is that these two realms of thought must be kept forever apart.  They are two separate realms.  But a certain mixing between the two is inevitable in the wear and tear of human life.  Rites and rituals are concerned with the movement between these two separate realms.  When we enter a church we dip our fingers in the holy water and bless ourselves with the sign of the cross.  That which was profane and dirty (us), can now safely enter that exalted and sacred realm.  We can now safely cross that threshold separating these two incompatible realms.  The native american (indian) performs certain rituals after slaying the deer, which is a sacred object (a totem perhaps), but now through the ritual it can cross from the sacred world to the profane one where it can be eaten.

C++, which in the beginning was whole and pure, bestowed upon man to save him from the hell fires of procedural coding, conceived in the sacredness of an environment where Unix was the exalted being with Dennis Ritchie (Moses) enthroned on one side and Bjarne Stroustrup (the Savior) on the other, must now, due to its greatness, exist in a profane world where that most filthy of profane things - money - must be circulated and made.  Rival operating systems springing up from the 'Dark Side', from the filth and corruption of the need to make money in the profane capitalistic system, corporations such as Microsoft, created rival operating systems not based on sacred doctrine, that is, the C++ Standard, but containing non standard functrion calls not part of the Standard or Doctrine.  And disciples of the sacred greats, dutifully taught and adhering to sacred dogma (OOP Theory, the C++ Standard as interpreted in an infallible sacred fashion by the C++ Standards Committee) must somehow go out into the filthy, begrimed and  profane world of men and non Unix Operating Systems, and interact with non C++ Standard Apis and functrion calls. The only way such pure disciples of the faith, imbued with sacredness, can interact with the corruption and filth of non C++ Standard procedural code, is to perform sacred rituals and rites upon it, so that they may not be dirtied and befouled by contact with it.  The actual mechanics of the rituals involve taking that filth of the underlying  non Standard Api code and wrapping it up in the sacredness of Classes.  Due to the sheer filth of it all it is oftentimes necessary to create thick insulations around the foul material.  Sometimes classes must be wrapped up within other classes, sometimes many layers thick.  In this way the unholy, dirty, corrupt procedural mess can be rendered usable by the C++ disciple, who will no longer need to fear contamination by it.  A way has been found to bridge the gap between the sacred and the profane.           

So it is in this way that when a C++ coder is confronted by a non-believer with the sheer size of his creations (massive Class Framework Code), he or she remains undaunted and sees no problem, in the same way a priest or holy man sees no issue with a world in which more sacred objects or religious phenomenon are in evidence. A full megabyte of class code to do something is better than a kilobyte to do the same thing, in the same way a full fountain of holy water is better than one with only a few drops in the bottom.

I'm sorry.  I just couldn't help myself!  There's no worse heretic than a once true believer who has fallen from faith.

Frederick J. Harris

My experience begins a bit earlier than yours

You are an 'early adopter'.  Marketing people catagorize everybody that way.  There are early adopters and late adopters.  If I hadn't changed jobs at the time Windows 95 came out I'd still probably be doing DOS and by now I'd be really, really good at it!

José Roca

I have also meet members of another sect: those that believe that the only professional way of coding is to use libraries. Working with include files is too easy and, therefore, unprofessional.

Frederick J. Harris

I have also meet members of another sect: those that believe that the only professional way of coding is to use libraries. Working with include files is too easy and, therefore, unprofessional.

Yep.  I saw an article on that one time.  The basic rule is don't write any code yourself.  Anything you need done, find a library that does it and use that.  I guess there can be some justification for that in terms of 'don't reinvent the wheel'.