IT-Consultant: James C. Fuller > Discussion
SDK or Dialog main window
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”)…
https://en.wikipedia.org/wiki/The_Elementary_Forms_of_the_Religious_Life
Emile Durkheim (of France) …
https://en.wikipedia.org/wiki/%C3%89mile_Durkheim
…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:
--- Quote ---My experience begins a bit earlier than yours
--- End quote ---
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:
--- Quote ---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.
--- End quote ---
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'.
Navigation
[0] Message Index
[*] Previous page
Go to full version