Howdy, Mike. Good to hear from you.

>Nothing personal here either! :).

Kewl. I don't like getting into arguments, but I love a healthy debate,
especially if someone is open enough to find common ground or maybe
consider other possibilities they have not previously considered.

>OK, so tell me in exacting detail how the textbox class was coded.

Ah. A loaded question, huh? LOL! Nice try! :^). All kidding aside,
Mike, this question is doable, even though The textbox class is a
base class, and I seriously doubt that Microsoft is going to give
out this information. The only problem with answering this is that
Microsoft will probably want to sue me for breach of contract if I
disassemble their code and plaster the answer on the net :^). Off the
top of my head (pure, logical guess work), though, I can tell you that:

1) it's a base class and built into VFP.
2) It's most definitely calling the Win32API somewhere along the line and
3) the original code was probably written in C and translated to C++ long ago,
most likely coming from the realms of Visual C++ version 1 or something.

It's probably been modified from here to eternity and back again to work in
.NET and VFP, too.

Oh, and I already know your response: "See. I don't need to know it at that
level to use it's capabilities, and better yet, I can extended it's capabilities
in the blink of an eye!" And you know what, I agree with that statement wholeheartedly! :^)

My problem with the situation is this: "I don't need to understand it at that level."
Wrong! Do NOT pass go! Do not collect $200.00! A good geek _WILL_ understand it at
that level, mainly out of insatiable curiosity, love of his or her work, or the
_need_ to know how the entire system, as a whole, functions. Is it time consuming?
You bet your butt it is! In most situations, is it practical? NOPE! :^). None the
less, knowing the underlying workings of a system makes you a guru/wizard in your
area of interest -- especially in programming and engineering!! -- and going into
any venture half-baked and half-cocked is, IMHO, simply ludicrous. What I'm saying
here, Mike is this: there are mindsets out there that not only need to know how
the textbox class was coded -- they _HAVE_ to know. It's just the way they are.
They love delving into the techincal details, and this is actually the stuff they
love and find enjoying while programming, believe it or not. :^)

>Hiding complexity does not mean you make the code impossible to find.

As in something like this: "Here's a dll/class library that does everything you ever
wanted to do and then some. You don't need to know the details. The methods handle
all of the details for you. Here's the manual." No problem. Saves time. "This code should
have been finished yesterday, and this package will save our butts." I totally
understand this, Mike. This is great, in my book, but, like I've said before,
it's the overall mentality or way of thinking that OOD and the universities are pushing
that gets me. "You don't need to understand the details, son. Leave that up to
people like us. All you need to know is that it has these capabilities, and if
you want to extend the capabilities with a new subclass, kewlness!" Or how about "We have
your best interests in mind; we'll hold your hand; we'll make things simple, and all you
have to do is data entry." And, for all practical purposes, that's exactly what you become.
A frickin' data-entry programmer.

Basically, I want access to the details. I _want_ to know how things are done in
VFP or any other language. However, the new OOD paradigm says that we're not
suppose to even want to know how all the low-level stuff works, and my response
to that brain-dead mentality is this: AHEM!!! BS! :^) :^).

>It means you make a chunk of code that does something complex into a unit.

Agreed. Everything is not spread out everywhere, and it's all in one clear,
logical spot/unit. No problem.

>You build a piece of code that is clear and you name it something clear. It does
>something complex like a spark plug, but you hide the complexity by calling it a
>spark plug and there after reusing it. That's how things are supposed to be built.

I agree, but let me ask you this: Let's say you wrote that code, and I said, "Mike.
That rocks. Way kewl. I need a bunch of these spark plugs. As a matter of fact, I'd
like to set up a spark plug plant. To do this, though, I'm going to need to see how
you make these spark plugs, know the complexity, and all details involved. I'll pay you
for it all, no problem." Most software companies don't want you to know the underlying
code and details. Most OOD folks don't want others to worry about the base class definitions.
"You don't need to know that." <--- This is the mentality I'm talking about. As programmers,
all of us should strive to understand as many underlying details as we possibly can, because
knowing these things will make us all better programmers. For instance, lets say that I did
understand all the code behind the textbox class. I might know that textbox rendering
was painfully slow, and that a better solution would be to use a label that looks and acts
like a textbox in a real-time environment. If I never bothered looking at the base class
and knowing it to whatever degree, I'd never even consider the solution I came up with.
"Just think about it as magic. Don't worry how it does things, only that it does the things
that you want it to do." NAK! (Negative AcKnowledge in RS-232 :^))


Anywho, Naomi should be applauded for her knowledge of SPT and views. If she feels
comfortable with "the more complicated" way of doing things, great! She'll get what
she wants, she knows that she can handle the situation, and she'll probably get a
finer level of control.

Don't get me wrong here, though, Mike. I understand that she can save herself a lot
of time and trouble by using CA's. Great! It's only that I don't like seeing her
(or anyone else) being drawn away from the details, because paying attention to details
is what inspires innovation, creativity, and it's the fountain of genius. Doubt that?
Take your favorite program/programmers/geeks. Scrutinize them. What do you see?
Someone that's been paying attention to details. This is the difference between
a program and a professional program.

>Where "hiding complexity" is bad is when code obscures the simple into ridiculously complex.

Again, I agree. IMHO, it takes a certain mindset or way of thinking to take the complex
and transform it into "complex is nothing more than a bunch of simples stacked on top
of each other." In other words, I try to break down a complex situation into a bunch of
smaller, more manageable pieces, solving these smaller problems one at a time. As a whole,
it's complex, but step back and examine each part and it's simple. That's good code.

Nice talking to you, Mike, and jumpin' off the soapbox. (BIG GRIN!)

Best Regards,

Randall