Hi, Bob.

BL>  FM> I think you need to take some time out to understand the object
BL>  FM> paradigm - encapsulation, inheritance and polymorphism, all of
BL>  FM> which should be supported by the compiler. I believe C++ also
BL>  FM> does this (but I've never used it).

BL>   I only learn what I *have* to learn, when I have to learn it. In
BL> fact, Delphi is very much like VB in the way it uses objects.

Well I don't know VB that well, but I think you mean *visual* objects,
the things you see on your screen. AFAIK VB doesn't have any
object-oriented stuff, in the programming (rather than the visual)
sense.

BL> I just wish they'd cut down on the buzz words and nerd-jargon.

Some jargon only obfuscates, but some really does exist to add
explanatory power. At some point I think you should step back and take
some time to learn the object-oriented stuff, not because you have to at
the time, but because it'll make future programming easier.

BL>  BL> Compiling is too slow,

BL>  FM> What? What could be quicker than pressing F9 and suddenly your
BL>  FM> application is running? The compile/link happens in a blink.
BL>  FM> And I think your system is faster than mine, n'est ce pas,
BL>  FM> clock-speed wise?

BL>   I press the button, and it takes 2-3 seconds (about the same as
BL> C++). The hard-disc light does not come on, which means it's all in
BL> cache. Of course, once it's in cache and I do it the second time, it
BL> does it in a blink (like BC++ which is also slow), but it's this
BL> first time that's the nuisance.

This seems to be contradictory. First you say it's in cache but still
takes 2-3 seconds, then you say that once it's in cache it happens in a
blink.

Curiously, Delphi uses more RAM than
BL> BC++4. I had to give it another meg off RAMdrive. It was right on
BL> the RAM limit of the virtual disc.

That's not too clear. Do you mean you have to make a bigger RAMdrive, or
smaller so you can give the memory back to the system? What do you put
on the virtual disk? Why not just get SmartDrive to handle it? And next
time Brenton's over, get him to set up your system; sped mine up
significantly.

BL>   The problem is that is recompiles the *whole* 220K form every rime I
BL> add a space or remove it. Try it for yourself. Compile, add a space in
BL> the code and then remove it, and Run again. I takes 2-3 seconds.

I don't tend to have big units, just a lot of little ones with logically
related things in them. So only the one you've changed gets recompiled,
the rest are just linked in from the .DCU.

BL> BTW, how the hell do you write code in another thingie that leaves the
BL> main form and main unit alone? I tried adding a unit, but the first
BL> one doesn't want to know about what I write in there, even though
BL> the unit has been declared in the program DPR (or whatver they call the
BL> MAK file).

That's probably where you're going wrong; it's *not* a make file in the
C sense. It's just the main program, normal Pascal code. Any unit (or
the main program) which uses stuff in another unit must be told where it
is, by putting that unit in a 'uses' clause. So BobProg.dpr will have
'uses BobUnit1', (called Unit1 by default, but I tend to rename things
to something meaningful), and BobUnit1 will have 'uses BobUnit2,
BobUnit3, ...' etc.

BL>  BL> and it annoys me when I have to type things in upper and lower case,
BL>  BL> when the editor should recognise the keywords and do it for me.

BL>  FM> Eh? You can type in whatever case you like!

BL>   The VB editor has a very nice trick. You type in lower case (or
BL> whatever you like), and at the end of the line, the editor corrects
BL> it to what VB wants.

I've seen that, don't like it at all. I think Word Basic does something
similar. I want my capitalisation *my* way, not what the compiler writer
thinks. I see that Bek is of a similar view.

This means that you can tell if you've forgotten
BL> to declare a variable (it doesn't change) or if you have used a
BL> protected word (it changes when it shouldn't), or if you misspelled a
BL> function name (it doesn't change when it should). If you change the
BL> case of a variable, it changes right through the code. You don't have
BL> to wait to compile it to find syntax errors; you see it happen as you
BL> type... in the editor itself. This little feature that would take no
BL> more than an hour to implement, saves an enormous amount of time in
BL> writng... plus the fact the VB really is instantaneous because it does
BL> not compile until you make the EXE file spearately.

I wouldn't call it a feature, and if it was provided as an option I'd
never turn it on. If press F9 or Ctrl-F9 when you have got errors -
undeclared variables, misusing reserved words, etc, then it really is
instantaneous to have that error shown to you. Even on your '220k form',
I would expect.

BL>  BL> But it's early days yet... maybe I'll fall in love.

BL>  FM> Hopefully, but maybe take some time out to understand what OOP
BL>  FM> really means. I think you'll need to be working in Borland
BL>  FM> Pascal (see how careful I was to say that, Paul), Delphi or C++
BL>  FM> to get the benefits though.

BL>   OOP means trouble. I learned to program in VB, which meant I was
BL> using OOP and event programming from the start (without realising it).

I don't think you were. Object-based, perhaps, for the visual stuff, but
not OOP. Event-driven sure, that's how Windows works.

BL> What gives me the shits, is that Borland spend all their time
BL> explaining the visual interface that is so instinctive it explains
BL> itself, but no time on how to order or declare procedures in this new
BL> version of Pascal that uses Units and has the program part somewhere
BL> else entirely! In VB or C, you put the bloody SUBS anywhere you like
BL> and it sorts it out for you. Pascal is fussy, it seems, Delphi is
BL> different, and I've lost the plot.

That stuff (units) is no different from the more recent (pre-Delphi)
implementations in Turbo Pascal. And you can put all the functions and
procedures in one unit if you want to, basically wherever you like so
long as it's before they're called or you use the 'forward' declaration.
It just usually makes better sense not to do that.

BL>  FM> I think Paul Markham makes the same point in his message to
BL>  FM> Paul E, directly after this one of yours to which I'm replying.
BL>  FM> Presumably you saw it.

BL>   The way I learn is to distil ideas first. I get around to the actual
BL> thing later. I don't have any troubles using objects, so why bother?

I don't think your using objects much, yet.

BL>   BTW, I like Pascal's way of handling pointers with the p^. In usual
BL> Borland vein, they call this dereferencing

It's also called dereferencing in C.

BL> (something like tossing a BL> Czech out a window, I suppose),

:-)

BL> but it really means going from the address to the thing. What a
BL> good idea! And I can't make Delphi lock the computer no matter what
BL> I do. I get lots of GPFs but it always comes back and laughs at me.

I see that you have subsequently discovered how to do this, by writing
an infinite loop. :-)

BL>   I reckon it's time they rewrote Pascal properly, and called it D.
BL> It's silly mixing Pascal strings and null strings, and it's bloody
BL> stupid too, when the Windows API uses pointers and Delphi objects use
BL> Pascal strings! ROFL! I wonder who thought *that* one up? I guess they
BL> were hoping to keep the dickhead market, but you can't dodge pointers
BL> anyway, so you're stuffed.

Turbo Pascal's strings were always there, like that. At least back to
TP3, the first version I used. They had to add support for
null-terminated strings when they went Windows, because that's what the
C-oriented Windows designers used.

BL>   Delphi is still a hotch potch, and I spend half my time writing
BL> conversions. It's a shame, when their pointers work so well, and it
BL> would have been easy enough to write their objects to take pointers.

Er, they do. If I understand your point.

Regards, FIM.

 * * And now for something completely different!
@EOT:

---