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

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

C.S.M.P. Digest             Tue, 20 Oct 92       Volume 1 : Issue 195

Today's Topics:

    CopyBits question
    LockPixels() before every CopyBits()?
    Many Questions about _Launch, but few answers...
    Finding file/dir size using it's FSSpec
    How to <<Readln>> from a text referenced by a handle??
    Temporary heaps
    ThC 5.0.3 address reg allocation



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] (Christopher Suley)
Subject: CopyBits question
Date: 11 Sep 92 00:14:09 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

I have a color image residing in an offscreen pixmap that I want to
CopyBits to the screen.  Not too hard, but there's a catch.  I want
all of the white pixels in the offscreen image to become a certain
color when they appear on the screen.

Using transparent mode doesn't work, because it leaves what was on
the screen beforehand in place, and that isn't what I want.  I
suppose I could just do a FillRect with the color I want, and then
a CopyBits in transparent mode, but I was hoping to be able to do
everything in one step.  (it's an animated image, so filling the
rectangle then copying would introduce some flickering as the area
was cleared, then redrawn each time)

Setting the background color to the color I want would work, but it
would colorize the rest of the image. (right?  I am programming on
an SE, so this color stuff is mostly a mental experiment until I
run up the massive hill to school and test it on a color computer
there... talk about an expensive code/compile/run cycle. ;)

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

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 12 Sep 92 06:46:24 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Christopher Suley) writes:
> I have a color image residing in an offscreen pixmap that I want to
> CopyBits to the screen.  Not too hard, but there's a catch.  I want
> all of the white pixels in the offscreen image to become a certain
> color when they appear on the screen.

This is easy, provided the offscreen pixmap is an indexed one. In an indexed
pixmap, a pixel represents white because it indexes into a CLUT entry containing
white. Want that pixel value to represent a colour other than white? Just
change the CLUT entry!

> Setting the background color to the color I want would work, but it
> would colorize the rest of the image. (right?  I am programming on
> an SE, so this color stuff is mostly a mental experiment until I
> run up the massive hill to school and test it on a color computer
> there... talk about an expensive code/compile/run cycle. ;)

Aye, that it would. Also remember that the colouring effect is different
between System 6 and System 7; the effect under System 6 is dependent on
a whole bunch of other entries in the CLUT (the gory details are in TN 163),
whereas System 7 interpolates between the foreground and background colours.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
I don't claim to be consistent. Yes I do!

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

From: [e-mail] (Joe Francis)
Date: 13 Sep 92 23:49:31 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

> This is easy, provided the offscreen pixmap is an indexed one. In an indexed
> pixmap, a pixel represents white because it indexes into a CLUT entry containing
> white. Want that pixel value to represent a colour other than white? Just
> change the CLUT entry!

But if that also happens to be the CLUT of the current gDevice, and
white happens to be the background color of the current gDevice, won't
this technique cause the entire CopyBits result to be colorized?

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

From: [e-mail] (Jan Rune Andreassen)
Date: 17 Sep 92 02:18:29 GMT
Organization: The University of Texas at Austin, Austin TX


   As the header say's I'm looking a translator, preferably a
PD or Shareware kind. If anyone knows where I can get it or
an FTP source where it might be it would be very helpful.
   Any hints or tips will be grately appriciated.
    Later
        JR

P.S.  I'm posting this for a friend, I'm not much of a Mac
person (I play on IBM's...).
 [e-mail]

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

From: [e-mail] (Reid Ellis)
Subject: LockPixels() before every CopyBits()?
Date: 11 Sep 92 21:32:20 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Inside Mac V says that LockPixels() must be called before drawing into
an offscreen GWorld.  And yet the examples within the next few pages
don't call LockPixels()!  What's the scoop here?

I think I've tracked down a bug in our program where it crashes on a
Quadra 700 but not on a IIci during a call to CopyBits().  On the
Quadra, the baseAddr of one of the bitmaps was F9001000, which was way
out of line with other addresses.  I would guess it's either invalid
or the address of the built-in VRAM.  I can't find any doc that says
"The 32-bit address of the Quadra's VRAM is xxxx".

Assuming that the address is okay, I noticed that we don't call
LockPixels() before CopyBits().  After inserting calls to LockPixels()
and UnlockPixels(), it looks something like this:

    HLock((Handle) pixHandle1);
    HLock((Handle) pixHandle2);
    LockPixels(pixHandle1);
    LockPixels(pixHandle2);
    CopyBits((BitMap *)*pixHandle1, (BitMap *)*pixHandle2, ...);
    UnlockPixels(pixHandle2);
    UnlockPixels(pixHandle1);
    HUnlock((Handle) pixHandle2);
    HUnlock((Handle) pixHandle1);

Now this seems to be a bit much for every call to CopyBits.  Is this
trip really necessary?  Would it be quicker to check to see is each
PixMapHandle is offscreen?

I'm off now to try it out.  I'm kind of hoping the address is just
invalid and not in VRAM :-)..

Reid
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

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

From: [e-mail] (Kenneth Knight)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Sat, 12 Sep 1992 22:25:27 GMT

In article <[e-mail]> Reid Ellis <[e-mail]> writes:
>Inside Mac V says that LockPixels() must be called before drawing into
>an offscreen GWorld.  And yet the examples within the next few pages
>don't call LockPixels()!  What's the scoop here?
>
>I think I've tracked down a bug in our program where it crashes on a
>Quadra 700 but not on a IIci during a call to CopyBits().  On the
>Quadra, the baseAddr of one of the bitmaps was F9001000, which was way
>out of line with other addresses.  I would guess it's either invalid
>or the address of the built-in VRAM.  I can't find any doc that says
>"The 32-bit address of the Quadra's VRAM is xxxx".
>
>Assuming that the address is okay, I noticed that we don't call
>LockPixels() before CopyBits().  After inserting calls to LockPixels()
>and UnlockPixels(), it looks something like this:
>
>    HLock((Handle) pixHandle1);
>    HLock((Handle) pixHandle2);
>    LockPixels(pixHandle1);
>    LockPixels(pixHandle2);
>    CopyBits((BitMap *)*pixHandle1, (BitMap *)*pixHandle2, ...);
>    UnlockPixels(pixHandle2);
>    UnlockPixels(pixHandle1);
>    HUnlock((Handle) pixHandle2);
>    HUnlock((Handle) pixHandle1);
>
>Now this seems to be a bit much for every call to CopyBits.  Is this
>trip really necessary?  Would it be quicker to check to see is each
>PixMapHandle is offscreen?

You can remove the HLock/HUnlcok calls certainly. I'd keep the LockPixels/
UnlockPixels() calls in place.

  ** Ken **


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

From: [e-mail]
Date: 13 Sep 92 04:22:33 GMT
Organization: Wright State University

> Assuming that the address is okay, I noticed that we don't call
> LockPixels() before CopyBits().  After inserting calls to LockPixels()
> and UnlockPixels(), it looks something like this:
>
>     HLock((Handle) pixHandle1);
>     HLock((Handle) pixHandle2);
>     LockPixels(pixHandle1);
>     LockPixels(pixHandle2);
>     CopyBits((BitMap *)*pixHandle1, (BitMap *)*pixHandle2, ...);
>     UnlockPixels(pixHandle2);
>     UnlockPixels(pixHandle1);
>     HUnlock((Handle) pixHandle2);
>     HUnlock((Handle) pixHandle1);
>
> Now this seems to be a bit much for every call to CopyBits.

LockPixels and UnlockPixels should be suffucient; the HLock and
HUnlock aren't needed. I think you may need to be calling
GetGWorldPixMap instead of getting the pixMap directly (except
under ColorQD version 1.2 where it's broken (see the Q & A stack)).

IM VI just says use GetGWorldPixMap without much explanation. I've
imagined this makes a difference with GWorlds on graphic accelerators
or temporary memory, but I don't really know.

Any thoughts?

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
|      "Whom the gods would destroy, they first invite to program in C"      |
o----------------------------------------------------------------------------o

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

From: [e-mail] (Dave T. Berquist)
Organization: 3M Company
Date: Sun, 13 Sep 92 22:39:55 GMT

In article <[e-mail]> [e-mail] writes:
>> Assuming that the address is okay, I noticed that we don't call
>> LockPixels() before CopyBits().  After inserting calls to LockPixels()
>> and UnlockPixels(), it looks something like this:
>>
>>     HLock((Handle) pixHandle1);
>>     HLock((Handle) pixHandle2);
>>     LockPixels(pixHandle1);
>>     LockPixels(pixHandle2);
>>     CopyBits((BitMap *)*pixHandle1, (BitMap *)*pixHandle2, ...);
>>     UnlockPixels(pixHandle2);
>>     UnlockPixels(pixHandle1);
>>     HUnlock((Handle) pixHandle2);
>>     HUnlock((Handle) pixHandle1);
>>
>> Now this seems to be a bit much for every call to CopyBits.
>
>LockPixels and UnlockPixels should be suffucient; the HLock and
>HUnlock aren't needed. I think you may need to be calling
>GetGWorldPixMap instead of getting the pixMap directly (except
>under ColorQD version 1.2 where it's broken (see the Q & A stack)).
>
>IM VI just says use GetGWorldPixMap without much explanation. I've
>imagined this makes a difference with GWorlds on graphic accelerators
>or temporary memory, but I don't really know.
>
>Any thoughts?
>

GetGWorldPixMap should be used if system 7 is available, otherwise get
the pixmap right from the gworld for system 6.  (GetGWorldPixMap does
not work under system 6 - I know, I have tried it).

- - Dave Berquist


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

From: [e-mail] (Humayun Lari)
Date: 16 Sep 92 00:07:10 GMT
Organization: The University of North Carolina at Chapel Hill

In article <[e-mail]> [e-mail] writes:
>IM VI just says use GetGWorldPixMap without much explanation. I've
>imagined this makes a difference with GWorlds on graphic accelerators
>or temporary memory, but I don't really know.

I seem to remember reading somewhere that GetGWorldPixMap is recommended
so that your code works on machines that do not have Color Quickdraw
(e.g. Classics under 7.x), since a GWorldPtr on such machines points to an
extended GrafPort rather than a CGrafPort.

Humayun Lari
([e-mail])

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

From: [e-mail] (Reuben Mezrich)
Subject: Many Questions about _Launch, but few answers...
Date: 14 Sep 92 20:35:56 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


     I think that the _Launch command must be one of the greatest
mysteries (sp?) of the pre-system 7 toolbox.  Does anybody have any
idea how to properly use this trap ?  I've have a fair amount of
success in using it, but have run into the difficulty that, under
System 6, multifinder does not seem to use it at all.  I've used the
_Launch command successfully under system 6 running the finder, and
under system 7, but have had no success under system 6 running multifinder.
It does launch the application, but it does not behave as it should
(it clears the screen and closes other background applications).
     Does anyone out there have any idea how system 6 multifinder
launches an application, or know where I might seek this information ?
I've seen several questions about the _Launch command posted, but
there does not seem to be a wealth of information available.  I am
writing an INIT which will allow executing applications with a single
key stroke (or key combination), and hope to make it available when
(or if) I am able to finish it.
     Please do not respond to this message using Email, as this is not
my account.  It is a friends and I am just using it until my account
comes up.  I do not check the mail.  Please respond on this newsgroup.

                                         Much Thanks,
                                                Dave Grossberg

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

From: [e-mail] (Matthew Xavier Mora)
Date: 14 Sep 92 22:34:17 GMT
Organization: SRI International

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


>      I think that the _Launch command must be one of the greatest
> mysteries (sp?) of the pre-system 7 toolbox.  Does anybody have any
> idea how to properly use this trap ?  I've have a fair amount of
> success in using it, but have run into the difficulty that, under
> System 6, multifinder does not seem to use it at all.  I've used the
> _Launch command successfully under system 6 running the finder, and
> under system 7, but have had no success under system 6 running multifinder.
> It does launch the application, but it does not behave as it should
> (it clears the screen and closes other background applications).

Its not a great mystery, your just not supposed to use it.
You probably have the wrong flags set.

I have used the version supplied in the technote # 126
"Sublaunching:Playing the shell Game" and it worked for me. Show us your
code and maybe we can see what you are doing wrong. Don't forget the you
need to set both high bits
(Launchflags := $C000000) to sublaunch.

Matt

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

From: [e-mail] (Tim Endres)
Date: 16 Sep 92 16:51:49 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> ([e-mail]), you write:
>
>      I think that the _Launch command must be one of the greatest
> mysteries (sp?) of the pre-system 7 toolbox.  Does anybody have any
> idea how to properly use this trap ?  I've have a fair amount of
> success in using it, but have run into the difficulty that, under
> System 6, multifinder does not seem to use it at all.  I've used the
> _Launch command successfully under system 6 running the finder, and
> under system 7, but have had no success under system 6 running multifinder.
> It does launch the application, but it does not behave as it should
> (it clears the screen and closes other background applications).
>      Does anyone out there have any idea how system 6 multifinder
> launches an application, or know where I might seek this information ?
> I've seen several questions about the _Launch command posted, but
> there does not seem to be a wealth of information available.  I am
> writing an INIT which will allow executing applications with a single
> key stroke (or key combination), and hope to make it available when
> (or if) I am able to finish it.
>      Please do not respond to this message using Email, as this is not
> my account.  It is a friends and I am just using it until my account
> comes up.  I do not check the mail.  Please respond on this newsgroup.

The difficulty arises in the sense that under Multi-Finder System-6
Launch can RETURN! You must bre prepared for the call to return and
for it not to return. This is a PAIN! In essence, you are *forced*
to come up with a method of determining if MultiFinder is running
(which Apple still claims you can not do) if your code depends upon
knowing if launch returns.

My code did, since I had to close files if not under MultiFinder.

Anyways....

Here's some code.

Some Assembler:

;
; Written by Tim Endres.
;

;
; OSErr Launchit(pb_launch)
;     PBLaunch        *pb_launch;
;     extern
;

    INCLUDE 'traps.a'
    CASE    OBJECT

Launchit    PROC    EXPORT
    move.l        4(sp), a0    ; Get pointer to prameter block
    _Launch

    ; NOTE: We *can return* under MultiFinder...

    move.l        (sp)+, a0    ; Get return address off stack
    addq        #$4, sp        ; dump the parameter
    jmp            (a0)        ; return to caller

    ENDP

    END

Some C code:

/*
**
** Written by Tim Endres.
*/

/* $$FILE UniLaunch.c
** UniLaunch.c contains the routine which launches applications.
** UniLaunch causes applications to be ru, just like the Finder does,
** as well as allowing documents to be opened at launch time.
*/

#include <types.h>
#include <memory.h>
#include <files.h>
#include <errors.h>

extern short    launch_returns;
extern short    app_done;

typedef struct {
    char    *app_name;
    short    param;
    char    LC[2];
    long    ext_blk_len;
    short    finder_flags;
    long    launch_flags;
    } PBLaunch;

static char        pascal_app_name[256];

#define AppParmHandle    (* (Handle *) 0x0AEC)

#define ALERT_ALERT        1

extern pascal Boolean RunStateFilter();

typedef struct {
    short    message;
    short    number;
    short    vrefnum;
    long    type;
    unsigned char version;
    unsigned char unused;
    char    document[1];
    } AppParms;

/* $$FUNCTION LaunchDoc
** Launch a Macintosh application with an associated document (or not).
** 'app_name' is the name of the application to be launched.
** 'vrefnum' is the working directory the application file can be located with.
** 'doc_name' is the name of a document to be opened with the application launch.
** If 'doc_name' is NULL, then no document is opened. If 'doc_name' is not NULL,
** then doc_type is the Finder file type (e.g. 'TEXT') of the file 'doc_name,
** with the four type characters represented by the bytes in the long integer.
** For Full Details, See Technical Note #126
*/
LaunchDoc(app_name, app_vrefnum, doc_name, doc_vrefnum, doc_type)
char    *app_name;
int        app_vrefnum;
char    *doc_name;
int        doc_vrefnum;
long    doc_type;
{
short        err;
PBLaunch    pbl;
CInfoPBRec    cpb;
AppParms    *parm_ptr;
Handle        parm_handle;
THz            save_zone;

    strcpy(&pascal_app_name[1], app_name);
    pascal_app_name[0] = (unsigned char) strlen(app_name);
    cpb.hFileInfo.ioNamePtr = pascal_app_name;
    cpb.hFileInfo.ioVRefNum = app_vrefnum;
    cpb.hFileInfo.ioFDirIndex = 0;
    cpb.hFileInfo.ioDirID = 0;

    err = PBGetCatInfo(&cpb, false);
    if (err != noErr)
        {
        message_alert("Error #%d trying to find file '%s'!\n", err, app_name);
        }
    else {
        /*
        ** First, if the document 'doc_name' is not NULL, then
        ** establish the Application Parameters.
        */
        parm_handle = AppParmHandle;
        if (parm_handle != NULL)
            DisposHandle(parm_handle);
        AppParmHandle = NULL;

        if (doc_name != NULL)
            {
            parm_handle = AppParmHandle;
            if (parm_handle != NULL)
                DisposHandle(parm_handle);

            save_zone = GetZone();
            SetZone(SystemZone());
            /*
            ** Don't worry about this handle. :-)
            ** _Launch appears to be smart enough to
            ** copy it into the launched application's
            ** heap and then toss it.
            */
            parm_handle = NewHandle(sizeof(AppParms) + strlen(doc_name) + 2);
            SetZone(save_zone);
            if (parm_handle != NULL)
                {
                parm_ptr = (AppParms *) *parm_handle;
                parm_ptr->message = 0;
                parm_ptr->number = 1;
                parm_ptr->vrefnum = doc_vrefnum;
                parm_ptr->type = doc_type;
                parm_ptr->version = 0;
                parm_ptr->unused = 0;
                parm_ptr->document[0] = strlen(doc_name);
                strncpy(&parm_ptr->document[1], doc_name, parm_ptr->document[0]);
                AppParmHandle = parm_handle;
                }
            }

        /*
        ** Now, launch the application.
        */
        SetVol(NULL, app_vrefnum);
        pbl.app_name = pascal_app_name;
        pbl.param = 0;
        pbl.LC[0] = 'L';
        pbl.LC[1] = 'C';
        pbl.ext_blk_len = 6;
        pbl.finder_flags = cpb.hFileInfo.ioFlFndrInfo.fdFlags;
        pbl.launch_flags = 0xC0000000;
        err = Launchit(&pbl);
        if (err < 0)
            {
            if (err == -10)    /* Not really sure why, but I *think* I've seen this with OLD ROMs! */
                message_alert("Error #%d launching '%s'.\015Probably due to insufficient memory.",
                                err, app_name);
            else if (err == fnfErr)
                message_alert("Could not find application '%s'!", app_name);
            else if (err == memFullErr)
                message_alert("Not enough memory available to launch '%s'!", app_name);
            else
                message_alert("Error #%d launching '%s'!", err, app_name);
            }

        }

    }


tim endres - [e-mail]  -or- tbomb!time
ICE Engineering, Inc - 8840 Main St, Whitmore Lake, MI 48189
Phone [phone] - FAX [phone]
USENET - a slow moving self parody... ph

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

From: [e-mail] (Eshel Liran)
Subject: Finding file/dir size using it's FSSpec
Date: 16 Sep 92 12:02:46 GMT
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel

How can I find the size of a file or a folder using it's FSSpec record ?

Liran Eshel
[e-mail]

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

From: [e-mail] (Leonard Rosenthol)
Date: Wed, 16 Sep 92 18:47:29 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Eshel Liran) writes:
>How can I find the size of a file or a folder using it's FSSpec record ?
>
    Finding the size of a file is easy - just use the information in
the FSSpec to setup an HParamBlockRec and call PBHGetFInfo.  Two of ther
returned fields are ioFlPyLen & ioFlRPyLen which is the physical size (amount
of disk space used) of the data & resource forks (respectively) of a file.

    In the case of a folder, you will have to recursively walk the hier-
archy using PBGetCatInfo calls and then add up the above info on each file
found.

    One thing of note - if the user has a transparent compression product
installed, the information returned may not be exactly what you expect - in
the case of StuffIt SpaceSaver (and AutoDoubler 2.0, I believe) the physical
sizes are the "compressord" sizes since that is the size on disk, while the
logical sizes are the "expanded" sizes since that is the real amount of data.
Howevever, in the case of More Disk Space, it returns the compressed sizes
for both the logical & physical (you can't get the expanded size of a file
w/o opening it first!).

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician


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

From: [e-mail] (Michael Peirce)
Date: 16 Sep 92 21:40:57 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Eshel Liran) writes:
> How can I find the size of a file or a folder using it's FSSpec record ?

How about PBGetCatInfo?  If you are going to be doing nay file stuff you
really should read the Inside Macintosh chapters on the File Manager.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

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

From: [e-mail] (Kent Sandvik)
Date: 17 Sep 92 02:28:58 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] (Eshel Liran) wrote:
>
> How can I find the size of a file or a folder using it's FSSpec record ?
>
> Liran Eshel
> [e-mail]

PBGetCatInfo should return information for defining the size of
the data fork, as in:

theSize = theCPB.hFileInfo.ioFlLgLen - theCPB.hFileInfo.ioFlStBlk;

You could call PBGetCatInfo, as in:

 theCPB.hFileInfo.ioFDirIndex = -1;
    theCPB.hFileInfo.ioVRefNum = VRefNum;
    theCPB.hFileInfo.ioDirID = DirID;
    theCPB.hFileInfo.ioNamePtr = (StringPtr) &FileName;

 PBGetCatInfo( &theCPB, nil );

This all is ad hoc programming, so it's untested.

Cheers,
Kent/DTS
"I would rather have a thousands idiots attacking my position, than
have one idiot helping to defend it."    [Paraphrased from Voltaire]
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

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

From: [e-mail] (Gary Czychi)
Subject: How to <<Readln>> from a text referenced by a handle??
Date: 15 Sep 92 07:44:58 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

Hi!

I have been told that the Mac (in fact any computer) is very slow reading
textual input from a file line by line.

nd in my application, I have already read in the text of a file in one big
chunk and pass the handle to the place where I process the data.

Now, is there any way for me, to read some of the lines in this handle? I
only need about 10 lines from the top and separate it from the rest, which
is being diplayed in a window as one big part.

I've tried to type coerce the handle to a str255 handle, but then I get a
range error (of course).

If there is no obvious or easy solution, how could I access the data in my
handle byte for byte and then put everything into a Str255 until the next CR
is detected?

As you might want to know, I'm using TH Pascal.

Thanks a lot for any help.

  Gary

    Gary T. Czychi          University of St.Gallen

       [e-mail] (preferred host)
         czychi at csghsg52   (=bitnet)
           [e-mail]
             Switzerland
              -

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

From: [e-mail] (Peter N Lewis)
Date: 16 Sep 92 01:32:12 GMT
Organization: NCRPDA, Curtin University

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

> nd in my application, I have already read in the text of a file in one big
> chunk and pass the handle to the place where I process the data.

{$R-}
procedure ReadALine(h:handle; var s:str255);
var
  p:ptr;
  size,len:longInt;
begin
  p:=h^;
  size:=GetHandleSize(h);
  len:=0;
  while (size>0) & (p^ <> 13) do begin
    p:=ptr(ord(p)+1);
    size:=size-1;
    len:=len+1;
  end;
  if len>255 then len:=255;
  s[0]:=chr(len);
  BlockMove(h^,@s[1],len);
  if size>0 then begin
    p:=ptr(ord(p)+1); { Skip over the <cr> }
    size:=size-1;
    BlockMove(p,h^,size);
  end;
  SetHandleSize(h,size);
end;

I tested this code, it seems to work ok.  Note, if you were going to read
lots of lines, you'd be better keeping an offset, and avoiding the block
move all the time, but the above will work ok, and isn't *that* inefficent,
it depends how many times you want to call ReadALine, if its 10 or 20, no
problem, if its 10 or 20 thousand, then some rethinking would be
necessary...
   Peter.

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

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

From: [e-mail] (Rhys Hollow)
Date: 16 Sep 1992 11:23:15 +0800
Organization: The University of Westrn Australia

[e-mail] (Peter N Lewis) gives a useful example of
implementing a Readln with a handle-referenced block of text :

>{$R-}

But wait!  What is this?? Turning Rangechecking off?  I wonder what that
could be for?  What's that you say?  Think Pascal will range check if
you try to set the length byte of the string?  Think Pascal will range
check if you access the string s[x] where x is greater than Length(s)?
You're kidding right?  Think Pascal couldn't possibly be that stupid
surely?  Oh dear, I think it is.

<Rhys bangs head against the wall <bang> <bang> <bang> >

>procedure ReadALine(h:handle; var s:str255);
[Body of procedure deleted]
>end;


Hmm, don't forget to turn Range Checking back on Pete!

Rhys.
- --
Rhys Hollow ([e-mail]) "ee'er by gum he's a bad'un!" -DangerMouse.

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

From: [e-mail] (David T. Greenfield)
Date: 18 Sep 92 17:50:28 GMT
Organization: Dartmouth College, Hanover, NH

In article <peter-160992091557@134.7.50.3>
[e-mail] (Peter N Lewis) writes:

> procedure ReadALine(h:handle; var s:str255);
> var
>   p:ptr;
>   size,len:longInt;
> begin
>   p:=h^;
>   size:=GetHandleSize(h);
>   len:=0;
>   while (size>0) & (p^ <> 13) do begin
>     p:=ptr(ord(p)+1);
>     size:=size-1;
>     len:=len+1;
>   end;
>   if len>255 then len:=255;
>   s[0]:=chr(len);
>   BlockMove(h^,@s[1],len);
>   if size>0 then begin
>     p:=ptr(ord(p)+1); { Skip over the <cr> }
>     size:=size-1;
>     BlockMove(p,h^,size);
>   end;
>   SetHandleSize(h,size);
> end;


Will this work for scripts that use 2 byte characters?


David
[e-mail]

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

From: [e-mail] (Jeremy Roussak)
Subject: Temporary heaps
Date: 16 Sep 92 22:57:33 GMT
Organization: Computer Science Dept, QMW, University of London

I'm having a problem with something I had thought rather clever. It seems
I am less intelligent than I thought.

I have written an INIT. To save memory, the INIT keeps most of its code
on disk, rather than resident. When needed, the resource file is opened,
the code loaded and run and the resource file closed. Since some apps
run with little space in their heaps, there sometimes isn't enough room
to load and run these modules, so I have been putting up an alert to
that effect. This seems inelegant at best, so I tried the following
solution.

1. Allocate a temporary memory handle large enough for the code
   resource and plenty of spare memory.

2. Lock it and set it up as a heap zone

3. Open the resource file, do various things, close the resource file

4. Reset the current zone and dispose of the temporary handle.

This works most of the time, but I have been getting a lot of random
crashes, some a good many minutes after the procedure above. Sometimes
the new heap is corrupt at the end of the procedure (although the code
never corrupts the application heap if it's run there). Hacking with
MacsBug indicates that sometimes (but not always), the heap is OK before
_CloseResFile and corrupt afterwards.

So, is there a problem with the resource manager? In his notes to
Disinfectant source, John Norstad makes a point about a comment in IM II
that the current zone should be the same as the resource's zone before
_ReleaseResource. Could the releasing of resources which goes with
_CloseResFile be responsible? Has anyone out there tried to do
anything as weird as this? Am I an isolated pervert?

Jeremy

code follows: no comments on layout, please!

#define zoneSize 0x18000        /* 96k: easily large enough */

static Handle TempZone(void)
 {  Ptr zone;
    short err;
    Handle result;

    unless ((result = TempNewHandle(zoneSize, &err))==nil)
     {  HLock(result);
        zone = StripAddress(*result);
        InitZone(nil, 64, zone+zoneSize, zone);
     }

    return result;
 }


main()
 {  THz oldZone;
    Handle newZone;

    oldZone = TheZone;
    newZone = TempZone();

/* then OpenResFile, do various things, CloseResFile */

    if (newZone!=nil)
     {  TheZone = oldZone;
        DisposHandle(newZone);
     }
 }

Running under system 7, 24-bit, no VM.

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

From: [e-mail] (Leonard Rosenthol)
Date: 17 Sep 92 06:32:59 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Jeremy Roussak) writes:
>I have written an INIT. To save memory, the INIT keeps most of its code
>on disk, rather than resident. When needed, the resource file is opened,
>the code loaded and run and the resource file closed. Since some apps
>run with little space in their heaps, there sometimes isn't enough room
>to load and run these modules, so I have been putting up an alert to
>that effect. This seems inelegant at best, so I tried the following
>solution.
>
> [Details of setting up own heap]
>
>This works most of the time, but I have been getting a lot of random
>crashes, some a good many minutes after the procedure above. Sometimes
>the new heap is corrupt at the end of the procedure (although the code
>never corrupts the application heap if it's run there). Hacking with
>MacsBug indicates that sometimes (but not always), the heap is OK before
>_CloseResFile and corrupt afterwards.
>
    One thing that I have found in doing this (creating your own heap
in an INIT) is that there are some trap calls which set low memory globals
which will try to rference data back into your no longer existant heap. The
BEST example of this is ParamText, but there are others...

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

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

From: [e-mail] (Jamie R. McCarthy)
Subject: ThC 5.0.3 address reg allocation
Organization: Kalamazoo College
Date: Thu, 17 Sep 1992 15:44:20 GMT

I'm playing around, making a code segment, and there's a short bit where
I need four address registers.  Turns out I only get two!  If I
understand correctly, A7, A6, and A5 are the system's;  A4 is my
globals, and A0 and A1 are reserved for scratch use.

It seems kinda silly to me that I can't force it to give me A0 and A1
without specifically specifying them.  (And, consequently, saving and
restoring them on the stack whenever I mix assembly and C code in the
same function.  Ick.)  Has ThC always done this, or is this new to
version 5.0.3?

Just wondering...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "It's bad enough to send a rude message to another via such an anonymous
  channel [as email].  To flame someone on an open forum is, to me, the
  height of insensitivity."                                 - P.J. Plauger

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

From: [e-mail] (Tom Emerson)
Date: 17 Sep 92 20:11:24 GMT
Organization: University of Vermont, EMBA Computer Facility

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

   I'm playing around, making a code segment, and there's a short bit where
   I need four address registers.  Turns out I only get two!  If I
   understand correctly, A7, A6, and A5 are the system's;  A4 is my
   globals, and A0 and A1 are reserved for scratch use.

You can use registers A0 and A1 without saving them in your function. However
they are used for scratch, like you said, so you can't save them. As far as I
know, THC has always used this technique. You could also use A2 and A3, though
these are sometimes used by the compiler/optimizer. In general it would be
safest to save them on the stack first. Or define those registers as register
variables and let the compiler take care of it for you.

Tom
- --
   Tom Emerson                                    Technical Support
   Language Products Group                     Symantec Corporation
            Internet: [e-mail]

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

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