[comp.sys.mac.programmer] Think C StaticText Panes

weyand@csli.Stanford.EDU (Chris Weyand) (07/29/90)

I have an application for which I am currently using a lot of StaticText
(Think C 4.0) panes to display small pieces of text.  Is this a bad idea in
terms of memory?  What are some other alternatives; DrawString directly on the
window?  Comparisons?

On a related note: some of the above mentioned StaticText panes are serving
as buttons.  Basically I wanted buttons without borders that would not just
blink but turn on (hilite) and stay on until clicked on.  There doesn't seem
to be built in facilities in Think C for this (are there?).  I guess what I 
need to do is write a CDEF for a borderless button however I'm not too clear
on how to do this.  Undoubtedly this has been done before.  Can anyone help
me on this?


Thanks,
Chris Weyand
weyand@csli.Stanford.edu

ech@cbnewsk.att.com (ned.horvath) (07/29/90)

From article <14702@csli.Stanford.EDU>, by weyand@csli.Stanford.EDU (Chris Weyand):
> I have an application for which I am currently using a lot of StaticText
> (Think C 4.0) panes to display small pieces of text.  Is this a bad idea in
> terms of memory?  What are some other alternatives; DrawString directly on the
> window?  Comparisons?
> 
> On a related note: some of the above mentioned StaticText panes are serving
> as buttons.  Basically I wanted buttons without borders that would not just
> blink but turn on (hilite) and stay on until clicked on.  There doesn't seem
> to be built in facilities in Think C for this (are there?).  I guess what I 
> need to do is write a CDEF for a borderless button however I'm not too clear
> on how to do this.  Undoubtedly this has been done before.  Can anyone help
> me on this?

For the latter, you might just want to define a subclass of StaticText that
behaved this way.  This is coming straight off my fingers, so don't expect
it to compile first time:

struct FlashText : CEditText {
	Boolean	hilited;

	void	HiliteIt (Boolean aHilite);
	void	Draw (void);	/* OVERRIDE */
	void	DoClick (...RTFM...);
};

and the implementation is

void FlashText::HiliteIt (Boolean aHilite)
{
	hilited = aHilite;
}

void FlashText::Draw()
{
	Rect aRect;

	inherited::Draw();
	if (hilited) {
		GetAperture (&aRect);
		InvertRect (&aRect);
	}
}

and FlashText::DoClick does your thing.  You might want to swipe the
SetClickCmd() and DoClick() from CButton.  This is a mundane example of
where multiple inheritance could simplify your life, but that's another
flame war...

=Ned Horvath=

cash@zug.csmil.umich.edu (Howard Cash) (08/05/90)

In article <1990Jul29.040422.21686@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes:
>From article <14702@csli.Stanford.EDU>, by weyand@csli.Stanford.EDU (Chris Weyand):
>> I have an application for which I am currently using a lot of StaticText
>> (Think C 4.0) panes to display small pieces of text.  Is this a bad idea in
>> terms of memory?  What are some other alternatives; 
>
>For the latter, you might just want to define a subclass of StaticText that
>behaved this way...  
>

TCL's CStaticText is very wasteful (except as a superclass of CEditText
for purposes of organizing the code).  It creates a TEdit record (a 
relatively bulky data structure) even though none of TEdit's editing 
functionality will be used.

If you are going to use a lot of static text in your app, consider 
building a new class that uses TextBox (Inside Mac Vol1, p388) or,
if the text does not need formatting, just storing the string and 
drawing it in a Pane in the ::Draw method.

-Hobart