Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-178.txt

Text File | 1994-12-08 | 42.6 KB | 1,246 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 06 Oct 92       Volume 1 : Issue 178

Today's Topics:

    Best text compression
    Adding Balloon help to my App...
    Projects to be converted in Think Pascal.
    Popup menus (help!!)
    Open file at launch time?
    Event Loop
    little sys 7 pop up problem (popupMenuCDEFProc)
    TN 306 GetIconSuite glue fatal error
    Shareware Legality - Summary
    Can TCL project size be reduced using precompiled headers?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

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.  (This means you can't post questions to the
digest.)

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
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month 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 entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


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

From: [e-mail] (Dawson Dean)
Subject: Best text compression
Date: 4 Sep 92 15:02:16 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853


I sent a message to the original poster last night, but it must
have bounced cuz I havent seen it on the net. Then, I see
everyone saying how swell Huffman is and I've got to put in
my own 2 cents. Its been my experience that a good lzw implementation
blows away Huffman and the best public domain lzw I know of is
built by Ross Williams, and is called lzrw. There are 5 versions
that have different speed/compression tradeoffs, but all are great.

You can ftp these from sirius.ucs.adelaide.edu.au or check archie
for other archives. Plus, check out comp.compression and
comp.compression.research, for the latest scoop from many people
(including Ross Williams) who know lots more about this stuff
than me.

Here is the readMe from the lzrw release....
- ----------------
DATA COMPRESSION DIRECTORY
==========================
Date   : 04-Apr-1992.
Author : Ross Williams ([e-mail])

This file gives an overview of the data compression directory of the
anonymous ftp archive located at the University of Adelaide, South
Australia. The exact location of the directory is:

   Machine   : sirius.itd.adelaide.edu.au    [IP=129.127.40.3]
   Directory : pub/compression

The directory mostly contains public domain data compression
algorithms developed by Ross Williams during early 1991. It also
contains one or two other items of interest.

The files in this directory may be compressed. Files that are
compressed will have names terminating with ".Z" and will have to be
uncompressed before use (using the Unix "uncompress" command). I
wouldn't trust my files to a data compression algorithm :-), but the
system programmer who put the files there for me (I do not have direct
control over this archive) seems to think that it is a good idea.

Ross Williams
21-Aug-1991

0readme         - This descriptive file.
dc_stan_just    - Justification of dc_stan_spec.
dc_stan_spec    - Proposal for data compression interface standard.
dc_stan_stream  - Revised proposed standard.
dcc91_report    - Report on 1991 Data Compression Conference.
fast_copy.68000 - Fast block move routine for 68000 microprocessor.
lzrw1-a.68000   - LZRW1-A algorithm implemented in 68000 assembler.
lzrw1-a.c       - LZRW1-A algorithm implemented in C
lzrw1-a.txt     - Release notes for LZRW1-A algorithm.
lzrw1.68000     - LZRW1 algorithm implemented in 68000 assembler.
lzrw1.c         - LZRW1 algorithm implemented in C.
lzrw1.tex       - DCC91 conference paper describing LZRW1 algorithm.
lzrw2.c         - LZRW2 algorithm implemented in C.
lzrw2.txt       - Release notes for LZRW2 algorithm.
lzrw3-a.c       - LZRW3-A algorithm implemented in C.
lzrw3-a.txt     - Release notes for LZRW3-A algorithm.
lzrw3.c         - LZRW3 algorithm implemented in C.
lzrw3.txt       - Release notes for LZRW3 algorithm.
lzrw4.txt       - Description of LZRW4 algorithm (not yet implemented).
lzrw45_covering - Release notes for LZRW4 and LZRW5 descriptions.
lzrw5.txt       - Description of LZRW5 algorithm (not yet implemented).
lzrw_headers.h  - Header files (.h files) for C code.
puzzlebox_provpatent - Provisional patent for puzzle box.
rw_info         - Information about Ross Williams and his activities.

WARNING: A patent has recently arisen that may cover one or more of
these algorithms. Please refer to the file rw_info for more
information.

- --<End of 0readme file for the compression directory>
- --
******************************************************************
Dawson Dean                       Internet: [e-mail]
Dept. of Computer Science         Office:   [phone]
Cornell University

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

From: [e-mail] (Danny W. McCampbell)
Subject: Adding Balloon help to my App...
Date: 2 Sep 92 13:26:11 GMT
Organization: University of Tennessee

Is there an easy way to add balloon help to my Application.
I ready IM Vol VI and understand the resources, but when
I create the resources in resedit I get the hex editor.
Can anyone give me any tips on how to get started?

Thanks a bunch.

Danny McCampbell
[e-mail]

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

From: [e-mail] (Stuart Cheshire)
Date: 2 Sep 92 17:35:38 GMT
Organization: Stanford University

In article <[e-mail]> Danny W. McCampbell,
[e-mail] writes:
>Is there an easy way to add balloon help to my Application.

I do my Balloon help by reading IMVI and using SaRez which comes with
Think C.

However, a friend showed me Resorcerer, and it is brilliant (in many
respects, not just that of its handling of Balloon help resources). If
you can afford it, I would recommend that you buy it. I intend to as soon
as I can.

Stuart Cheshire <[e-mail]>
 * Liliore Green Rains Houses Resident Computer Coordinator
 * Stanford Distributed Systems Group Research Assistant
 * Macintosh Programmer

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

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Thu, 3 Sep 1992 05:13:30 GMT

In article <[e-mail]>, [e-mail]
(Danny W. McCampbell) wrote:
>
> Is there an easy way to add balloon help to my Application.
> I ready IM Vol VI and understand the resources, but when
> I create the resources in resedit I get the hex editor.
> Can anyone give me any tips on how to get started?

Whatever you do, don't use BalloonWriter or you'll spend more time fighting
it than adding balloons!  The best way I've found is to use ResEdit to
create the dialog, and then set the DITL resource's Balloon Help to
HMscanhdlg, ID <whatever>, and then use SARez, and life is relatively
simple.  Here's an example rez source:

#include "Types.r"
#include "BalloonTypes.r"

resource 'hdlg' (1002, "DITL 202") {
    2,
    0,
    0,
    0,
    0,
    HMSkipItem {

    },
    {    /* array HDialogArray: 10 elements */
        /* [1] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            1,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [2] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            2,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [3] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            3,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [4] */
        HMSkipItem {

        },
        /* [5] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            4,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [6] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            0,
            0,
            0,
            0,
            1002,
            5,
            1002,
            5
        },
        /* [7] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            6,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [8] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            7,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [9] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            8,
            0,
            0,
            0,
            0,
            0,
            0
        },
        /* [10] */
        HMStringResItem {
            {0, 0},
            {0, 0, 0, 0},
            1002,
            9,
            0,
            0,
            0,
            0,
            0,
            0
        }
    }
};

resource 'STR#' (1002, "BH for hmnu 202") {
    {    /* array StringArray: 4 elements */
        /* [1] */
        "Click here to save the changes that you "
        "have made.  The changes will take effect"
        " for all future logins.",
        /* [2] */
        "Click here if you don't want to make any"
        " changes.",
        /* [3] */
        "Click here if you make a mistake and wis"
        "h to discard all the changes you have ma"
        "de.",
        /* [4] */
        "Type in the default directory here.  Thi"
        "s is the directory a user will start in "
        "if they are not explicitly listed in the"
        " menu below.",
        /* [5] */
        "Select a user with this menu, and then e"
        "dit their username and/or their startup "
        "directory.",
        /* [6] */
        "Click here if you wish to create a new u"

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

From: [e-mail] (Norman Franke, III)
Date: 4 Sep 92 17:21:35 GMT
Organization: Lawrence Livermore National Laboratory

In article <[e-mail]> Reid Ellis, [e-mail]
writes:
>This is fine as long as your balloon help strings are all less than
>255 chars long.  If they're longer, you should use TEXT [HMTEResItem]
>resources instead.  Another advantage of using TEXT resources is that

I read in the recent copy of _d e v e l o p_ that the Help Manager will
only
use 255 length strings maximum, whether from TEXT & styl or from a STR or
STR#.
They suggested using a PICT for anything larger.

| | | |   +----------------------------------------+
| | | |   | Lawrence Livermore National Laboratory |
| | | |__ |        Computer Scientist - EPD        |
| | |___/ |     T-5475, R-1321, [phone]     |
\ \____/  | Norman Franke, III - frankee@.llnl.gov |
 \____/   -----------------------------------------+

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

From: [e-mail] (Rudi Maelbrancke)
Subject: Projects to be converted in Think Pascal.
Organization: Dept. Computerwetenschappen K.U.Leuven
Date: Thu, 3 Sep 1992 14:09:57 GMT

Hello,

I have a problem opening some example projects which are accompaning
plug in cards for Macintosh.

When I open the projects, I get a message saying: The project name has to be
converted (compressed) before proceeding...

When I click OK the file is enlarged but seems to contain no files.
(No references in the project).

Does anybody knows what a compressed or converted project means?

I'm using system 7.0 and still THINK Pascal 3.0

Rudi Maelbrancke,

Please E-mail me.

[e-mail]

Thank you!



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

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Thu, 3 Sep 1992 17:32:25 GMT

In article <[e-mail]> [e-mail] (Rudi Maelbrancke) writes:
>
>When I open the projects, I get a message saying: The project name has to be
>converted (compressed) before proceeding...
>
>When I click OK the file is enlarged but seems to contain no files.
>(No references in the project).

The probable cause of this is that the project documents were created by
THINK Pascal 4.0, and you're trying to open them with THINK Pascal 3.0.
You can either update to THINK Pascal 4.0, or get your vendor to send
you the projects in 3.0 format, or guess and try to figure out what
files (besides runtime.lib and interface.lib) were in the example
projects.

R>
- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

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

From: bberqu@sagpd1 ()
Subject: Popup menus (help!!)
Date: Mon, 31 Aug 1992 17:32:44 GMT


Hi,

I have three popup menus within a dialog box and am trying to figure out
the best way to handle them, I know system 7 has support for them, but
I would like my application to work with earlier versions of the OS also.

Here's how I'm doing it, I create the static text to the side of the
popupmenu with ResEdit (using DITL/DLOG editor), and also the popup menus
(with the Menu editor).  Since I don't know the width of the menus in
ResEdit to make boxes for the popupmenus to the right of the static text
as user Items, I calculate in my program based on where the static text
item's rect is and the width of the popup menu, the rectangle for the popupmenu.
I also create a control for the popup menu for that rectangle and store
the menuhandle in the control's refcon field.  Everything works fine up to
this point, handling them is another story.

It seems like all I should have to do to handle popup menus is when
ModalDialog detects an event within the dialog it should pass the
information to my filterProc function. If I know where the event happened
and the dialog pointer I could call FindControl which would return me the
control, and I've previously stored the menu handle in the control refcon
field, so then I could simply call PopMenuSelect with the controls rect
and the menuhandle, however I don't, understand CDEFs so FindControl
doesn't seem to be returning the control handle, also ModalDialog does not
seem to be passing me the dialog pointer (should it be?).  I suspect
FindControl is not finding the control because of my CDEF (it doesn't do
anything right now but return 1).  I know very little about CDEFs, IM
doesn't seem to explain them very well (at least I don't understand them),
I looked for information on them in bookstores over the weekend, but
with no luck.

Am I on the right track or totally off base.  If I'm on the right track,
could somebody please explain CDEFs or point me to a good book on the
subject and if ModalDialog will give me the information I need to do this.
I also don't understand how ModalDialog works either, but somebody explained
at least how the ModalDialog and filterProc functions work together.
If I'm off base, please give me some info on how you would do it.

Thanks in advance, sorry for the long mail and hope its understandable.

Brian

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

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Mon, 31 Aug 1992 23:24:09 GMT

bberqu@sagpd1 () writes:

>I have three popup menus within a dialog box and am trying to figure out
>the best way to handle them, I know system 7 has support for them, but
>I would like my application to work with earlier versions of the OS also.

Suggestion 1: use the pop-up menu CDEF included with the System 6
Communications Toolbox for pre-System 7 machines.

>It seems like all I should have to do to handle popup menus is when
>ModalDialog detects an event within the dialog it should pass the
>information to my filterProc function. If I know where the event happened
>and the dialog pointer I could call FindControl which would return me the
>control....

More likely, you want to call FindDItem, not FindControl.

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] (Carl W. Haynes III)
Date: 1 Sep 92 03:04:59 GMT
Organization: Purdue University

In article <[e-mail]> [e-mail] (Pete Resnick) writes:
>
>Suggestion 1: use the pop-up menu CDEF included with the System 6
>Communications Toolbox for pre-System 7 machines.
>

What's the licensing deal with this? Do we need to license the CDEF from
Apple if we use it in our programs for pre-system 7 work?
I ended up writing my own, but may be interested in using Apple's instead.

carl

- --
Carl W. Haynes III
Haynes Consulting Services        ||  [e-mail]
PO Box 2715                       ||  [e-mail]
W. Lafayette, IN 47906            ||  [e-mail]
- ----------------------------------------------------------------------
       Macintosh Programming & Consulting - Yes, I'm available

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

From: [e-mail] (Steven Dorner)
Organization: Qualcomm, Inc
Date: Tue, 1 Sep 1992 14:40:26 GMT

[e-mail] (Carl W. Haynes III) wrote:
>
>[e-mail] (Pete Resnick) writes:
> >
> >Suggestion 1: use the pop-up menu CDEF included with the System 6
> >Communications Toolbox for pre-System 7 machines.
> >
>
> What's the licensing deal with this? Do we need to license the CDEF from
> Apple if we use it in our programs for pre-system 7 work?

I would assume you would have to pay the fee for redistributing the Comm
Toolbox.  This is $50 per year.  Ask [e-mail] to
be sure.

It's a real shame this CDEF didn't get rolled into System 6.  The CTB
has been around since 6.0.4 or so, so it could have been done with the
release of 6.0.5 or 6.0.7.

The problem with shipping your own copy of the CDEF is that you must
renumber it, or it will interfere with the system 7 popup CDEF.  Then you
either have to use your renumbered CDEF under system 7, or you have to
change your controls on the fly to pick up the sys7 CDEF.

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

From: [e-mail] (Sak Wathanasin)
Date: 4 Sep 92 14:17:40 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Steven Dorner) writes:

> [e-mail] (Carl W. Haynes III) wrote:
> >
> >[e-mail] (Pete Resnick) writes:
> > >
> > >Suggestion 1: use the pop-up menu CDEF included with the System 6
> > >Communications Toolbox for pre-System 7 machines.
> > >
> >
> > What's the licensing deal with this? Do we need to license the CDEF from
> > Apple if we use it in our programs for pre-system 7 work?
>
> I would assume you would have to pay the fee for redistributing the Comm
> Toolbox.  This is $50 per year.  Ask [e-mail] to
> be sure.

There is a copy of the popup CDEF in the MacApp 3.0 distribution. There is
a brief reference to it in the release notes, and UPopup.h contains the
following instruction:

// For Sys 6.0 support: include the Popup CDEF in the resource fork of your application
// with the following lines in your app.r file:
//        include "Popup.rsrc";

I assume, therefore, that the MacApp object code distribution licence covers
the use of the CDEF.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

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

From: [e-mail] (hui  dong)
Subject: Open file at launch time?
Date: 31 Aug 92 07:05:51 GMT
Organization: University of Chicago Computing Organizations

I created an application, it can write files. I like to know if one double
click on a file, the application is launched, but how can the application know
and open the file automatically after the launched is finished.

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

From: [e-mail] (Tague Griffith )
Date: 31 Aug 92 11:33:32 GMT
Organization: BUG, Inc.   Sapporo, Japan

Subject says it all.

Under system 7.0, when your application is opened, the finder first sends the
application an kAEOpenApplication ('oapp')  apple event.  Your application
should respond by doing anything it needs to do at startup.  Then the finder
sends your application an kAEOpenDocuments 'odoc' event which includes a list
of alias records to the double clicked files, resolve the aliases and then
open the files.  Pretty much the same thing with the print document event as
well.

Under system 6.0.x you can use the CountAppFiles, GetAppFiles, and ClrAppFiles
procedures to handle this.  Your application really should support both
methods, since system 6.0.x is still the latest version of the os in many
languages.  The Apple Event stuff is documented in IM VI (including example
code) and the *AppFiles routines in IM II.  Plus, I think the
comp.sys.mac.programmer faq.----------------------------------------------------------------------------
internet : [e-mail]         |  $@%S!<!&%f!<!&%8!<;%KZF|K\$G$9(J
         : [e-mail]   |  $@%9%?%s%U%)%I!<Bg3X%"%a%j%+$G$9(J
AppleLink: BUGPLAN.DVJ             |  BUG, Sapporo Japan (ISDN Development)
"A result is a neutralisation ov, and challenge to, thee centre ov Control.
A Tribal State replacing a State ov tribe." - G.P-Orridge, Psychic TV
- ----------------------------------------------------------------------------

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

From: [e-mail] (Chuck Hoffman)
Date: 31 Aug 92 15:12:40 GMT
Organization: GTE Laboratories

In article <[e-mail]>, [e-mail] (Tague
Griffith ) wrote:
> Under system 6.0.x you can use the CountAppFiles, GetAppFiles, and ClrAppFiles
> procedures to handle this.  Your application really should support both
> methods, since system 6.0.x is still the latest version of the os in many
> languages.  The Apple Event stuff is documented in IM VI (including example
> code) and the *AppFiles routines in IM II.  Plus, I think the
> comp.sys.mac.programmer

This is also true under System 7.  I have a sample application which
happens to have this code in it.  It also has code for printing from the
Finder as well as opening.  If you are interested, I would be happy to mail
it to a postal address.

Chuck Hoffman
[e-mail]
GTE Laboratories, Waltham, Massachusetts, USA
[phone]
=====================================
I'm not sure why we're here, but I am sure that while we're here we're
supposed to help each other.
=====================================

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

From: [e-mail] (J. S. Greenfield)
Organization: Syracuse University, CIS Dept.
Date: Tue, 1 Sep 92 22:56:52 EDT

In article <[e-mail]> [e-mail] (Tague Griffith ) writes:
>
>Under system 7.0, when your application is opened, the finder first sends the
>application an kAEOpenApplication ('oapp')  apple event.  Your application
>should respond by doing anything it needs to do at startup.  Then the finder
>sends your application an kAEOpenDocuments 'odoc' event which includes a list
>of alias records to the double clicked files, resolve the aliases and then
>open the files.  Pretty much the same thing with the print document event as
>well.

Actually, under any normal circumstances, the finder will *either* send
an "oapp" or an "odoc" but *not* both.  (That is, immediately after launching.)

If you get an "oapp" it means that your application was launched *without*
any documents--and you should take any appropriate action--for example,
opening a new, untitled window.

If you get an "odoc" it means that your application was launched *with*
documents (those listed in the "odoc" event).

If you were to get *both*, it would (normally) indicate that the application
was first launched without any documents, and then a document was launched
(double-clicked, or dropped on the app, for example) *after* the app was
already running.


- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

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

From: Anders Wallgren <[e-mail]>
Organization: Verity, Inc., Mountain View, CA, USA
Date: Thu, 3 Sep 92 22:03:03 GMT

In article <[e-mail]> J. S.
Greenfield, [e-mail] writes:
>Actually, under any normal circumstances, the finder will *either*
send
>an "oapp" or an "odoc" but *not* both.  (That is, immediately
after launching.)

Don't forget 'pdoc' - you will get either 'oapp', 'odoc', or 'pdoc'
(and sometimes 'quit' shortly thereafter), under 'normal'
conditions - this isn't enforced by anything, so be prepared for
other sequences to happen.

anders

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

From: [e-mail] (Richard J. Resnick)
Subject: Event Loop
Organization: University of Massachusetts, Amherst
Date: Tue, 1 Sep 1992 15:27:20 GMT

Hello,

I don't know if it is "ok" protocol to post code questions here... I apologize
in advance for any annoyance I may create. I did check the faq, and it wasn't
any help.

I am a beginning MAC programmer, and am working with the event loop thingy.
I am trying to write a simple program which brings up the text window, and
then just runs through the event loop until you click on the menu bar. But when
I run it, it just hangs on me, and the debugger says that isEvent is _never_
true! Will someone enlighten me as to why this code doesn't work? Thanks in
advance.

begin

  repeat
    isEvent := GetNextEvent(everyEvent, thisEvent);

    case thisEvent.what of
        nullEvent: {Do nothing}
           begin
           end;
        mouseDown: {where is the mouse clicked?}
           begin
              whereIsIt := FindWindow(thisEvent.where, thisWindow);

              case whereisIT of
                  0, 3: {In drawing window}
                     gameOver := false;
                  1: {in Menubar}
                     gameOver := true;
              end; {case whereIsit}

           end; {mouseDown}

        otherwise:
           begin
           end;

    end; {case thisEvent.What}
  until gameOver;

end.

*=====/=== ===^=====.==='========`============/==== = ^========~====/====^ =-=*
*        "I'll return your fire, if you take away your vultures..."           *
*                       - Prometheus, gaining leverage                        *
*===^==/=======\======= ===`====='===> ==========>====.===== =^=====/====*====*
                  Internet Address: [e-mail]




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

From: [e-mail] (Andrew Thomas-cramer)
Date: 3 Sep 92 17:47:32 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

isEvent is always 0, fortunately -- but it is not FALSE. GetNextEvent
returns zero (noErr) unless an error occurs. You're confusing noErr
with FALSE, both of which are equal to zero.

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

From: [e-mail] (Charles B. Cranston)
Date: 3 Sep 92 18:54:19 GMT
Organization: UM Home for the Terminally Analytical

In article <[e-mail]>,
[e-mail] (Andrew Thomas-cramer) wrote:

> isEvent is always 0, fortunately -- but it is not FALSE. GetNextEvent
> returns zero (noErr) unless an error occurs. You're confusing noErr
> with FALSE, both of which are equal to zero.

Sigh - wrong.  More dangerous misinformation.  It only took me 45
seconds to pull my Inside Mac off the shelf and find GetNextEvent.
You'd think someone would do that before sending a netnews message
to tens of thousands of people on thousands of computers...

Ahem:

"Before reporting an event to your application, GetNextEvent first
 calls the Desk Manager function SystemEvent to see whether the system
 wants to intercept and respond to the event.  If so, or if the event
 being reported is a null event, GetNextEvent returns a function result
 of FALSE; a function result of TRUE means that your application should
 handle the event itself."

Now, the Desk Manager clause is not as important as it once was.
Since DAs are run in their own layers in system 7 and in a unified
DA layer in system 6 with multifinder, the only time this can make
a difference is on system 6 without multifinder, or system 6 with
multifinder and a DA loaded into the application's heap using the
option key while opening the DA.

Modulo this, the result from GetNextEvent is FALSE if a null event
is being reported and TRUE if a real event is being returned.  It
is NOT an error code...

And this is what I put in my private email to the original poster.

[e-mail]     -KA3ZDF

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

From: [e-mail] (Paul L Merchant Jr.)
Subject: little sys 7 pop up problem (popupMenuCDEFProc)
Date: 1 Sep 92 18:57:48 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Vincent Zocca) writes:

> tracked properly by TrackControl. That is, the control is inverted to show
> itUs being tracked but the menu doesnUt actually pop up.


I had this problem when I first used popup menus:  Make sure you're
setting the actionProc field of the control to -1.  This will cause the
default action procedure to be used and will make TrackControl work
properly.

- -- Paul Merchant
DCIS

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

From: Michael Brennan <[e-mail]>
Organization: Amgen
Date: Wed, 2 Sep 1992 22:01:07 GMT

In article <[e-mail]> Vincent Zocca,
[e-mail] writes:
>So, I've got this problem with system 7's Pop-Up controls.
>I create one with NewControl and popupMenuCDEFProc (IM VI 3-16). That
works
>fine; The control is displayed and the value (selection of a menu item)
and
>hilite status can be set. The 'only' thing is that the control is not
>tracked properly by TrackControl.

This is a common problem.  When you call TrackControl, be sure to use -1L
as your final parameter (e.g., TrackControl( theControl, localPt,
(ProcPtr) -1L )).  If you are using 0 for the final parameter, than this
is why it is not working for you.  The -1L indicates that the CDEF
employs a custom tracking procedure.  Be sure to cast it as a ProcPtr to
keep the compiler happy!

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

From: [e-mail] (Peter N Lewis)
Subject: TN 306 GetIconSuite glue fatal error
Date: 2 Sep 92 04:30:46 GMT
Organization: NCRPDA, Curtin University

Hi All,

I just came across this in TN 306:

In the body:

Function GetIconSuite(    Var theSuite: Handle; theID:Integer;
        theSelector:Longint):OSErr;

In the interface:

FUNCTION GetIconSuite(VAR theIconSuite: Handle;theResID: INTEGER;
    selector: Integer): OSErr;    INLINE    $303C, $0501, $ABC9;

pascal OSErr GetIconSuite(Handle *theIconSuite,short theResID,short
selector)= {0x303C, 0x0501, 0xABC9};

Now, look carefully at the selector ... oooops!

Its suppose to be a LongInt/long, not an integer/short!  The same most
probabbly applies to ForEachIconDo's selector but I haven't checked it.
Its clear it has to be a long, since the svAllMiniData constant that can be
passed is $00FF0000, certainly not a short value...

You have been warned,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

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

From: [e-mail] (Michael Hecht)
Date: 2 Sep 92 14:35:25 GMT
Organization: SAS Institute Inc.

In article <peter-020992122411@134.7.50.3> Peter N Lewis,
[e-mail] writes:
>Its suppose to be a LongInt/long, not an integer/short!  The same most
>probabbly applies to ForEachIconDo's selector but I haven't checked it.

The same certainly does apply to ForEachIconDo.

Not only that, but the procedure definition for its action proc should be:

pascal OSErr DoIcons( ResType theType, Handle *theIconData,
                long refCon );

Note that the first two parameters are *reversed* in the Tech Note!

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

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

From: [e-mail] (Brian Bechtel)
Date: 4 Sep 92 13:48:25 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Peter N Lewis) writes:

>I just came across this in TN 306:

>In the body:

>Function GetIconSuite(    Var theSuite: Handle; theID:Integer;
>        theSelector:Longint):OSErr;

>In the interface:

>FUNCTION GetIconSuite(VAR theIconSuite: Handle;theResID: INTEGER;
>    selector: Integer): OSErr;    INLINE    $303C, $0501, $ABC9;

>pascal OSErr GetIconSuite(Handle *theIconSuite,short theResID,short
>selector)= {0x303C, 0x0501, 0xABC9};

>Now, look carefully at the selector ... oooops!

>Its suppose to be a LongInt/long, not an integer/short!  The same most
>probabbly applies to ForEachIconDo's selector but I haven't checked it.
>Its clear it has to be a long, since the svAllMiniData constant that can be
>passed is $00FF0000, certainly not a short value...

This will be fixed in the October release of tech notes.  Thanks for
reporting it!

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

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

From: [e-mail] (Matthew Hall)
Subject: Shareware Legality - Summary
Date: 2 Sep 92 20:18:55 GMT
Organization: Oberlin College Computer Science

Hello-
    Thank you all for your replies to my question - in brief I
released software to sumex-aim, asking to be contacted before it was
redistributed, and found out that NAUTILUS, against my wishes,
included it on their latest CD-ROM.  The answers I recieved were
widely varied ( only one of them told me that I was completely silly)
and there were at least 30 responses, on the net and by e-mail.

As for what I should do now, the responses tended towards the line
that I had goofed.  A legal action was discouraged (I wasn't really
planning on a suit - that seemed a little much) as it would probably
cost more than I would gain.  I could ask them to remove my App from
their disk, but it is published now, and I doubt that they will recall
all the copies.  The damage is done, and the best course of action
seems to be a polite, firm letter telling them that they were at
fault. (Maybe the all of the other disenchanted folks that this
happened to and I can start a letter writing campaign.  Or heck - all
call to complain... collect. :-) )

To protect against these things, the first thing is to copyright your
program (I did). Put the copyright sign, date, and your name in your
programs About box, and in the documentation. This may give you all
the protection you need, but you should take the additional measures below.

Next, in the documentation, or README file, be very careful that you
use the correct wording if you don't want this to happen.  If you want
them to ask you beforehand, say something like "Any person or persons
wishing to redistribute this program for a profit MUST gain written
permission from me, the author, beforhand".  You can't be too explicit
here, and be very, very careful.  "Contact me" may be interpreted as
not needing permission, merely sending a letter to you.

(Other helpful lines - add one about "The author takes no liability
for damages..." so noone can take action against you if they think
your program fried their hard drive, and add one about "Redistributed
copies of this program must be distributed with all files, including
this one" so that if someone gets a copy second hand, they know
better)

Finally- Register your program with the library of congress.  The
person posting this suggestion, however, did not say explicitly how to
do this.  Perhaps someone could post instructions.

Oh yeah, MacTutor's latest version includes an article on software
authors rights.  Looks like I should get me a copy.

Thanks to everyone who responded.
- -matt hall

P.S.  I guess it was somewhat flattering to have my meager app
published on CD-ROM (I can tell my friends that I got put on CD this
summer) however, I did feel like my rights were violated here, and I
now know that I will have to be very careful in the future -
especially with the commercial version which I am publishing myself
and selling through catalogs.  Anyone who has suggestions for that, I
welcome your replies, and again will summarize.

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


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

From: [e-mail] (Chuck Hoffman)
Date: 4 Sep 92 16:02:37 GMT
Organization: GTE Laboratories

In article <[e-mail]>,
[e-mail] (Matthew Hall) wrote:
>
> Finally- Register your program with the library of congress.  The
> person posting this suggestion, however, did not say explicitly how to
> do this.  Perhaps someone could post instructions.
>

Just for background:  your copyright "declaration" is what you put on your
startup screen, etc., that says "Copyright 1992, Charles A. Hoffman.  All
rights reserved."  Your copyright "registration" is what you request from
the Library of Congress.  You are registering your copyright of your
program, you are not registering the program itself.

To register your copyright, call the Library of Congress at [phone]
and request Form TX and instructions.  This is for copyrighting your source
code, which is treated as text.  Form PA is for works of art, in case you
want to copyright background pictures, etc.  I never have.

When you get the form, use the instructions to fill it out, and send it
back in with two copies of your source, and $20.  It's twenty, even though
some of the forms still say $10.  Some people say only one is required, but
that is for "hardship" which is more trouble than to just get a second copy
of the source.  Also some say only the first and last 50 pages, but that's
an old rule applying to OBJECT code, and I don't think it ever applied to
source.

In one to three months, you will receive back your registration form, with
the registration number stamped on it.

Questions about copyrights should be referred to an attorney, of course.
The Library of Congress also maintains another number which has prerecorded
answers to common questions about copyrights.  It is [phone].

P.S.  Once you get a Form TX, you can copy it freely (holds down their
cost, they say).  It's not copyrighted!

Chuck Hoffman
[e-mail]
GTE Laboratories, Waltham, Massachusetts, USA
[phone]
=====================================
I'm not sure why we're here, but I am sure that while we're here we're
supposed to help each other.
=====================================

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

From: [e-mail] (Dan Emery)
Subject: Can TCL project size be reduced using precompiled headers?
Date: 2 Sep 92 21:39:37 GMT
Organization: UM Home for the Terminally Analytical

Is it possible to reduce the size of a TCP project file by using
the "precompiled header" feature?  If so, could some kind soul
email or post a description of the strategy one would use.

Dana Emery <[e-mail]>

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

From: [e-mail] (Michael A. Kelly)
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Thu, 3 Sep 1992 00:40:12 GMT

In article <[e-mail]> [e-mail] (Dan Emery) writes:
>Is it possible to reduce the size of a TCP project file by using
>the "precompiled header" feature?  If so, could some kind soul
>email or post a description of the strategy one would use.
>

I'll add this to the next version of the FAQ.

The answer is yes.  You just add your TCL headers to Mac #includes.c and
Precompile.  Presumeably you would want to make a separate file, called
something like "Traps+TCL Headers".

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
[e-mail]                             Computer Science Department
_____________________________________________________________________________

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

From: [e-mail] (Lars Petrus)
Organization: Stacken Computer Club, Stockholm, Sweden
Date: Thu, 3 Sep 1992 10:10:56 GMT

In article [e-mail] (Michael A. Kelly) writes:
>In article [e-mail] (Dan Emery) writes:
>>Is it possible to reduce the size of a TCP project file by using
>>the "precompiled header" feature?  If so, could some kind soul
>>email or post a description of the strategy one would use.
>>
>
>I'll add this to the next version of the FAQ.
>
>The answer is yes.  You just add your TCL headers to Mac #includes.c and
>Precompile.  Presumeably you would want to make a separate file, called
>something like "Traps+TCL Headers".


   There is a nasty trap in this. If you precompile your headers using
"Generate 68881 instructions", and then use them in a project which do
not use 68881 your program will work perfectly on your machine (which
has a 68881), but will crash on a machine without 68881.

   This caused our biggest panic to date (it was The Important Possible
Customer who had the FPU-less mac), and took two days and one night to
figure out.



   Precompiling headers is the first thing to do to reduce project size.
It chopped 75% of mine. If you are still not satisfied, you can turn of
debugging on files where you don't think you need it. That's the grey
dot to the left of file name.



  -  -  -  -
Wise Quote: "You want to know how to paint a perfect painting? It's easy.
Make yourself perfect and then just paint naturally. That's the way all the
experts do it." - Robert M Pirsig in ZATAOMM.

Lars Petrus, Solna, Sweden  -  [e-mail]

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

From: Andrew Gilmartin <[e-mail]>
Date: 3 Sep 1992 14:07:17 GMT
Organization: Brown University

In article <[e-mail]> Dan Emery,
[e-mail] writes:

>Is it possible to reduce the size of a TCP project file by
using
>the "precompiled header" feature?  If so, could some kind soul
>email or post a description of the strategy one would use.

The TCL-Talk archive at ftp.brown.edu:/pub/tcl/misc has a TCL
header file that I use for debugging. Using this header my
projects are 50-60% smaller.

- --
Andrew Gilmartin
Computing & Information Services
Brown University

[e-mail]

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

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