ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-018

Text File | 2010-09-21 | 87KB | 2,419 lines

Received-Date: Fri, 22 Apr 1994 12:17:43 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-018
To: [e-mail]
Date: Fri, 22 Apr 94 12:17:36 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 20

C.S.M.P. Digest             Fri, 22 Apr 94       Volume 3 : Issue 18

Today's Topics:

        CD-ROM of Mac source code?
        Color Quickdraw Intimcay
        Custom popup menu
        Editable pop-up menus
        Females who answer questions?
        HELP - PICT File ColorTables and Palettes
        Max # of open files
        Proper QT PICT creation?
        Q: Changing font & size of dialog items
        Removing PowerPC code from a fat binary
        Roman Numerals
        SCSI Drivers



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Paul Celestin)
Subject: CD-ROM of Mac source code?
Date: 5 Apr 1994 21:39:46 GMT
Organization: Celestin Company

Does anyone know of a CD-ROM of Mac source code? I know there are plenty of
sites on the Internet with source code, but has anyone compiled it all into
one CD-ROM? If not, are there any people interested in something like this?
If it's not available, I might do it myself.

Thanks for all replies.
--
[e-mail]              (Paul Celestin, Celestin Company)
Check out my URL:   file://speedway.net/pub/celestin/www/Celestin.html

+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 7 Apr 1994 22:57:04 -0700
Organization: Apple Computer, Inc., Cupertino, California

[e-mail] (Paul Celestin) writes:

>Does anyone know of a CD-ROM of Mac source code? I know there are plenty of
>sites on the Internet with source code, but has anyone compiled it all into
>one CD-ROM? If not, are there any people interested in something like this?
>If it's not available, I might do it myself.

MacTech Journal sells a CD-ROM with all the source code and articles
they've ever published.

Wayzata publishes Disc Tracy, which is a collection of Macintosh source
code on CD-ROM.  Wayzata is in the metropolitan Minneapolis Minnesota
area.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

+++++++++++++++++++++++++++

>From [e-mail] (Rand Arnold)
Date: Fri,  8 Apr 94 17:24:17 PST
Organization: Berkeley Learning Technologies, Inc.

Paul Celestin writes:

>>Does anyone know of a CD-ROM of Mac source code? I know there are plenty of
>>sites on the Internet with source code, but has anyone compiled it all into
>>one CD-ROM? If not, are there any people interested in something like this?
>>If it's not available, I might do it myself.


Xplain Corporation sells a CD-ROM that contains all of the source code from the
last eight years of MacTutor/MacTech magazine. It can be quite a resource.
Xplain can be reached at [e-mail] or [e-mail], voice (310)
575-4343.

Rand
Berkeley Learning Technologies, Inc.                           [phone]

---------------------------

>From [e-mail] (Brian Veenker)
Subject: Color Quickdraw Intimcay
Date: 1 Apr 1994 13:00:57 -0600
Organization: UTexas Mail-to-News Gateway

Crud. So GWorlds don't work on non-Color Quickdraw machines. One user
suggested that I just leave my data in some native format and just draw
it as I go. I want this prog to run on everything, but that sounds like a
huge pain in the butt.. Especially since I probably won't be able to work
on it on my PB100 now...

WAIT a minute, I just copied the thing over (to my PB100), and it woiks!
Groovy! I'm back in business! Thanks everyone!

BTW: does it make any difference that I'm only using a 1-bit depth in my
GWorld? Could that have helped? Or is it that my PB100 just happens to be
running Color Quickdraw?

Thanks again everybody!
Brian Veenker



+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 5 Apr 94 12:43:02 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Brian Veenker) writes:
> Crud. So GWorlds don't work on non-Color Quickdraw machines. One user
> suggested that I just leave my data in some native format and just draw
> it as I go. I want this prog to run on everything, but that sounds like a
> huge pain in the butt.. Especially since I probably won't be able to work
> on it on my PB100 now...
>
> WAIT a minute, I just copied the thing over (to my PB100), and it woiks!
> Groovy! I'm back in business! Thanks everyone!
>
> BTW: does it make any difference that I'm only using a 1-bit depth in my
> GWorld? Could that have helped? Or is it that my PB100 just happens to be
> running Color Quickdraw?

Your PB100 does not have Color QuickDraw. However, under System 7, even
non-Color-QuickDraw machines have GWorlds, albeit limited to 1 bit per pixel,
as you were using.

IM6 has a list somewhere of the Color QuickDraw calls you're allowed to make
on a non-Color-QuickDraw machine under System 7.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sun,  3 Apr 94 19:56:38 PST
Organization: Berkeley Macintosh Users Group

[e-mail] (Brian Veenker) writes:

>Crud. So GWorlds don't work on non-Color Quickdraw machines. One user
>suggested that I just leave my data in some native format and just draw
>it as I go. I want this prog to run on everything, but that sounds like a
>huge pain in the butt.. Especially since I probably won't be able to work
>on it on my PB100 now...
>
>WAIT a minute, I just copied the thing over (to my PB100), and it woiks!
>Groovy! I'm back in business! Thanks everyone!
>
>BTW: does it make any difference that I'm only using a 1-bit depth in my
>GWorld? Could that have helped? Or is it that my PB100 just happens to be
>running Color Quickdraw?

Don't confuse "Color Quickdraw" with "monitor is displaying color".
"Color Quickdraw" means that you have the version of Quickdraw that
understands what color is.  It doesn't necessarily mean that you have
your monitor(s) set to display color, or even that you have a color-
capable monitor.

Color Quickdraw is in the ROMS of Mac II and later machines, and is also
in System 7 or later.  So you can probably depend on color QD and still
run on almost everything.  You will be locking out only SE and earlier
machines running on 6.0.8 and earlier, and I think even for those machines
there may be an INIT that will supply color QD.  For that matter, if you
are using GWorlds, you are already depending on Sys7, so you should have
color QD already.  Of course, the noble thing would be to check anyway...

-Ron Hunsinger

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Wed, 6 Apr 94 16:08:32 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Ron Hunsinger, [e-mail]
writes:
>Color Quickdraw is in the ROMS of Mac II and later machines, and is also
>in System 7 or later.  So you can probably depend on color QD and still
>run on almost everything.  You will be locking out only SE and earlier
>machines running on 6.0.8 and earlier, and I think even for those
machines
>there may be an INIT that will supply color QD.  For that matter, if you
>are using GWorlds, you are already depending on Sys7, so you should have
>color QD already.  Of course, the noble thing would be to check anyway...

This is not entirely true, Color QD will not run on 68000 Macs, not even
with the prism INIT.  Many of the Color QD routines are written in 68020
assembler.  One of the Tech Notes explains this.

+++++++++++++++++++++++++++

>From [e-mail] (Greg Landweber)
Date: 08 Apr 1994 11:37:03 GMT
Organization: (none)

In article <[e-mail]> [e-mail] (Ron Hunsinger) writes:
   Color Quickdraw is in the ROMS of Mac II and later machines, and is also
   in System 7 or later.  So you can probably depend on color QD and still
   run on almost everything.  You will be locking out only SE and earlier
   machines running on 6.0.8 and earlier, and I think even for those machines
   there may be an INIT that will supply color QD.  For that matter, if you
   are using GWorlds, you are already depending on Sys7, so you should have
   color QD already.  Of course, the noble thing would be to check anyway...

This is NOT true.  Color Quickdraw is optimized for use with a 68020
processor or better, and it will NOT run on any machine with a 68000.
System 7 contains an updated version of 32-bit QuickDraw, but that is
useless on machines like the Plus, SE, Classic, Portable, PB100.

-- Greg "Browser" Landweber

---------------------------

>From [e-mail] ("K.H.Ping")
Subject: Custom popup menu
Date: Fri, 8 Apr 1994 15:59:42 +0000
Organization: Associated Newspapers

Hi,

can anyone tell me how to do a popup menu (with no popup box) that is
attached to a window bar (like the one that appears if you hold down the
option key and click in the title bar of a window under THINK C 6.0)?

+++++++++++++++++++++++++++

>From [e-mail] (Peter Mattis)
Date: 8 Apr 1994 20:22:53 GMT
Organization: Computer Science Undergrad Assoc., UCBerkeley

In article <[e-mail]>,
K.H.Ping <[e-mail]> wrote:
>Hi,
>
>can anyone tell me how to do a popup menu (with no popup box) that is
>attached to a window bar (like the one that appears if you hold down the
>option key and click in the title bar of a window under THINK C 6.0)?

Well, since the application (you) draws the popup box then if you
don't want one then don't draw it.

To do a popup like the one in THINK C 6.0 all you have to do is
call PopUpMenuSelect(myMenu, vPosition, hPostion, lastItem)

-myMenu is the MenuHandle to your menu
-vPosition is the vertical position of the mouse click.
 (you can adjust this value so that the popup doesn't appear
  below and to the right of the cursor always like it does in
  THINK)
-hPosition is the horizontal position of the mouse click.
 (you can adjust this value just like vPosition)
-lastItem is the number of the last item selected. But since
 there is no "last item" because you don't have a popup box then
 this value should be 1.

Oh, and you call PopUpMenuSelect whenever you determine there has
been an option-click in the title bar of your window.

-Peter Mattis


---------------------------

>From [e-mail] (Molly Gilmore Baldwin)
Subject: Editable pop-up menus
Date: 6 Apr 1994 03:51:34 GMT
Organization: I-Link, Ltd., Des Moines, Iowa, US - 515/255-2754

I'd like to set up a pop-up menu that people could also type a value in
for.  The most common example of what I'm trying to do would be a point
size pop-up, in which you get to pick the common point sizes in 6-point
increments, but where you could also just type in 17.

Does anyone know of some good examples of how to do this?

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Wed, 6 Apr 1994 19:24:31 GMT
Organization: PRZ TU-Berlin

[e-mail] (Molly Gilmore Baldwin) writes:
>I'd like to set up a pop-up menu that people could also type a value in
>for.  The most common example of what I'm trying to do would be a point
>size pop-up, in which you get to pick the common point sizes in 6-point
>increments, but where you could also just type in 17.
>
>Does anyone know of some good examples of how to do this?

There are detailed examples of what this should look like in _Inside
Macintsoh VI_, see Figures 2-30 and 2-31 in the User Interface
chapter. I'm sure the examples are in _NIM_, but I don't have it,
so I can't tell you where to look.

Implementation is pretty straight-forward when you see the examples.
hope this pointer gets you on the right track...
--
Peter Castine                      | One child is shot every two hours
[e-mail]     | in the U.S.A.
                   | Thank you for blocking gun control,
                   | N.R.A.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 7 Apr 1994 00:21:43 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Molly Gilmore Baldwin <[e-mail]> wrote:
>I'd like to set up a pop-up menu that people could also type a value in
>for.  The most common example of what I'm trying to do would be a point
>size pop-up, in which you get to pick the common point sizes in 6-point
>increments, but where you could also just type in 17.
>
>Does anyone know of some good examples of how to do this?

You can use my Popup CDEF. I just sent the current version (1.0b3) to
the info-mac archives and it should be available there in the
/info-mac/dev/src directory within a few days. It was also posted a
few weeks ago to alt.sources.mac and is available in the file

ftpbio.bgsu.edu:/ftp/pub/alt.sources.mac/popupcdef1.0b3.cpt.hqx

The file "PopupCDEF-demo.c" contains sample code that shows how a font
size type-in popup menu can be managed.
--
Ari Halberstadt    [e-mail]     #include <std/disclaimer.h>
"These beetles were long considered to be very rare because very few
entomologists look for beetles in the mountains, in winter, at night,
during snow storms." -- Purves W. K., et al, "Life: The Science of

---------------------------

>From [e-mail] (SusanLesch)
Subject: Females who answer questions?
Date: 18 Mar 1994 04:52:04 -0500
Organization: America Online, Inc. (1-800-827-6364)

Informal survey
  In your own experience, how many females regularly answer
  programming and technical questions in this newsgroup? I
  mean women who often answer (rather than ask) questions
  about programming (or, failing that, anything you would
  term "technical").

  As determined informally in 1993 by a source I cannot
  reveal, there were approximately two qualifiers in
  Macintosh programming on the entire Internet. As
  determined by myself, through logging CompuServe's
  Macintosh Developers' Forums, I found about two also.
  (Just a note that CIS' name fields allow full names,
  unlike AOL and other online services who have only 10
  available characters, which seems to lead to ambiguity in
  gender by name.)

  I do not mean to suggest that these 1000:1? ratios
  reflect all working programmers! I am curious to know if
  my source re: the Internet was being facetious or rather,
  as I tend to suspect, being fairly accurate.

Thanks very much for any replies,
Susan Lesch
(an Internet and C novice)
P.S. Pardon the multiple postings, my mistake.

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Fri, 18 Mar 1994 18:36:49 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (SusanLesch) writes:
>Informal survey
>  In your own experience, how many females regularly answer
>  programming and technical questions in this newsgroup? I
>  mean women who often answer (rather than ask) questions
>  about programming (or, failing that, anything you would
>  term "technical").
Not many, but I think probably a larger percentage than are distributed
amongst the developer community as a whole.  My experience with teaching
gobs of Apple and non-Apple developers is that *at this point* many of
the senior software types are still men, reflecting mostly a generational
lag in women's participation in the field.  After all, my class at MIT
had about 15-20% women, so it isn't suprising that people my age who
post are mostly men.  Plus fewer women seem to like to flame :->
--
-Bill Hofmann                    [e-mail]
 Fresh Software and Instructional Design    [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Francis H. Schiffer 3rd)
Date: Fri, 18 Mar 1994 20:12:51 GMT
Organization: Self

In article <[e-mail]>, [e-mail] (Bill Hofmann) wrote:

> post are mostly men.  Plus fewer women seem to like to flame :->

That is my wife's analysis as to why there are so few women posting on many
of the Usenet groups.  There are many more posts by women on email circles
and/or Usenet groups where the flamage is minimal.
         skip
--
Francis H Schiffer 3rd  [e-mail] - my opinions only, those of
[e-mail]  stscic::schiffer   - my employer are unknown to me

+++++++++++++++++++++++++++

>From [e-mail] (Michael Hore)
Date: 26 Mar 1994 16:55:02 +1000
Organization: Kralizec Dialup Unix Sydney: [phone] V.32bis


[e-mail] (SusanLesch) writes:

>  In your own experience, how many females regularly answer
>  programming and technical questions in this newsgroup? I
>  mean women who often answer (rather than ask) questions
>  about programming (or, failing that, anything you would
>  term "technical").
>
>  As determined informally in 1993 by a source I cannot
>  reveal, there were approximately two qualifiers in
>  Macintosh programming on the entire Internet.

I've been reading c.s.m.p for a couple of years now, and I'd have to
say that that's two more than I've ever noticed.

But I've been to a number of Mac developers' meetings here in
Sydney, Australia, and the ratio there was more like 10:1.

My son is studying CS at university - I must check with him to see
if the ratio is higher there, so that we could say that there's
any sort of trend.

As another poster said, I suspect there's a reluctance to get involved
in a Usenet group with all the flamage etc. that goes on.

[...snip...]
>  I do not mean to suggest that these 1000:1? ratios
>  reflect all working programmers! I am curious to know if
>  my source re: the Internet was being facetious or rather,
>  as I tend to suspect, being fairly accurate.

Looks accurate to me.

>Thanks very much for any replies,
>Susan Lesch
>(an Internet and C novice)

Welcome!

--  Mike.

- --------------------------------------------------------
Mike Hore          [e-mail]
.sig deliberately kept short to minimize .sig/noise ratio.
- --------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Lee Ann Rucker)
Date: 30 Mar 1994 22:16:00 GMT
Organization: ParcPlace

 [e-mail] (SusanLesch) writes:

 >  In your own experience, how many females regularly answer
 >  programming and technical questions in this newsgroup? I
 >  mean women who often answer (rather than ask) questions
 >  about programming (or, failing that, anything you would
 >  term "technical").
 >

I've answered a few questions.  I don't answer often, because questions
generally fall into two categories: so simple that the answer's been posted
before the question gets to my newsreader, or out of my area of expertise -
I see very few questions about the internals of the Smalltalk Virtual
Machine.

LeeAnn Rucker
ParcPlace Systems

+++++++++++++++++++++++++++

>From [e-mail] (SCOTT I CHASE)
Date: 31 Mar 1994 10:52 PST
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA

In article <[e-mail]>, [e-mail] (Lee Ann Rucker) writes...
> [e-mail] (SusanLesch) writes:
>
> >  In your own experience, how many females regularly answer
> >  programming and technical questions in this newsgroup? I
> >  mean women who often answer (rather than ask) questions
> >  about programming (or, failing that, anything you would
> >  term "technical").
> >
>
>I've answered a few questions.  I don't answer often, because questions
>generally fall into two categories: so simple that the answer's been posted
>before the question gets to my newsreader, or out of my area of expertise -
>I see very few questions about the internals of the Smalltalk Virtual
>Machine.

Ah, well that's the kicker.  Most men don't seem to let any of that stop
them.

-Scott
- ------------------                         Physics is not a religion.  If
Scott I. Chase                               it were, we'd have a much easier
[e-mail]                         time raising money. -Leon Lederman

+++++++++++++++++++++++++++

>From [e-mail] (Michael Hore)
Date: 27 Mar 1994 12:56:33 +1000
Organization: Kralizec Dialup Unix Sydney: [phone] V.32bis


Yesterday I wrote:

>My son is studying CS at university - I must check with him to see
>if the ratio is higher there, so that we could say that there's
>any sort of trend.

He said it's about 10:1 there - but most of the 10% females are from
a non English-speaking background (Asian).  So it's possible that
lack of confidence in English is another factor operating here.

This percentage isn't very different from what I remember when I
studied CS nearly 20 years ago, except that the females then were
all from an English-speaking background.  So at least in this part
of the world, if we think the ratio of females "ought" to be rising,
for some reason, then we have a problem.  It just isn't happening.

I know this has gone beyond what the original poster asked, but
interesting nonetheless.

--  Mike.

- --------------------------------------------------------
Mike Hore          [e-mail]
.sig deliberately kept short to minimize .sig/noise ratio.
- --------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Michael Hore)
Date: 29 Mar 1994 16:55:02 +1000
Organization: Kralizec Dialup Unix Sydney: [phone] V.32bis


[e-mail] (SusanLesch) writes:

>  In your own experience, how many females regularly answer
>  programming and technical questions in this newsgroup? I
>  mean women who often answer (rather than ask) questions
>  about programming (or, failing that, anything you would
>  term "technical").
>
>  As determined informally in 1993 by a source I cannot
>  reveal, there were approximately two qualifiers in
>  Macintosh programming on the entire Internet.

I've been reading c.s.m.p for a couple of years now, and I'd have to
say that that's two more than I've ever noticed.

But I've been to a number of Mac developers' meetings here in
Sydney, Australia, and the ratio there was more like 10:1.

My son is studying CS at university - I must check with him to see
if the ratio is higher there, so that we could say that there's
any sort of trend.

As another poster said, I suspect there's a reluctance to get involved
in a Usenet group with all the flamage etc. that goes on.

[...snip...]
>  I do not mean to suggest that these 1000:1? ratios
>  reflect all working programmers! I am curious to know if
>  my source re: the Internet was being facetious or rather,
>  as I tend to suspect, being fairly accurate.

Looks accurate to me.

>Thanks very much for any replies,
>Susan Lesch
>(an Internet and C novice)

Welcome!

--  Mike.

- --------------------------------------------------------
Mike Hore          [e-mail]
.sig deliberately kept short to minimize .sig/noise ratio.
- --------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Michael Hore)
Date: 29 Mar 1994 12:56:33 +1000
Organization: Kralizec Dialup Unix Sydney: [phone] V.32bis


Yesterday I wrote:

>My son is studying CS at university - I must check with him to see
>if the ratio is higher there, so that we could say that there's
>any sort of trend.

He said it's about 10:1 there - but most of the 10% females are from
a non English-speaking background (Asian).  So it's possible that
lack of confidence in English is another factor operating here.

This percentage isn't very different from what I remember when I
studied CS nearly 20 years ago, except that the females then were
all from an English-speaking background.  So at least in this part
of the world, if we think the ratio of females "ought" to be rising,
for some reason, then we have a problem.  It just isn't happening.

I know this has gone beyond what the original poster asked, but
interesting nonetheless.

--  Mike.

- --------------------------------------------------------
Mike Hore          [e-mail]
.sig deliberately kept short to minimize .sig/noise ratio.
- --------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Brad Andrews)
Date: Fri, 8 Apr 1994 16:31:05 GMT
Organization: Chemical Abstracts Service

In article [e-mail], [e-mail] (Michael Hore) writes:
[snip]
]
]As another poster said, I suspect there's a reluctance to get involved
]in a Usenet group with all the flamage etc. that goes on.
]
[snip]

I have been flamed quite a few times by women on other forums, so I doubt
that is the sole reason.  :)

- -

Brad Andrews
[e-mail]
All opinions are strictly mine


---------------------------

>From [e-mail] (James "Newt" Perdue)
Subject: HELP - PICT File ColorTables and Palettes
Date: 7 Apr 1994 10:50:49 -0500
Organization: UTexas Mail-to-News Gateway

I'm pulling my hair out over this one: I'm trying to read Pict files,
display them and have their colors be accurate (256 colors):

I read a PICT file that I created in PhotoShop.

I use DrawPicture to transfer it to an off-screen GWorld.

I use the Picture Utilities GetPictInfo to return a Palette.

I install the Palette and everything is great! Colors are correct.

BUT....

The Picture Utilities takes TOO LONG for a commercial application I am
building.  So,  I need a way to merely access the color table that comes
along with the Pict file and build my own Palette.  Looking at the pmTable
field in the offscreen GWORLD after I do the DrawPicture, it doesn't change
from Pict to Pict.  WHAT TO DO???  I can't believe that there is not a way
to access the colortable directly from the Pict.

I am in desperate need to meet a deadline on this one. Any help would be
appreciated. (The person to help me solve it will get a free CD-ROM I am
developing!)

Thanks

Newt Perdue

Newt Perdue                                           [e-mail]
Rocky Mountain Digital Peeks                        1-303-258-3779
PO Box 1576
Nederland, CO 80466



+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Thu, 7 Apr 94 18:13:42 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> James, [e-mail]
writes:
>from Pict to Pict.  WHAT TO DO???  I can't believe that there is not a
way
>to access the colortable directly from the Pict.

It is possible, although it may not be entirely easy.  You need to root
through the PICT data looking for opcodes $0090 or $0098, which are for
rect-clipped CopyBits, to find the offset to the color table.  The first
block of data for these opcodes is the PixMap, which $32 bytes long.
Following the PixMap is the color table.  Assuming the PICT file just
contains a PixMap from PhotoShop, you might be able to get away with
parsing just a few of the opcodes listed in IM Vol. V to get to the
CopyBits portion.  If not, you will need to parse most or all of the
opcodes.  Most are easy, but a number of them are variable length, which
will complicate things.

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Giles)
Date: Thu, 07 Apr 1994 17:10:59 -0500
Organization: Cornell University Medical College

In article <[e-mail]>, Carl R. Osterwald
<[e-mail]> wrote:

> In article <[e-mail]> James, [e-mail]
> writes:
> >from Pict to Pict.  WHAT TO DO???  I can't believe that there is not a
> >way to access the colortable directly from the Pict.
>
> It is possible, although it may not be entirely easy.  You need to root
> through the PICT data looking for opcodes $0090 or $0098, which are for
> rect-clipped CopyBits, to find the offset to the color table.....

No, no, no!  There is a completely clean, fast way of doing just what you
want.  It's called the QuickDraw Bottleneck, and if you deal with PICTs
extensively, you'll need to know how to do it.  For this case, you write a
StdBits bottleneck, which gets called whenever a CopyBits is performed in
the port, and in that bottleneck, you copy out the color table of the
source PixMap (since that's where the color data is coming from).  The
code will look something like this:

CTabHandle gMyColors;

CTabHandle MyGetPICTColors(myPicture)
{
   CQDProcs myProcs, *oldProcs;

   gMyColors = nil;                   // nil result in case no colors found
   SetPort(myDummyPort);              // point to where drawing won't be seen
   SetStdCProcs(&myProcs);            // set up standard pointers
   myProcs.bitsProc = MyStdBitsProc;  // use UPP here if compiling for PowerPC
   oldProcs = myDummyPort->grafProcs; // save old bottlenecks
   myDummyPort->grafProcs = &myProcs; // install our new bottlenecks
   DrawPicture(myPicture, &destRect); // this does all the magic
   myDummyPort->grafProcs = oldProcs; // restore old bottlenecks
   return gMyColors;                  // return the global result
}

pascal void MyStdBitsProc(BitMap *srcMap, Rect *srcRect, Rect *dstRect,
         short tMode, RgnHandle maskRgn)
{
   PixMapPtr thePixMap = (PixMapPtr)srcMap; // cast as a PixMapPtr

   if (thePixMap->rowBytes & 0x8000) { // verify that this is a color source
      gMyColors = thePixMap->pmTable;  // get the color table handle
      HandToHand(&gMyColors);          // make a copy
   }
}

Note that there's no error checking or niceties here, but this shows you
the general technique.

Aaron
--
Aaron Giles
Power Macintosh & Newton developer
Cornell University Medical College
[e-mail]

---------------------------

>From [e-mail] (Ralf Lehmann)
Subject: Max # of open files
Date: 25 Mar 1994 22:53:08 GMT
Organization: Brigham Young University

>From inside my program, it seems I can only open about 12 files
simultaneously.  What do I need to do (Toolbox call, Control
Panel, whatever...) to open more files than that ?

Thanks,
Ralf.

+++++++++++++++++++++++++++

>From [e-mail] (Shawn O'Donnell)
Date: Sat, 26 Mar 1994 01:45:19 GMT
Organization: M.I.T. Media Laboratory

> it seems I can only open about 12 files simultaneously.  What do I
>  need to do... to open more files than that ?

You can set that in your AUTOEXEC.BAT file.

 :)

--Shawn

P.S.  Do you know why you can't open more?  Are you running out of
memory?  Running out of pointers?  Try calling MoreMasters() and/or
allocating more RAM to the program.

+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Fri, 25 Mar 1994 23:15:25 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Ralf Lehmann) wrote:

> From inside my program, it seems I can only open about 12 files
> simultaneously.  What do I need to do (Toolbox call, Control
> Panel, whatever...) to open more files than that ?
>
> Thanks,
> Ralf.

Are you using ANSI lib calls or regular toolbox OS calls?  If you are using
ANSI (and I'll assume for a moment MPW) then StdCLib's limit of 20 open
files at a time still isn't your problem.  If you are using regular toolbox
calls you still shouldn't have a problem opening 12 files.  Do you have a
ton of fonts in your system?  If you are under System 7, that shouldn't be
a problem.

Can you be specific about why you can't open more than 12 files.  What
error codes are you getting back, etc?

- ------------------------------------------------------------------------
Devon Hubbard                                                Silicon Pilot
[e-mail]                                   Taligent, Inc

+++++++++++++++++++++++++++

>From Aaron Bratcher <[e-mail]>
Date: Sat, 26 Mar 1994 14:01:31 GMT
Organization: University of Chicago

In article <[e-mail]> Shawn O'Donnell, [e-mail] writes:
>You can set that in your AUTOEXEC.BAT file.

That should be the CONFIG.SYS file  ;)

- ------------------------------------------------------------------------
     MegaWatt                         |    _____  _____  _____   _   _
                                      |   |__  / | ___ || ___ \ | | | |
AKA  Aaron L. Bratcher                |     / /  | |_| || |_/ / | | | |
     University of Chicago            |    / /__ | ___ ||  __/  |_| |_|
     [e-mail]  |   |_____||_| |_||_|     (_) (_)
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Ralf Lehmann)
Date: 29 Mar 1994 17:19:44 GMT
Organization: Brigham Young University

OK, OK, here some more information about what I'm trying to do:
I use Think C 5.0, I need to use portable functions, that's why
I use open or fopen from the ANSI library.  Following your
suggestions, I tried to replace the open function by the Create
function, and indeed, it worked (I aborted the program after 500
had been created... what a mess to put them in the trash can...)
So it seems that Think C's library is at fault.  Why would it
limit the # of open files ? Isn't it just calling Create or FSOpen ?
Here is my little test program:

#include <stdio.h>
#include <unix.h>
#include <fcntl.h>

void main ()
    {
    int i;
    char name[5];

    for (i = 0; ; i++)
        {
        sprintf (name, "_t%d", i);
        if (open (name, O_CREAT) == -1) break;
        }
    printf ("max open files: %d\n", i);
    }

+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Tue, 29 Mar 1994 21:59:31 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

: So it seems that Think C's library is at fault.  Why would it
: limit the # of open files ? Isn't it just calling Create or FSOpen ?

Under system 6, the number of open files on a mac is limited. With the
standard configuration, you would be able to open about 12 files (that
is, depending on how many other files are opened by the system and other
apps). One way to fix this is by using SuitCase, which has a power user
setting somewhere that allows you to up the max # of open files.
This I know for sure.
What I don't know for sure:
I think/seem_to_remember that under system 7 the FCB's are dynamically
allocated, so there is no longer a limit to the number of open files.
Again, I'm not sure. Are you using system 7?

Btw. I think the reason why your little test program works is because you
only create files, but you do not actually keep them open.

Marcel


+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Fri, 1 Apr 1994 06:58:37 GMT
Organization: Little to none

In article <[e-mail]>,
[e-mail] (Ralf Lehmann) wrote:

> From inside my program, it seems I can only open about 12 files
> simultaneously.  What do I need to do (Toolbox call, Control
> Panel, whatever...) to open more files than that ?

Sounds like you're using C's stdio. There's this comment thing inside of
StdIO.h that you might want to read:

/*
 *    The minimum number of files that a program is guaranteed to be able to
have
 *    open simultaneously (including the pre-opened stdin, stdout, and
stderr).
 *    The numbers are listed in Inside Macintosh, page IV-178, as:
 *    64K ROM, 128K Macintosh        12 files
 *    64K ROM, 512K Macintosh        40 files
 *    128K ROM                    40 files per volume
 */

#define FOPEN_MAX    12

That's from MPW. Symantec C 6.0 sets this to 15, without any comments.

How do you fix this? If you're using MPW, you'll probably have to rewrite
your program to either a) live with the limit or b) using the File Manager
calls. If you're using THINK C, you can probably just recompile the
libraries.

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team
Newton

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 7 Apr 94 11:02:25
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:

> In article <[e-mail]>,
> [e-mail] (Ralf Lehmann) wrote:

>> From inside my program, it seems I can only open about 12 files
>> simultaneously.  What do I need to do (Toolbox call, Control
>> Panel, whatever...) to open more files than that ?

> Sounds like you're using C's stdio. There's this comment thing inside of
> StdIO.h that you might want to read:
>[...]
> #define FOPEN_MAX    12

> That's from MPW. Symantec C 6.0 sets this to 15, without any comments.

> How do you fix this? If you're using MPW, you'll probably have to rewrite
> your program to either a) live with the limit or b) using the File Manager
> calls.

Alternatively, you can do the following, at least with MPW 3.2 and MPW 3.3:

/* Allocate more stdio buffers */

FILE _iob[64] = {
    0, nil, nil, nil, 0, _IOREAD,         0,
    0, nil, nil, nil, 0, _IOWRT,          1,
    0, nil, nil, nil, 0, _IOWRT+_IOLBF,    2
};

FILE * _lastbuf = _iob + 64;

The Linker will warn you, forgive him if you know what you're doing :-)

Matthias

- ---
Matthias Neeracher                                  [e-mail]
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

---------------------------

>From [e-mail] (James West)
Subject: Proper QT PICT creation?
Date: 31 Mar 1994 20:59:20 GMT
Organization: Augsburg College

I am trying to create a custom interface for a digital camera that
downloads a JPEG (or JFIF) image via the serial port. So far, it is set up
so that an appleevent triggers the camera to snap a photo, and another
appleevent orders the camera to download the image. So far so good.

My challenge is to convert the photo to a QT PICT. Right now I have had
some success by canabalizing existing JPEG PICT's and pasting the opcodes
onto the JFIF data. I realize this is very bad technique, and would like to
be able to do this in a proper fashion.

I understand the basic process for creating a PICT file containing a
compressed image, but I am somewhat confused when it comes to the
imagedesc(?) structure that needs to be passed with the decompressImage
funtion. Since quicktime did not compress this image (which is usually when
the imagedesc is created), what do I use for this value? Can I steal a
imagedesc from an existing JPEG PICT and use that after some tweaking to my
specifications (height and width, ect.)? This option seems to kind of make
me a cannibal again. Are there published standards for creating this
structure?

I would also love to have this QT PICT version of this image pasted onto
the clipboard for further use. Is this supported and is there any way this
could be done with my image grabbing app in the background?

ANY pointers and/or kicks in the side of the head are welcome. Thanks

--
James West                             ***** I like Cacti... ****
Augsburg College Graphic Center
731 21st Ave S
Mpls. MN 55454
[e-mail]                      ********  OUTCH!! ********

+++++++++++++++++++++++++++

>From [e-mail] (MarkHanrek)
Date: 1 Apr 1994 13:31:04 -0500
Organization: America Online, Inc. (1-800-827-6364)

On the QuickTime CD, there is source code for taking a standard JFIF file, and
feeding it to one of the Quicktime routines, FDecompress I believe, so that you
end up with a normal everyday PixMap of the image.

( Note that the resulting image quality is not as good as is obtainable with
the standard JPEG decompression routines available from the Independent JPEG
Group (uunet.uu.net) . This may change with the impending release of QuickTime
2.0 ).

At this point, you have a straight pixmap of your image, and the following
"intermediate" steps have nothing to do with QuickTime, or JPEG.

You have a PixMap of the image, and you can easily turn it into a Macintosh
picture using the standard method of opening a new picture and copybitsing the
image to itself, and closing the picture, yielding a picture.

You can save this picture to the clipboard, draw it to the screen, or write it
to a PICT file.

To put it on disk as a QT Compressed PICT, you use additional functions found
in the QuickTime toolkit to compress the pixmap and write out a QT compressed
file.

If at all possible, you really do want try to stand on the shoulders of the
routines provided along with the QuickTime CD's example source code.

I have done a wide variety of things in this regard, and I couldn't answer your
question about ImageDescriptors, most likely because I took the example source
code and treated it as a black box, and have never had to deal with knowing
these details, thank god! :)

See if you can't get a hold of the stuff on the QuickTime Developer's Toolkit
CD. ( or whatever it is called exactly ).

Hope this helps.

Mark Hanrek


+++++++++++++++++++++++++++

>From Steve Bryan <[e-mail]>
Date: Sat, 2 Apr 1994 05:14:22 GMT
Organization: Sexton Software

In article <west-310394144925@141.224.192.172> James West,
[e-mail] writes:
>I understand the basic process for creating a PICT file containing a
>compressed image, but I am somewhat confused when it comes to the
>imagedesc(?) structure that needs to be passed with the decompressImage
>funtion. Since quicktime did not compress this image (which is usually
when
>the imagedesc is created), what do I use for this value? Can I steal a
>imagedesc from an existing JPEG PICT and use that after some tweaking to
my
>specifications (height and width, ect.)? This option seems to kind of
make
>me a cannibal again. Are there published standards for creating this
>structure?

You're probably already aware of it but just in case (and for others)
there is significant discussion of this topic in Inside Macintosh:
QuickTime starting on page 3-24. A good (the best?) general reference for
JPEG  is "JPEG Still Image Data Compression Standard" by Pennebaker and
Mitchell from Van Nostrand (ISBN 0-442-01272-1). If you're looking for
the book in Minneapolis try Borders Books at Hennepin & Lake, they have
it in stock.
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 5 Apr 94 12:40:49 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <2nhp98$[e-mail]>, [e-mail] (MarkHanrek) writes:
> On the QuickTime CD, there is source code for taking a standard JFIF file, and
> feeding it to one of the Quicktime routines, FDecompress I believe, so that you
> end up with a normal everyday PixMap of the image.
>
...
>
> You have a PixMap of the image, and you can easily turn it into a Macintosh
> picture using the standard method of opening a new picture and copybitsing the
> image to itself, and closing the picture, yielding a picture.
>
> You can save this picture to the clipboard, draw it to the screen, or write it
> to a PICT file.
>
> To put it on disk as a QT Compressed PICT, you use additional functions found
> in the QuickTime toolkit to compress the pixmap and write out a QT compressed
> file.

Note that the decompress calls are drawing calls. This means that, if you have
a QuickDraw picture open, the _compressed_ data will be recorded directly in
the picture. This is better than decompressing the data into a PixMap, and
then recompressing it, with the consequent loss of even more image quality.

I do actually have some code somewhere that fakes an ImageDescription structure
for a JPEG image. I think it still works. :-)

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (James West)
Date: 5 Apr 1994 16:57:28 GMT
Organization: Augsburg College

Great replies- thanks folks! Here's where I'm at...

> Note that the decompress calls are drawing calls. This means that, if you have
> a QuickDraw picture open, the _compressed_ data will be recorded directly in
> the picture. This is better than decompressing the data into a PixMap, and
> then recompressing it, with the consequent loss of even more image quality.
>
> I do actually have some code somewhere that fakes an ImageDescription structure
> for a JPEG image. I think it still works. :-)

I did end up going this route, because I did want the data to be compressed
and avoid the data loss of recompression. The ImageDescription that I
created also seems to work fine for the DecompressImage call recorded to a
picture. I don't think there should be a problem using this option in this
application, since the resolution and depth of my JPEG data from this
camera will always be constant.

My only problem now is trying to get the picture pasted to the clipboard
when this application is running in the background. Works fine when it's a
foreground app, but while backgrounding it either silently fails to get the
picture onto the scrap, or drops into MacsBug (but that may be another
problem :-(   ).
--

James West                             ***** I like Cacti... ****
Augsburg College Graphic Center
731 21st Ave S
Mpls. MN 55454
[e-mail]                      ********  OUTCH!! ********

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Apr 94 11:34:24 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, I said:
>
> Note that the decompress calls are drawing calls. This means that, if you have
> a QuickDraw picture open, the _compressed_ data will be recorded directly in
> the picture. This is better than decompressing the data into a PixMap, and
> then recompressing it, with the consequent loss of even more image quality.
>
> I do actually have some code somewhere that fakes an ImageDescription structure
> for a JPEG image. I think it still works. :-)

OK, here are some relevant extracts from a quick-and-dirty tool I wrote a
couple of years ago for turning JPEG files into PICT files. I discovered very
little of this information myself: in particular, Dolf Starreveld at Storm
Technologies was kind enough to tell me enough about JPEG and JFIF formats to
make this work.

Note: "JpegData" points to a buffer containing the contents of the JPEG
file. The number of bytes is in "JpegDataSize". First you need to scan this,
looking for the bounds of the image. You don't really need the whole file for
this: the information should be present somewhere within the first 1K:

    PROCEDURE FindPictureSize;
      (* scans the JPEG data, looking for the information about
    the dimensions of the image. *)

    VAR
        NextByte, DataEnd : ADDRESS;
        TwoBytes :
        RECORD
        CASE : CARDINAL OF
        | 1:
            HighByte, LowByte : BYTE;
        | 2:
            SignedWord : INTEGER
        END (*CASE*)
        END (*RECORD*);
        Msg, TempStr : Str255;

    BEGIN
    NextByte := JpegData;
    DataEnd := JpegData + JpegDataSize;
    LOOP
        IF NextByte = DataEnd THEN
        ErrorLiteral('couldnUt determine JPEG image bounds', ProcessingError);
        EXIT
        END (*IF*);
        IF ORD(NextByte^) = 0FFH THEN
        INC(NextByte);
        IF NextByte = DataEnd THEN
            ErrorLiteral('malformed JPEG file', ProcessingError);
            EXIT
        END (*IF*);
        IF ORD(NextByte^) = 0C0H THEN
            INC(NextByte);
            IF DataEnd - NextByte >= 7 THEN
            NextByte := NextByte + 3;
            TwoBytes.HighByte := NextByte^;
            INC(NextByte);
            TwoBytes.LowByte := NextByte^;
            INC(NextByte);
            PictureSize.v := TwoBytes.SignedWord;
            TwoBytes.HighByte := NextByte^;
            INC(NextByte);
            TwoBytes.LowByte := NextByte^;
            INC(NextByte);
            PictureSize.h := TwoBytes.SignedWord;
            MakeCounted('Image size (h, v) = (', Msg);
            NumToString(PictureSize.h, TempStr);
            AppendCounted(ADR(TempStr), Msg);
            AppendtoCounted(', ', Msg);
            NumToString(PictureSize.v, TempStr);
            AppendCounted(ADR(TempStr), Msg);
            AppendtoCounted(')', Msg);
            ErrorString(Msg, Success);
            EXIT
            ELSE
            ErrorLiteral('malformed bounds info', ProcessingError);
            EXIT
            END (*IF*)
        END (*IF*)
        ELSE
        INC(NextByte)
        END (*IF*)
    END (*LOOP*)
    END FindPictureSize;

Then, you build the fake ImageDescription and record the data into a
picture:

    PROCEDURE BuildPicture;

    VAR
        Description : ImageDescriptionHandle;
        PictureBounds : Rect;
        TempPort : CGrafPort;

    BEGIN (*BuildPicture*)
    Description := NewHandle(SIZE(ImageDescription));
    Description^^.idSize := SIZE(ImageDescription);
    Description^^.cType := 06A706567H (* 'jpeg' *);
    Description^^.resvd1 := 0;
    Description^^.resvd2 := 0;
    Description^^.dataRefIndex := 0;
    Description^^.version := 0;
    Description^^.revisionLevel := 0;
    Description^^.vendor := 06170706CH (* 'appl' *);
    Description^^.temporalQuality := ImageCompression.codecMinQuality;
    Description^^.spatialQuality := ImageCompression.codecNormalQuality; (* is this significant? *)
    Description^^.width := PictureSize.h;
    Description^^.height := PictureSize.v;
    Description^^.hRes := FixRatio(72, 1);
    Description^^.vRes := FixRatio(72, 1);
    Description^^.dataSize := JpegDataSize;
    Description^^.frameCount := 1;
    Description^^.name[0] := 0C;
    Description^^.depth := 32; (* I hope! *)
    Description^^.clutID := -1;
    OpenCPortVar(TempPort);
    PictureBounds.top := 0;
    PictureBounds.left := 0;
    PictureBounds.botRight := PictureSize;
    ClipRect(PictureBounds);
    Picture := OpenPicture(PictureBounds);
    Err := DecompressImage
      (
        (*data :=*) JpegData,
        (*desc :=*) Description,
        (*dst :=*) TempPort.portPixMap,
        (*srcRect :=*) ADR(PictureBounds),
        (*@dstRect :=*) PictureBounds,
        (*mode :=*) QuickDraw.ditherCopy,
        (*mask :=*) NIL
      );
    ClosePicture;
    IF Err <> noErr THEN
        OSError(Err)
    END (*IF*);
    CloseCPortVar(TempPort);
    DisposeHandle(Description)
    END BuildPicture;

Hope that helps.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

---------------------------

>From [e-mail] (Heikki Leinonen)
Subject: Q: Changing font & size of dialog items
Date: 31 Mar 1994 13:18:34 GMT
Organization: Helsinki University of Technology, Finland


  Greetings from the depths of Dialog Manager

  (possible FAQ alert...)

  So I make my DLOGs and DITLs with ResEdit, call GetNewDialog
  and ModalDialog in my program and so on. And then comes the
  tough part: is there a SIMPLE way to make *all* the texts
  (meaning static and edit texts, button and check box titles etc.)
  in my dialog something else than Chicago 12?  SetDAFont seems
  to handle only the font name, not the size. And it won't
  change the controls. If I created the controls myself, I could
  add the useWFont constant to controls' definition values. But
  making the layout with ResEdit is SOOOOO easy...

  Anyone have any bright ideas on this one?


  Heikki Leinonen

  [e-mail]
  Helsinki University of Technology
  Finland




+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Thu, 31 Mar 1994 12:06:05 -0600
Organization: University of Illinois at Urbana-Champaign

In article <2neija$[e-mail]>, [e-mail] (Heikki
Leinonen) wrote:

>  So I make my DLOGs and DITLs with ResEdit, call GetNewDialog
>  and ModalDialog in my program and so on. And then comes the
>  tough part: is there a SIMPLE way to make *all* the texts
>  (meaning static and edit texts, button and check box titles etc.)
>  in my dialog something else than Chicago 12?

You need to create an ictb resource. Unfortunately, ResEdit does not have
an ictb editor. Resourserer (sp?) is able to create them, or you can use
Rez.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Vampire)
Date: Fri, 1 Apr 1994 00:41:37 GMT
Organization: Pennangalan Software


In article <2neija$[e-mail]> [e-mail] (Heikki Leinonen)
writes:
>  tough part: is there a SIMPLE way to make *all* the texts
>  (meaning static and edit texts, button and check box titles etc.)
>  in my dialog something else than Chicago 12?  SetDAFont seems
>  to handle only the font name, not the size. And it won't
>  change the controls.

All objects in a Dialog box use the font of the Dialog's GrafPort. SetDAFont()
changes a global setting for the font to use in ALL subsequent Dialog Manager
Windows.

What you need to do is set the font and textsize of the GrafPort directly. The
way to do this is with the QuickDraw calls TextFont() and TextSize() [See IM
Vol 1 - p171]. These routines affect the ~current~ port, so you'll need to do
something like this...

[C Code]
DialogPtr    pMyDialog = GetNewDialog(blah blah blah);

    GetPort(&SavePort);
    SetPort(pMyDialog);
    TextFont(rhubarb);
    Textsize(baloney);
    SetPort(SavePort);
    ShowWindow(pMyDialog);

You need the code to save and restore the current grafport, as the Dialog
Manager normally does this for you, so it is probably missing from any code you
have written (DialogSelect() and ModalDialog() handle the grafports
automatically).

The above ~should~ work...I ~think~ it does for me, but I haven't written
anything recently that used it...

PS. If you only ant to change the text of editText items, you can do it by
directly modifying the contents of the Dialog's TERec structure...you can get
this by casting your DialogPtr to type DialogPeek, and dereferencing it as
follows:

TEHandle myDialogText = ((DialogPeek) pMyDialog)->textH;    [IM Vol 1, p408]

Best of luck...

=============================================================================
                                  |"If I knock on your door, you're a fool;
         VAMPIRE                  | if you invite me in, you're a dead fool"
  (Pennangalan Software)          |  My dust resides @crypt.demon.co.uk
=============================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Fri, 01 Apr 1994 14:04:27 -0600
Organization: I-Link, Ltd.

In article <[e-mail]>, [e-mail] (Vampire)
wrote:

> In article <2neija$[e-mail]> [e-mail] (Heikki Leinonen)
> writes:
> >  tough part: is there a SIMPLE way to make *all* the texts
> >  (meaning static and edit texts, button and check box titles etc.)
> >  in my dialog something else than Chicago 12?  SetDAFont seems
> >  to handle only the font name, not the size. And it won't
> >  change the controls.
>
> All objects in a Dialog box use the font of the Dialog's GrafPort. SetDAFont()
> changes a global setting for the font to use in ALL subsequent Dialog Manager
> Windows.
>
> What you need to do is set the font and textsize of the GrafPort directly. The
> way to do this is with the QuickDraw calls TextFont() and TextSize() [See IM
> Vol 1 - p171]. These routines affect the ~current~ port, so you'll need to do
> something like this...
>
> [C Code]
> DialogPtr    pMyDialog = GetNewDialog(blah blah blah);
>
>     GetPort(&SavePort);
>     SetPort(pMyDialog);
>     TextFont(rhubarb);
>     Textsize(baloney);
>     SetPort(SavePort);
>     ShowWindow(pMyDialog);

Actually, that will only change the Static and Edit text items, not the
controls (like buttons and checkboxes) in the dialog.  The only way that I
know of to change the font/size in the controls is to use CNTL resources
for each of those items and set the flag that tells the controls to use the
window's font.  (Note however that you must still change the port's
font/size for this to work.)

_troy
//////// //////___Troy [e-mail]__ //
  //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
 //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Fri, 01 Apr 1994 15:03:21 -0600
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail] (Vampire) wrote:

>All objects in a Dialog box use the font of the Dialog's GrafPort.
Not if you use an ictb resource.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Newman)
Date: 1 Apr 1994 14:28:53 -0600
Organization: The University of Texas - Austin

In addition to what has been mentioned earlier, I was doing this the other
day, and I discovered an additional twist that noone has mentioned. If your
dialog includes an editable text box, you must set the text of that box to
the same text as the buttons (that is, the textFont must be the same for the
grafPort and for the TErec), otherwise, textedit will reset the font for the
grafPort.

Someone can correct me if they *know* better, since I'm a novice at such
things, but that was my diagnosis of the problem, and since I corrected
it, things work great.

>>Dave

P.S. Thanks to Leonard Rosenthal for pointing me in the right direction
when I had this problem, otherwise I wouldn't be able to answer.

+++++++++++++++++++++++++++

>From [e-mail] (Adam Skwersky)
Date: 1 Apr 1994 19:39:36 GMT
Organization: Massachvsetts Institvte of Technology

In article <2neija$[e-mail]>, [e-mail] (Heikki
Leinonen) wrote:

>. If I created the controls myself, I could
>   add the useWFont constant to controls' definition values. But
>   making the layout with ResEdit is SOOOOO easy...
>
>   Anyone have any bright ideas on this one?


I have had a similar problem. I was trying to use the custom Connection
Manager
Setup routines that add DITL's to your dialog and you use the DITL's to
setup up a certain tool. The items are all SUPPOSED to be in geneva 9, and
when you call the toolbox command CMChoose() thats what you get. However
if I were to add the DITL's to my OWN dialog, they all come out in
Chicago 12. I thought about trying to go through each dialog item and
changing its procID to procID+useWFont, but I could not even find the
procID field in the ControlHandle record! I'm really lost with this as
well,
and I do not think it is a FAQ. Do any Mac gurus out there know how to go
through a bunch of controls (dialog items) and change their fonts and
sizes?

Adam Skwersky
[e-mail]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (HRodstein)
Date: 2 Apr 1994 01:09:03 -0500
Organization: America Online, Inc. (1-800-827-6364)

I asked this question of Apple developer support a couple of months
ago. They told me I should use an ictb resource. This is documented
on page 279 of Inside Mac V. There are two problems.

First, neither ResEdit nor Rez know how to make ictb resources.
Resourcer does  know how to make it so you would either need
to hack it in hex or buy Resourcer.

Second, it will not work on machines without color QuickDraw
such as Mac Plus under System 6.

The technique of setting the font and text size of both the
dialog's grafPort and setting the font and text size of the
dialog's TextEdit record also seems to work if you want
to change editText and statText items only.

Howard Rodstein

+++++++++++++++++++++++++++

>From [e-mail] (Rob Terrell)
Date: 4 Apr 1994 17:28:45 GMT
Organization: Jecta Development Corp.

In article <2nj25v$[e-mail]>
[e-mail] (HRodstein) writes:

> First, neither ResEdit nor Rez know how to make ictb resources.
> Resourcer does  know how to make it so you would either need
> to hack it in hex or buy Resourcer.

I remember when I had to make these by hand a few years back...that was
no fun. So the real answer is...we need someone to cough up a ResEdit
'ictb' editor.

Does anyone have such a beast they would be willing to contribute to
sumex?

Rob

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 7 Apr 1994 01:15:49 GMT
Organization: Apple Computer

Heikki Leinonen, [e-mail] writes:
>   is there a SIMPLE way to make *all* the texts
>   (meaning static and edit texts, button and check box titles etc.)
>   in my dialog something else than Chicago 12?

As has been said, you can use an 'ictb' resource. Unfortunately (maybe) these
aren't recognized on 68000 systems so if your program is supposed to run on
old hardware you can't use them.

One alternative thing I've done is to set the "useWFont" bit of the
variationCodes of the control items; this makes their text appear in the
current grafPort's font/size/style instead of the system font. Unfortunately,
to do this you have to temporarily patch NewControl during your call to
GetNewDialog, and in the patch set the appropriate bit in the variationCode
before calling the old trap address. It's a wee bit ugly but works fine.

Another solution is simply not using the Dialog Manager. This is really
feasible only if you have a framework (MacApp, TCL, PowerPlant...) that will
let you set up complex windows easily. I did this approach for the
AppleScript Script Editor, with a hand-rolled framework. It works great, but
the overhead is a bit high for a small app.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] ( Florent Pillet)
Date: Thu, 7 Apr 1994 13:10:40 GMT
Organization: France-Teaser

References: <[e-mail]>

[e-mail] (Adam Skwersky) writes:
> In article <2neija$[e-mail]>, [e-mail] (Heikki
> Leinonen) wrote:
>
> >. If I created the controls myself, I could
> >   add the useWFont constant to controls' definition values. But
> >   making the layout with ResEdit is SOOOOO easy...
> >
> >   Anyone have any bright ideas on this one?
>
>
> I have had a similar problem. I was trying to use the custom Connection
> Manager
> Setup routines that add DITL's to your dialog and you use the DITL's to
> setup up a certain tool. The items are all SUPPOSED to be in geneva 9, and
> when you call the toolbox command CMChoose() thats what you get. However
> if I were to add the DITL's to my OWN dialog, they all come out in
> Chicago 12. I thought about trying to go through each dialog item and
> changing its procID to procID+useWFont, but I could not even find the
> procID field in the ControlHandle record! I'm really lost with this as
> well,
> and I do not think it is a FAQ. Do any Mac gurus out there know how to go
> through a bunch of controls (dialog items) and change their fonts and
> sizes?
>
> Adam Skwersky
> [e-mail]
> [e-mail]

 I have EXACTLY the same problem and I'm managing to setup my custom
 connection manager setup dialog box.

 Well, it mostly works. I followed the example given in "IM: CTB", but
 before doing any update in the CTB part of the dialog box, or before
 calling any CTB function, I call a function of mine, which uses the
 Script Manager to set the current font attributes. It works for
 the control texts but not for the static or edit texts. The only
 way I've found to set the static & edit text font is to modify
 the SysFontFam & SysFontSiz low-memory variables but this is dirty
 and it also affects the menu bar (sometimes) and other window's title
 bar (always).

 Here is the function I use to set everything up before calling the
 connection manager:

static void SetCTBToolEnv(dialogInfoPtr infoP,DialogPtr theDialog)
{
  short script;
  unsigned long fnt;

  UseResFile(0);
  SetPort((GrafPtr)theDialog);

  fnt = ((long)geneva << 16L) | 9L;
  script = FontScript();

  SetScriptVariable(script,smScriptMonoFondSize,fnt);
  SetScriptVariable(script,smScriptPrefFondSize,fnt);
  SetScriptVariable(script,smScriptSmallFondSize,fnt);
  SetScriptVariable(script,smScriptSysFondSize,fnt);
  SetScriptVariable(script,smScriptAppFondSize,fnt);

  TextFont(geneva);
  TextSize(9);
}



  Well, this is a hack but it works. I still have to find how setup the
  Edit & Static Text font so it affects only my window.

  Anyway, those f****g bastards at Apple who have designed the CTB and
  implemented it should be thrown on a desert island. I can't imagine how
  they could do such a bad design and I don't understand why they decided
  to document only the easiest-to-use parts of their tools.

  Apple often makes beautiful software. This one was an exception. Ugly.


  Hope the code helps,
  Florent.

--

  Florent Pillet, freelance programmer.             ____/|
  Location: Paris, France.                          \ o O|
    E-Mail: [e-mail]                 =(_T_)=
                                                       U

+++++++++++++++++++++++++++

>From [e-mail] (Ed Walker)
Date: Thu, 7 Apr 1994 13:31:45 GMT
Organization: SAS Institute Inc.


In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
>Heikki Leinonen, [e-mail] writes:
>>   is there a SIMPLE way to make *all* the texts
>>   (meaning static and edit texts, button and check box titles etc.)
>>   in my dialog something else than Chicago 12?
>

stuff deleted

>
>--Jens Alfke
>  jens_alfke@powertalk              Rebel girl, rebel girl,
>            .apple.com              Rebel girl you are the queen of my world

One thing that works for me is SetDAFont(n) before opening the dialog.
This only changes the font for static and edit text. Once your
dialog is open you can use SetDAFont(0) to restore the system font
for your other dialogs (like alerts) and it won't affect the opened
dialogs.

Ed                                               >'<
                                                (o o)
+---------------------------------------------o0o-U-o0o---------------+
| [e-mail]    (home)     | It is impossible to make anything  |
| [e-mail]  (work)     | foolproof; fools are so ingenious. |
+---------------------------------------------oo0---0oo---------------+

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 7 Apr 1994 14:30:59 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] ( Florent Pillet) writes:

>  Anyway, those f****g bastards at Apple who have designed the CTB and
>  implemented it should be thrown on a desert island. I can't imagine how
>  they could do such a bad design and I don't understand why they decided
>  to document only the easiest-to-use parts of their tools.

That obviously stands for your opinion, but I feel this is a rather
wonderful part of system software, and it solves a whole class of
problems which ANY other operating system simply ignores (at worst)
or doesn't really have any coherent support for (at best)

You are of course welcome to write your own code, but using such
language about Apple engineers will not improve your standing in
this newsgroup.

PS: There has been rumors about the CTB dying, but when I checked
with DTS, it seems those rumors are false. The CTB will not disappear
from the OS for the forseeable future, and it will "at some point in
time" "probably" become native; it's just no sense in doing so now,
since there are no native tools and the context switches would just
kill it.

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
  "After I first used the Mac, I had a dream in which I would walk up to
   people, touch them, and they'd turn black. Then I could talk to them."
                     -- Anon

---------------------------

>From [e-mail] (Herschel A Gelman)
Subject: Removing PowerPC code from a fat binary
Date: 1 Apr 94 22:15:40 GMT
Organization: University of Pittsburgh

Well, the subject line says most of it.  Is there an easy way to do this?  I'd
rather have the 680x0 code only, rather than waste already minimal hard drive
space.

I grabbed the fat version of JPEGView, and it seems like the 601 code is all in
the data fork.  Weird.  An older version I found had nothing in the data fork,
so it seems safe to just cut that out.  Which I haven't gotten around to doing
yet.  (I assume I'd have to change it to type text, then go in with a word
processor and select-all and delete -- is there an easier way??)

Is there anything in the resource fork?  How would a program distinguish
between data and PowerPC code, and how would I distinguish if I'm trying to
shorten the program like this?

I'd prefer E-mail responses...  gracias..


--
- -------------- Herschel Gelman ----------- [e-mail] -----------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 2 Apr 1994 08:01:04 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Herschel A Gelman) writes:

>Well, the subject line says most of it.  Is there an easy way to do this?  I'd
>rather have the 680x0 code only, rather than waste already minimal hard drive
>space.

1) Set the data fork length to 0 bytes
2) Remove the cfrg resource

Done.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
  "It was, in fact, cool as all get-out.  Fortunately it was a little
   too late (historically speaking) to be groovy."
                     -- Dennis Pelton

+++++++++++++++++++++++++++

>From [e-mail] (Jack Littleton)
Date: Mon, 4 Apr 1994 15:31:35 GMT
Organization: Law Offices of Buttafuoco, Bobbit and Harding

Jon Wdtte ([e-mail]) wrote:
: 1) Set the data fork length to 0 bytes
: 2) Remove the cfrg resource

: Done.

To be really safe, I'd check the offset field of the cfrg resource before
doing this.  It is still possible, although not recommended, to store data
in the data fork of a fat binary.  The offset field in the cfrg tells the
CFM where the actual code starts (or other code fragments start).  If the
offset is zero, as it is for most apps I've seen, go ahead and zap the
data fork.
--
Jack Littleton                                               [e-mail]
PowerPC and/or 68k Debugger Engineer                      Apple Computer, Inc.
(WARNING: Above title can change suddenly and without warning)

     ### This, and all other posts generated by myself, are in no ###
     ### way meant to be an official view of Apple Computer, Inc. ###

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 04 Apr 1994 11:02:42 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Jack Littleton)
wrote:

> Jon Wtte ([e-mail]) wrote:
> : 1) Set the data fork length to 0 bytes
> : 2) Remove the cfrg resource
>
> : Done.
>
> To be really safe, I'd check the offset field of the cfrg resource before
> doing this.  It is still possible, although not recommended, to store data
> in the data fork of a fat binary.  The offset field in the cfrg tells the
> CFM where the actual code starts (or other code fragments start).  If the
> offset is zero, as it is for most apps I've seen, go ahead and zap the
> data fork.

If you're going to go to the trouble of checking the offset field, also
check the length field...the fragment can be at offset zero with other
stuff after it.  If the length field is zero (kWholeFork, or some name like
that...fancy for 0), THEN the data fork is all [one] application fragment.

Or...try it "blind" and see whether the application objects.  [It may even
be worth it with JPEGView (the app in the original question):  almost 300K
out of the about 775K file is data fork.]
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail]. (Allan Foster)
Date: 4 Apr 1994 21:26:40 GMT
Organization: Guru Inc

In article <[e-mail]>
[e-mail] (John W. Baxter) writes:

> In article <[e-mail]>, [e-mail] (Jack Littleton)
> wrote:
>
> > Jon Wtte ([e-mail]) wrote:
> > : 1) Set the data fork length to 0 bytes
> > : 2) Remove the cfrg resource
> >
> > : Done.
> >
> > To be really safe, I'd check the offset field of the cfrg resource before
> > doing this.  It is still possible, although not recommended, to store data
> > in the data fork of a fat binary.  The offset field in the cfrg tells the
> > CFM where the actual code starts (or other code fragments start).  If the
> > offset is zero, as it is for most apps I've seen, go ahead and zap the
> > data fork.
>
> If you're going to go to the trouble of checking the offset field, also
> check the length field...the fragment can be at offset zero with other
> stuff after it.  If the length field is zero (kWholeFork, or some name like
> that...fancy for 0), THEN the data fork is all [one] application fragment.
>
> Or...try it "blind" and see whether the application objects.  [It may even
> be worth it with JPEGView (the app in the original question):  almost 300K
> out of the about 775K file is data fork.]
> --

If you REALLY want to do the right thing,  then you may want to look to
see if there are any other cfrg resources in the resource fork.  Since
there is nothing stopping anyone from having MULTIPLE containers in the
data fork, you may have to update the other cfrg resources if you
delete stuff.....

And nothing says it has to start at 0 either!
- --------------------------------------------------------
I am responsible for what I say and do. -- Allan Foster --

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: 4 Apr 1994 23:43:30 -0500
Organization: I-Link, Ltd., Des Moines, IA, USA - 515/255-2754

In article <2nq0mg$[e-mail]>,
Allan Foster <[e-mail].> wrote:
>In article <[e-mail]>
>[e-mail] (John W. Baxter) writes:
>
>> In article <[e-mail]>, [e-mail] (Jack Littleton)
>> wrote:
>>
>> > Jon Wtte ([e-mail]) wrote:
>> > : 1) Set the data fork length to 0 bytes
>> > : 2) Remove the cfrg resource
>> >
>> > : Done.
>> >
>> > To be really safe, I'd check the offset field of the cfrg resource before
>> > doing this.  It is still possible, although not recommended, to store data
>> > in the data fork of a fat binary.  The offset field in the cfrg tells the
>> > CFM where the actual code starts (or other code fragments start).  If the
>> > offset is zero, as it is for most apps I've seen, go ahead and zap the
>> > data fork.
>>
>> If you're going to go to the trouble of checking the offset field, also
>> check the length field...the fragment can be at offset zero with other
>> stuff after it.  If the length field is zero (kWholeFork, or some name like
>> that...fancy for 0), THEN the data fork is all [one] application fragment.
>>
>> Or...try it "blind" and see whether the application objects.  [It may even
>> be worth it with JPEGView (the app in the original question):  almost 300K
>> out of the about 775K file is data fork.]
>> --
>
>If you REALLY want to do the right thing,  then you may want to look to
>see if there are any other cfrg resources in the resource fork.  Since
>there is nothing stopping anyone from having MULTIPLE containers in the
>data fork, you may have to update the other cfrg resources if you
>delete stuff.....

There shouldn't be more than one 'cfrg' resource.  Only the one with ID 0
is looked at, but it can describe multiple code fragments.

You would also want to check the code's type, as it might not be for the
PowerPC ('pwpc').  It could (in the future) be for the 68K or
theoretically some other processor.

Theoretically, there can be data after code, multiple codes (multiple
fragments for one processor or fragments for different processors -- or
both), and there could even be multiple datas interspersed between codes.

_troy
--
//////// //////   Troy Gaul                            [e-mail]   //
  //    //       I-Link, Ltd.                                             //
 //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)              //
//    ////// __________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (David Johnson)
Date: Fri, 8 Apr 1994 01:35:09 GMT
Organization: Wind River Systems, Inc.

[e-mail] (Jack Littleton) writes:

>Jon Wdtte ([e-mail]) wrote:
>: 1) Set the data fork length to 0 bytes
>: 2) Remove the cfrg resource

>: Done.

>To be really safe, I'd check the offset field of the cfrg resource before
>doing this.  It is still possible, although not recommended, to store data
>in the data fork of a fat binary.  The offset field in the cfrg tells the
>CFM where the actual code starts (or other code fragments start).  If the
>offset is zero, as it is for most apps I've seen, go ahead and zap the
>data fork.

If you want to just shit-can the data fork and see if the app runs, use
one of the the apps made for munging the registration info that a lot
of apps store in the data fork.  A little more elegent than using a
word-processor.

Let's see what we have here...

/folk/johnson/Misc/Umich/mac.archive.umich.edu.gz    %71.2
/mac/util/diskfile/anonymity1.2.cpt.hqx
  34    12/20/92    BinHex4.0,Compact1.34

   Remove the personalization info from programs (like Word and Excel)
   that store the info (and ONLY the info) in the data fork.


Yup, that otta do it :-)

--DAVE ([e-mail])

"And now, a man who faces his destiny at FULL THROTTLE...  Its David Letterman!"

                                   (c)1993 CBS

---------------------------

>From [e-mail] (Vik Rubenfeld)
Subject: Roman Numerals
Date: 05 Apr 1994 00:21:15 -0000
Organization: (none)

Does anybody have an algorithm for translating an integer into a string that
contains its Roman Numeral equivalent? Thanks in advance.

+++++++++++++++++++++++++++

>From [e-mail] (Vik Rubenfeld)
Date: 06 Apr 1994 10:20:10 -0000
Organization: (none)

Thanks for the extremely cool algorithm.

+++++++++++++++++++++++++++

>From [e-mail] (Vik Rubenfeld)
Date: 07 Apr 1994 11:32:15 -0000
Organization: (none)


Thanks for your excellent procedure, ArabicToRoman. It was also a good
excercise for me to use in becoming more familiar with C, because I
translated it from C to Pascal. In case you'd like to see it, and in case
others would like a Pascal version, here's what it looks like in Pascal.


procedure ArabicToRoman (arab: integer;
       var Rom: DecStr);
  const
   nFives = 3;
   nOnes = 4;

  var
   reverse: integer;{ stores digits in reverse order (6533 -> 3356) }
   mag: integer;{ magnitude of the arabic number (6533 -> 3   ) }
   digit: integer;{ current digit being processed                 }

   Fives, Ones: DecStr;
 begin
  reverse := 0;
  mag := -1;
  Rom := '';

  Fives := 'vld';
  Ones := 'ixcm';

  while (arab > 0) do
   begin
    reverse := reverse * 10;
    reverse := reverse + (arab mod 10);
    arab := arab div 10;
    mag := mag + 1;
   end;

  while reverse > 0 do
   begin
    digit := reverse mod 10;
    reverse := reverse div 10;

    if (((mag = nFives) & (digit > 3)) | ((mag = nOnes) & (digit <> 5)) |
((digit = 9) & (mag = nOnes - 1))) then
     begin
      Rom := 'Cannot Convert';
      exit(ArabicToRoman);
     end;

    case digit of
     3:
      begin
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
      end;
     2:
      begin
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
      end;
     1:
      rom := concat(rom, ones[mag + 1]);

     4:
      begin
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, fives[mag + 1]);
      end;

     5:
      rom := concat(rom, fives[mag + 1]);

     6:
      begin
       rom := concat(rom, fives[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
      end;

     7:
      begin
       rom := concat(rom, fives[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
      end;

     8:
      begin
       rom := concat(rom, fives[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 1]);
      end;

     9:
      begin
       rom := concat(rom, ones[mag + 1]);
       rom := concat(rom, ones[mag + 2]);
      end;

     otherwise
      ;
    end; {case}
    mag := mag - 1;
   end; {while}
 end;




+++++++++++++++++++++++++++

>From [e-mail] (Vik Rubenfeld)
Date: 08 Apr 1994 21:51:07 -0000
Organization: (none)

CMG> Hi there! I have some Pascal code that I wrote for a program that
CMG> converts Decimal, hexadecimal, etc. to Roman Numerals and vice
CMG> versa... I might be able to dig it up : )
CMG>
CMG> What kind of program are you writing?

Thanks! Sure, I'd like to see it. I've adapted a C routine provided by Mike
Mayer, and it's working fine, but the hex part of your code might be neat to
see.

It's a program that tabulates Market Research data. It's the basis of a
business I operate. I wanted to use Roman Numerals for the page numbers in
the table of contents.

---------------------------

>From [e-mail] (Mark Armitage)
Subject: SCSI Drivers
Date: Thu, 7 Apr 1994 12:54:12 GMT
Organization: Poor,  but trying...

Help,

I have a non-apple SCSI drive which requires a SCSI START command to be
sent to it!  (Apparently the drive doesn't acually start spinning until
this command is received).

Can anyone point me in the direction of a utility/init or piece of code
that can perform this function?

Thanks,

Mark.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (LANKTON MARK)
Date: Fri, 8 Apr 1994 13:47:55 GMT
Organization: University of Colorado, Boulder

[e-mail] (Mark Armitage) writes:

>Help,

>I have a non-apple SCSI drive which requires a SCSI START command to be
>sent to it!  (Apparently the drive doesn't acually start spinning until
>this command is received).

>Can anyone point me in the direction of a utility/init or piece of code
>that can perform this function?

>Thanks,

>Mark.

>[e-mail]

Try this:


#define     kStartStopUnitCmd    0x1B
#define     kStartCode            0x01
#define     kStopCode            0x00
SpinUp(short targetID)
{
    short             theResult;
    unsigned char    theCommand[6];
    sensePage        returnedSense;
    short            numTries = 0;
    Boolean            gotBus = false;
    int                waitTime = 100;    /*or so...*/
    short            returnedStatus = 0;
    short            returnedMessage = 0;


    theCommand[0] = kStartStopUnitCmd;
    theCommand[1] = 0x01;    /*Don't wait for reply on command */
    theCommand[2] = 0;
    theCommand[3] = 0;
    theCommand[4] = kStartCode;
    theCommand[5] = 0;

    do
        {
        numTries++;
        theResult = SCSIGet();
        if(theResult == noErr)
            {
            theResult = SCSISelect(targetID);
            if(theResult == noErr)
                gotBus = true;

            }
        }
        while((numTries <= kMaxSelectTries) && (!gotBus));

    if((numTries >= kMaxSelectTries) || !gotBus)
        {
        printf("SCSI device selection failed on ID = %d",targetID);
        return;
        }

    if(gotBus)
        {
        theResult = SCSICmd((char *)theCommand,6);
        theResult = SCSIComplete(&returnedStatus,&returnedMessage,waitTime);
        }

    /*Check returnedStatus for errors

}

Mark Lankton ([e-mail])
Laboratory for Atmospheric and Space Physics
University of Colorado

---------------------------

End of C.S.M.P. Digest
**********************