> Have you run into the thing where controls defined in the RC
> file don't work right and you have to define them in the C code?
I've never seen a case where I was convinced that I was doing everything
right. (But it has happened; perhaps it wasn't just me...)
But of course I use Ada code to define controls. There is no C in Claw.
(Something about that statement looks funny! :-) Claw interfaces directly to
the Win32 interfaces.
The main reason that I and the other Claw developers go through so much pain
with Windows is so that the Ada programmer using Claw doesn't have to. As
much as possible, we "cover up" differences between Windows versions and
unusual behavior in Claw. (Which is why Claw doesn't support some of the
Windows-defined styles: experments suggest that they don't work, so we don't
include them in Claw.)
> However, Microsoft, to its credit, is scrupulously clear about what
> versions a given option is good for.
Although sometimes the options don't work anyway. And it is often the case
that some important details are missing in the description...
> I've had a chance to study quite a few standards in recent years,
> and even contribute in a small way to a couple, and I can't think
> of one that even comes close to the rigor of the Ada standards.
> There's way too much "then you wave your hands and the magic
> happens" and neglect of initial and final conditions. About the
> only truly outstanding thing I've seen in a spec recently is the
> ECMA-262 math function definitions.
> So I think your operational definitions of "standard" and "clearly
> defined" are set too high for real-world standards.
Could be. But that seems to prove the point: the world doesn't take
standards seriously. If they did, unclear and ambiguous standards wouldn't
last long. Another area for us Ada people to do some education. (See, I can
somehow relate this to Team-Ada. :-)