IT-Consultant: James C. Fuller > Discussion

SDK or Dialog main window

(1/2) > >>

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 ;)


[0] Message Index

[#] Next page

Go to full version