#Pane enabling
6 messages in this thread
Andrew,
I agree about that drawing in gray if a Pane is dis-abled, should be built into
the TCL.
One caveat, if the Mac is BW only you can't draw in gray, all PC's Window apps
draw in gray if a pane is dis-abled but they don't have that BW problem.
Anybody have a generalized piece of code for drawing dis-abled panes in gray?
Baiss E. Magnusson
>>>Anybody have a generalized piece of code for drawing dis-abled panes in
gray?"<<<
I've worked on the "greyed-out" (Canadian spelling) problem a great deal. I
find the TCL very short on colour features. For example:
– CPaneBorder would be a great way to draw grey and coloured borders,
if only it supported PixPats instead of Pats.
– CStdPopupPane should use the 'grayishTextOr' transfer mode to
display a deactivated, un-popped-up menu. It would benefit
automatically from the change to CPaneBorder.
– There should be a CIcnPane class to handle the drawing of the whole
ICN# familly.
– CWindow should support 'wctb' resources
– CDLOGDialog should support 'dctb' resources
I've implemented changes to these and many other areas under TCL 1.1.2, but it
cost me a great deal of grief when converting to TCL 1.1.3. There's really no
easy and portable way to make changes like this yourself. They really should be
implemented by Symantec.
It would be no big deal to handle non-color-quickdraw Macs. The TCL would just
check Gestalt to choose the correct technique where necessary. When you
consider the thousands of programs built on the TCL, it makes much more sense
for Symantec to add simple features like this than each of us to add them a
thousand times.
David,
RE: "I've implemented changes to these and many other areas under TCL 1.1.2,
but it cost me a great deal of grief when converting to TCL 1.1.3."
I wrote an extremely "color aware" application, Square One, using TCL. I too
was a bit frustrated by the lack of color support in the TCL. The best solution
is just to override the classes that you mentioned. Don't modify them.
That said, I am fairly convinced that there will never be a significant upgrade
to TCL from here on out, and have started to change the TCL selectively.
jud spencer
Jud:
I have to agree with you: TCL 2.0 seems a million miles off, especially when
you have real work to do today.
I hear what you're saying about overriding the TCL instead of modifying it, but
that's far from an ideal solution for me. It's the classic TCL catch-22: when a
new version comes out, you either have to copy your mods into the new TCL, or
copy the new TCL into your mods. Some of the TCL methods (especially
initializations) are REALLY BIG, which makes it a royal pain when you just want
to patch one line in the middle of it.
Suggestion to Symantec: If the TCL can't be all things to all people, at least
break it up into more methods so I can overide it more easily. This would be
especially useful in initializations; I've got several patches in
CDLOGDialog::IDLOGDialog() alone. Please implement the IClassNameX() methods to
virtual in the next release. These are the ones I most often need to override,
and I can't if they're not virtual.
David
Your suggestions regarding color and increased modularity in the TCL have been
noted.
Kevin Irlen
Symantec Languages Support
David,
Thanks for your response, I agree with all that you have said.
I am getting beat up by some customer's about the lack of color in my latest
app in the pre-press world.
Baiss E. Magnusson