access controls... :o)
(at least that I've seen). Most of what I do is just WebForm or WinForm
based and they are mostly glorified dialog apps. The interface for creating
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
The course is titled "MFC Programming", and its goal is to teach people
who may not know
C++ and usually don't know MFC how to quickly become effective
programmers. I have five
days to teach them the basics of C++ and MFC. Inevitably, there are those
who learned how
to write bad C code 20 years ago, or were taught bad C progrmaming 10
years ago by people
who were bad programmers, and they try to force C++ to look like C. They
don't understand
those complicated "classes", they have ideas like "I want to change the
functionality of
this control, but I don't want to create a subclass", they write bad
Petzold code in MFC
(they write everything as a switch statement by overriding the OnWndMsg or
PreTranslateMessage handlers, because "That's how Windows works". It is
my JOB to
restrict their mindsets!
One of the reasons most of my clients won't use C#, WPF, etc. is that it
doesn't support
MDI, and therefore does not support what they need to do. It was a design
blunder to not
continue this important paradigm into the modern world.
****
Personally, without the help of the smarter IDE holding the hands of
programmers, using MDI in C/C++ was very complex framework to follow
and require a high degree of understanding. Never mind the fact that
it added a higher overhead.
****
I always get suspicious when someone says "higher overhead". I have no
idea what this
means. Sometimes, it means "it executes a few thousand instructions extra
while
processing a mouse click" as if that statement has any meaning whatsoever.
Particularly
if you are trying to compare MDI to SDI, where they essentially have the
same performance.
****
I just had to make a comment mostly because I noticed a propensity
from your post lately that many methods that have many years of
precedence is deemed by you as wrong and/or incorrect. The Exports
thread was one of them. I suddenly felt "Am I stupid?" because we use
WINAPI in our prototyping and DEF files for our WIN32 SDK?
****
WINAPI is a bad choice, for the reasons I outlined. I see nothing that
suggests it was
ever a good choice. If you want to use __stdcall, either invent your own
macro for your
application suite, or use __stdcall directly, but don't use a Microsoft
word that means
"the standard linking into the kernel" because that means changes in that
interface can
render your code nonfunctional, because you have based your interface on
something subject
to change.
.DEF files have their uses, but sometimes they are clumsy. They are not
always the first
and best choice for exporting symbols these days, and unless you are using
features such
as export renaming, numeric entry point mapping, and other DEF-file
features, they don't
represent the ideal selection.
****
both, where it applies, when we want to expose C/C++ classes, then we
use the dllexport/dllimport declarations. When we want to expose pure
pascal based stack proloque/epilogues we used the traditional WIN32
****
You are programming in Delphi? THat's the only thing I know that has a
pascal based stack
prolog/epilog. In a pascal calling convention, arguments are pushed
left-to-right. I'm
sure that is not what you intend, so either you are using __cdecl or
__stdcall. The word
"pascal" as used in WIn16 disappeared from programmers' vocabulary when
Win32 was
released, and it is a failure of Microsoft to have not removed that
obsolete keyword from
every header file in existence. Note that in Win16, the "pascal"
convention really did
push parameters left to right instead of the right-to-left used by __cdecl
or __stdcall.
It is reasonably important to not tie modern programming to quaint and
obsolete, and in
fact, irrelevant, concepts like "pascal".
****
WINAPI because that is how WIN32 works and it is the method most
explicit traditional binding is done in the API world. For use, this
important because we have a 250 function WIN32 API/SDK for all the
major languages, including p-code languages:
****
You are confusing abstraction and implementation. If you want the
implementation of
__stdcall, you can either use it explicitly, or create your own macro, but
relying on
someone else's definition does not seem a good choice.
The point is you need to understand what Microsoft owns and what you own.
You own the
linkages to your library, so using a keyword that Microsoft owns seems
inappropriate.
joe
****
C/C++
Delphi (from 3.0 up)
****
Delphi presumably calls external functions using __stdcall, because it
would not be safe
to assume a C/C++ calling convention for non-Pascal code. But I suspect
it does not use
WINAPI, it uses __stdcall. This week, in Win32 (only), __stdcall and
WINAPI are the same.
****
VB (classic)
Java
PHP
COM
.NET
We have a mixed world here. I will say, today, if you allow the IDE to
create the initial source code and framework, that it helps in the
area of not needing to pay special attention. However, personally,
over the years, when I want clarity or have issues with multi-language
API imports, by far, using the MS dllimport/dllexport has been more
problematic and generally will revert to the basic methods.
****
For multi-language API imports, you have to choose a calling convention
supported by all
the languages. The last I looked, it was formally __stdcall for Win32.
Not WINAPI.
****
Anyway, as David suggested, its about wisdom and generally, with age
comes wisdom and openness to understand:
"There is no such thing as bad ideas, just bad implementations."
SDI and MDI has its place in the CUI arena.
I don't think you want anyone telling you this. I wouldn't, but I am
also not the type to tell anyone that is good or bad. I might suggest
there an an optimal way to do something, but I am strong believer of
people learning thru trial and error and fault. I guess today, that
is rare and IMHO the "IDE" help contribute to people needed more help
not less because almost inevitably most programmers, some day will
need to understand how things actually work not depend on higher layer
frameworks holding their holds. I will be interested to know the
statistics how many programmers don't use the IDE for development or
don't depend on it or get solve issues when the IDE is not there for
them. :)
****
"Good judgment comes from experience. Experience comes from bad judgment"
My goal is to help my students AVOID making the mistakes I have seen, and
most especially
avoid making the mistakes I have made. In my early years of MFC
programming, I would
propose SDI apps to clients. Or accept their specification of SDI.
Inevitably, it became
evident that MDI was what was desired. So why should I tell people that
SDI is a good
idea, when in EVERY case I have created an SDI app, the client ultimately
wanted MDI? That
clients who had SDI apps came to me and said "convert this to MDI,
PLEASE!" When you
start seeing patterns like this, it is important to pass this information
on.
I do not use the VS IDE for editing, because the editor is somewhere out
of the Dark Ages,
sort of glorified keypunch. I know what a program editor is supposed to
do; The VS editor
doesn't do it, and can't be made to do what I need. Intellinonsense
doesn't work right
(gives A or W suffix APIs, not the abstract API), and to use it, I still
need to bring up
the documentation. So, it is nearly useless nearly all the time for me.
I either have
the API memorized and don't need it, or I need the COMPLETE documentation
on it so I know
what flags that UINT or DWORD use, or what
should-have-been-enum-but-is-a-#define constant
I should use. Sadly, the API isn't even defined wll in C, let alone C++,
and I might was
well lhave a decent editor.
Now, perhaps you are confusing "IDE" with what we thought of as "wizards".
Frankly, the
view that these are a handicap is nonsensical. They are very important,
particularly for
beginners, because you can build WORKING code with a minimum of effort,
and learn the
details at your leisure. Doing it by hand means you have to know
EVERYTHING before you
can even start, an extremely poor approach to building cost-effective
systems. I was
delivering MFC solutions for two years before I fully understood command
routing. It did
the right thing, and I didn't have to care why.
The only reason I don't use the wizard-style interfaces was that due to
serious design and
implementation failures, Microsoft rendered it almost but not quite
totally unusable. But
by this time, I don't need it, I can simulate it as fast as I can type.
But I would not
recommend this approach to someone learning MFC. [When Add Variable takes
over a minute
to bring up a dialog, and along the way, every time I want to add a
variable I hear it
spin up the disk in my CD-ROM drive, even though the drive does not appear
in any path
anywhere, I know that someone who was totally clueless did the
implementation. An "add
variable" dialog that can only add one variable, and takes anything over
100ms to come up,
represents a failed design. But it was designed by people who obviously
never actually
wrote a line of code in their lives, and did not understand workflow of
software
development. And to the lame excuse that "it's good for C#", it sucks for
C#, too]
Most people have never seen a decent editor, and don't know what they are
missing using
the primitive editor we get in VS.
****
This is all of course, ONE MAN's OPINION :)
Ciao
Joseph M. Newcomer wrote:
Perhaps because the students have zero years of experience and the
teacher has 15 years
experience dealing with the reality of MFC applications? Maybe what I
do for a living
carries some weight for people who have never done it? I have yet to
find a situation in
which someone asked for an SDI app and did NOT change their mind and
want MDI. Sometimes
they come to me and say "We started this as an SDI app, now we want MDI,
can you fix it
for us? The guy who did it is long gone." In the first few years, I
got good at this
conversion, because they always asked for SDI but ended up wanting MDI.
And "untold
thousands" does not suggest that those apps always make sense. I once
bought an app that
was SDI, while its predecessor had been a DOS version of an MDI
app...seriously, I could
have multiple files open in the MS-DOS version. In the Windows version,
only one, and the
"clipboard" still used the "internal" mechanism from the MS-DOS version
so I could not
copy objects from one file into another file!
Or, to use another quote I am fond of "Just because it is possible
doesn't mean it makes
sense". My job is to teach people the reality of building apps, not
some hypothetical
model that someone at Microsoft thought of in the early 1990s. Reality
for me has
consistently been that anyone who asks for SDI does so out of ignorance.
As soon as they
see the product, or as soon as their customers see it, they want MDI.
You sound like a very special case. The embedded compiler system I did
over ten years ago
was required by the client to be MDI (they got that part right). Since
it cost nothing to
make it MDI instead of SDI, it was the obvious choice.
joe
On Thu, 21 Jan 2010 03:22:16 -0500, Hector Santos
<sant9442@nospam.gmail.com> wrote:
Why would a teacher restrict the mindset of students with such a
highly subjective opinion, which is highly isolated to one own
experiences and to many, not really true in the market place? There
are untold thousands of SDI applications. Its unconceivable to even
notice that it might even be a rarity. Its not. SDI has its place as
well as MDI and they offer two different set of design needs. We use
a MDI for our embedded p-code language/compiler IDE. We use SDI for
monitors, configuration tools, etc. This isn't an oddity or exception.
Very odd statement.
--
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm