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

Text File | 1994-12-08 | 33.6 KB | 932 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 08 Nov 92       Volume 1 : Issue 209

Today's Topics:

    What does DrawPicture() want?
    >moving the mouse
    CTB Questions and Answers
    CASE tools
    Changing 'STR#'s
    Vendors for Mac assemblers?  Which are decent?



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] (Eric Weidl)
Subject: What does DrawPicture() want?
Organization: Academic and Public Computing
Date: Thu, 24 Sep 1992 20:35:52 GMT



All,
    I'm writing a simple application using the THINK Class Library (1.1.2)
to display PICT files and I'm having a problem with the toolbox DrawPicture()
routine.  My app opens the file with no problem, I can verify that the
PicHandle is valid and contains valid data, etc. etc.  When I pass call
DrawPicture() with the PicHandle, it fails with an out of memory error (-108),
and executes my exception handler.
    Now, I know that I can increase the application's partition, but the
problem is deeper than that.  I want to know why DrawPicture fails.  I check
the amount of free space available using MaxMem() before I call DrawPicture,
and don't bother if it's not double the size of the PicHandle.  But why
should DrawPicture need twice as much memory as the PicHandle; it's already
in memory.  Even with twice the memory it occasionally doesn't draw.
    I watched the application's heap with Swatch to try to figure out how
much space DrawPicture was using.  To my surprise, it wasn't using any (at
least that Swatch knew about.)  If I had 100K free before I called DrawPicture,
I had 100K free afterwards.  So why is DrawPicture choking?

    Is there any way to determine how much memory a PICT will need before
calling DrawPicture?

Thanks.

- --
===================================================================
               Eric Weidl    [e-mail]
      University of Chicago -- Academic and Public Computing
===================================================================

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

From: [e-mail] (Matt Mora)
Date: 25 Sep 92 16:18:50 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] writes:

>I had 100K free afterwards.  So why is DrawPicture choking?


Did you lock the picthandle before you called drawpicture? DrawPicture
is a routine that WILL move memory.


Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

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

From: [e-mail] (Larry Rosenstein)
Date: 25 Sep 92 23:41:58 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>
> Did you lock the picthandle before you called drawpicture? DrawPicture
> is a routine that WILL move memory.

I didn't think this was necessary.  QuickDraw should lock the handle if it
needs to.

In article <[e-mail]>,
[e-mail] (Eric Weidl) wrote:
>
> the amount of free space available using MaxMem() before I call DrawPicture,
> and don't bother if it's not double the size of the PicHandle.  But why
> should DrawPicture need twice as much memory as the PicHandle; it's already

Images (CopyBits calls) are usually compressed.  QuickDraw might uncompress
the whole thing before doing the actual CopyBits, in which case QuickDraw
could need enough memory to hold the whole image.

>     I watched the application's heap with Swatch to try to figure out how
> much space DrawPicture was using.  To my surprise, it wasn't using any (at
> least that Swatch knew about.)  If I had 100K free before I called DrawPicture,

I'm not sure that Swatch will update its display in the middle of the
DrawPicture.  If the DrawPicture fails, QuickDraw should free everything it
allocated, so the before and after free space should be the same.

Larry Rosenstein
Taligent, Inc.

[e-mail]

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

From: [e-mail] (Humayun Lari)
Date: 26 Sep 92 20:58:31 GMT
Organization: The University of North Carolina at Chapel Hill

In article <[e-mail]> [e-mail] writes:
[calling DrawPicture causes exception with memFullErr]

I ran into a similar problem the other day, while implementing a
CDiskPictFile class that would draw pictures directly from disk.

Here's my analysis of what happened -- perhaps your situation is similar:
1. DrawPicture asks for lots of memory (perhaps it wants to allocate a pixmap
   as large as the picture).
2. Since there isn't enough memory, the TCL's grow zone function is executed,
   and tries to free memory (e.g. from the rainy day fund) in the hope that
   that will satisfy the request.

   That doesn't work. So, the grow zone function checks whether the allocation
   is permitted to fail. Nope -- I haven't called SetAllocation(kAllocCanFail).
   Since an unfulfilled memory request could cause crashes, it raises a
   memFullErr exception.

My solution was to enclose the DrawPicture call with calls to SetAllocation.
DrawPicture worked fine; perhaps it uses temporary memory if necessary?
To see if DrawPicture actually managed to draw the picture, I took a look at
QDError and also checked whether the rainy day fund had been depleted.

Anyone know of a more elegant way of handling this?


Humayun Lari
([e-mail])

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

From: [e-mail] (Steve Riggins)
Date: 27 Sep 92 16:48:28 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Humayun Lari) writes:
>In article <[e-mail]> [e-mail] writes:
>[calling DrawPicture causes exception with memFullErr]
>
>I ran into a similar problem the other day, while implementing a
>CDiskPictFile class that would draw pictures directly from disk.
>
>Here's my analysis of what happened -- perhaps your situation is similar:
>1. DrawPicture asks for lots of memory (perhaps it wants to allocate a pixmap
>   as large as the picture).
>2. Since there isn't enough memory, the TCL's grow zone function is executed,
>   and tries to free memory (e.g. from the rainy day fund) in the hope that
>   that will satisfy the request.
>
>   That doesn't work. So, the grow zone function checks whether the allocation
>   is permitted to fail. Nope -- I haven't called SetAllocation(kAllocCanFail).
>   Since an unfulfilled memory request could cause crashes, it raises a
>   memFullErr exception.
>

What is your stack heap set to?  Is the TCL growing it?  I've had a
lot of problems with CopyBits (which DrawPicture may call) and solved
it
by lowering the AppleLimit and the beginning of execution, prior to my
MaxApplZone call.  By default, a non color QD machine allocates 8K of
RAM to the stack, and on a color QD Mac, you get 32K.  Copybits uses
the
stack, so often, 32K is not enough.  Try an addition 64K.

- --
Steve Riggins                  Internet: [e-mail]
AppleLink:  Voyager.geek       AOL:      RigginsS
CompuServe: 75300,1635         "Can never have enough EMail addresses"

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

From: [e-mail] (Matt Mora)
Date: 28 Sep 92 16:21:21 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:
>In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>>
>> Did you lock the picthandle before you called drawpicture? DrawPicture
>> is a routine that WILL move memory.
>
>I didn't think this was necessary.  QuickDraw should lock the handle if it
>needs to.

IM doesn't say that Drawpicture locks the handle. I did an 'ir drawpicture'
in macsbug and didn't see a hlock. (though I'm not sure thats the right
command to use). I seem to remember a program I wrote a long time ago
would crash occasionally. It was drawing a complicated pict as a header
in a window. When I added hlock before the drawpicture calls the random
crashes disappered. I may have locked some other stuff too, its been a while.
Anyway, try locking the picture first then drawpicture.

Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

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

From: [e-mail] (Larry Rosenstein)
Organization: Taligent, Inc.
Date: Mon, 28 Sep 1992 21:26:37 GMT

In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>
> IM doesn't say that Drawpicture locks the handle. I did an 'ir drawpicture'
> in macsbug and didn't see a hlock. (though I'm not sure thats the right

IM also doesn't say that locking the handle is necessary before calling
DrawPicture.  I don't recall reading this in a Tech Note either.

DrawPicture itself isn't the thing that accesses picture bytes, since this
can be overridden in a capture proc.  If you disassemble StdGetPict,
however, you see that QuickDraw keeps a handle to the picture and the
offset within the picture in private variables and dereferences the handle
each time it needs to access the picture.

> command to use). I seem to remember a program I wrote a long time ago
> would crash occasionally. It was drawing a complicated pict as a header
> in a window. When I added hlock before the drawpicture calls the random

There must be some other explanation.

In general, if the system accepts a handle as input, then it is prepared to
deal with the consequences of the handle's data moving.  The only exception
I know to this is playing a sound handle asynchronously.  (Even then that's
not strictly an exception because the Sound Manager does lock down the
handle for the duration of the call; it's just that when called
asynchronously the sound plays beyond the extent of the call.)

Larry Rosenstein
Taligent, Inc.

[e-mail]

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

From: [e-mail] (Robert M. Fuhrer)
Date: 28 Sep 92 22:32:53 GMT
Organization: Computer Science Dept., Columbia Univ.

I am also being bitten by a Picture-related bug. I am attempting to associate a
PicHandle with a window so that future updates are handled automatically (as
per IM Vol 1, Window Mgr chapter). It seems to work for a stand-alone test
program, but in a more significant one, crashes at the call to SetWindowPic(),
even though the window displays the picture ok just before that. Any clues?

The simplified code looks like:

void Graph(WindowPtr macWin)
{
    PicHandle    pH;
    static Rect    bounds = { 50, -630, 450, -10 };

    KillPicture(GetWindowPic(macWin));

    SelectWindow(macWin);
    SetPort(macWin);

    pH = OpenPicture(&bounds);

    ShowPen();
    EraseRect(&bounds);

    /* ... calls to MoveTo(), Line(), etc. */

    ClosePicture();
    SetWindowPic(macWin, pH);
}
- --

- -- Bob

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

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

In article <1r#[e-mail]> [e-mail] (Steve Riggins) writes:
>In article <[e-mail]> [e-mail] (Humayun Lari) writes:
[my problem with DrawPicture and the TCL deleted]
[Steve suggested increasing the stack]

Actually, DrawPicture seems quite happy now. I'm asking it to draw 100x100
pixel thumbnails of screen snapshots that were taken in 16-bit color, and it's
shrinking and dithering them to 8-bit color with no problem. The application
partition is only 384K -- the pictures themselves would take up that much
memory if they were uncompressed -- but it's drawing them quite happily
(from disk, no less!)

>Copybits uses
>the stack, so often, 32K is not enough. Try and addition 64K.

If I remember correctly, the latest versions of CopyBits divide up their work
so that they can do the job even if there isn't sufficient stack space, and
even allocate memory if necessary. I hope that's true; otherwise, I guess
I'll be increasing the stack size soon...

Humayun Lari
([e-mail])

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

From: [e-mail] (Robert M. Fuhrer)
Date: 4 Oct 92 04:37:20 GMT
Organization: Computer Science Dept., Columbia Univ.

I have received a couple of responses to my posting regarding my problem
installing a PicHandle in a window. Thanks to those who responded for their
help! Now, a summary of the results:

One person advised calling ClipRect() before the call; though I wasn't doing it
before, adding a call didn't help. Another mentioned that SetWindowPic() was a
trivial call; after disassembling it in Macsbug, I saw that that was true; it
does literally stuff the handle in the window record field and return.

I started to suspect other problems, probably memory-related. I tried using
Macsbug "heap spy"; this turned up nothing. However, when I did a heap dump, I
noticed that a control handle for an active modal dialog was unlocked and
purgeable. I suspected this might be a problem. Does this sound reasonable?

Unfortunately, locking the handle didn't solve the problem anyway. Any other
clues?

This snooping did lead to another confusing problem:

I have a modal dialog which has a scroll bar control item in it. The item's
type is thus "control" (4), and the sub-type is scroll-bar (3). If I look at
the DITL resource in ResEdit, the item number is 15. (Which is good, because my
Rez source builds it that way.) Now, when I do a GetDItem() on item #15, it
returns a handle which doesn't match the handle Macsbug reports as the only
CTRL handle in the application. [It always seems to be off by 4 bytes.]

Am I missing something here?
- --

- -- Bob

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

From: [e-mail] (J Eric Bush)
Date: 4 Oct 92 15:47:52 GMT
Organization: The Ohio State University

I have used DrawPicture quite a bit, and I admit that I am starting to read
this strand late in the discussion, but here is some pascal code that I
use with DrawPicture to draw PICT resources:

procedure DrawPict(whichPicture:integer);

var
     thePicture : PicHandle;
     myRect, pictureRect : Rect;

begin
     thePicture:=GetPicture(whichPicture);
     pictureRect:=thePicture^^.picFrame;
     SetRect(myRect,0,0,pictureRect.right-pictureRect.left,
          pictureRect.bottom-pictureRect.top);
     DrawPicture(thePicture, myRect);
end;

Note: if you want to display only part of a picture on the screen, then
      add another RECT variable and set that rectangle to the part of
      the screen you want it to display in (also works with regions),
      then call SetClip or ClipRect procedure followed by DrawPicture.

Hope this is what you wanted, if not, then disregard as 1's and 0's.
- --
- ------------------------------------------------------------------------------
J. Eric Bush
Internet: [e-mail]

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

From: [e-mail] (Jay Krell)
Subject: >moving the mouse
Date: 4 Oct 92 03:39:29 GMT
Organization: Cornell Information Technologies

>> Jay Kreibich, moving the mouse

The IIGS Event Manager has a call FakeMouse that drivers use to move the mouse.
Perhaps the Mac has the same.


[e-mail].

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

From: [e-mail] (Charles Reiman)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Sun, 4 Oct 1992 17:17:21 GMT

[e-mail] (Jay Krell) writes:

>>> Jay Kreibich, moving the mouse
>
>The IIGS Event Manager has a call FakeMouse that drivers use to move the mouse.
>Perhaps the Mac has the same.

Nope. You must muck with system globals. From memory, you must change
both MTemp and RawMouse to the coordinate you want. That should do the
trick. Note that this is dangerous, since a VBL could hit while you are
changing the variables, and the jCrsrTask will proceed to move the
pointer on its own to a strange new location.

FYI: This is based on what I know from beating up on the jCrsrTask. I
have never actually done this from an application environment.

- --
Charlie Reiman             |                  [e-mail]
"This week, Ross Perot guaranteed his place in the record books by playing
peek-a-boo with nearly 250 million people simultaneously."
- --
Charlie Reiman             |                  [e-mail]
"This week, Ross Perot guaranteed his place in the record books by playing
peek-a-boo with nearly 250 million people simultaneously."

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

From: [e-mail] (Jamie R. McCarthy)
Date: 4 Oct 92 23:52:31 GMT
Organization: Kalamazoo College

[e-mail] (Charles Reiman) writes:
>
>From memory, you must change
>both MTemp and RawMouse to the coordinate you want. That should do the
>trick. Note that this is dangerous, since a VBL could hit while you are
>changing the variables, and the jCrsrTask will proceed to move the
>pointer on its own to a strange new location.

Hmmmmm, interesting.  Have you tried setting the byte at CrsrBusy
(0x08CD) while you change the globals?  That might keep the system off
your back...?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I tried to sleep my way to the top
 But my alarm clock always woke me right up

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

From: [e-mail] (Jerome Chan)
Subject: CTB Questions and Answers
Date: 5 Oct 92 04:11:22 GMT
Organization: The Tofu Society of Singapore

I've had several questions about the Communications Tool Box and now I have
some muddled Answers.

1) How do I set the size of the Window Before Calling TMNew?
   Call TMNew with an invisible Window. Then call TMGetTermEnvirons,
calculate the actual size of the window from textRows,textCols,cellSize or
graphicSize, resize the window and make it visible. Do I have to worry
about changing the termRect, viewRect and visRect values?

2) Can anyone explain what a MyClickLoop is supposed to do?
   Someone replied that all it did was to return true if the click was in
the cached region. If I'm not implementing a cache reqion, I can put a 0L
for the myClickProc parameter in TMNew? I don't have to worry about
highlighting and such?

- ---
 The Evil Tofu

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

From: [e-mail] (Brian Hall)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Mon, 5 Oct 1992 06:48:46 GMT

In article <[e-mail]> [e-mail] (Jerome Chan) writes:
>2) Can anyone explain what a MyClickLoop is supposed to do?
>   Someone replied that all it did was to return true if the click was in
>the cached region. If I'm not implementing a cache reqion, I can put a 0L
>for the myClickProc parameter in TMNew? I don't have to worry about
>highlighting and such?

That is partially true.  The clickloop returns a boolean, which should
be TRUE if the click was in the terminal region.  If you are not going to
do a cache region, you don't even need to do a ClickProc - the idea of
the proc is for you to handle auto-scroll, hilighting, selection, and
all that fun stuff in the cache region.


- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | The tornado ate my powerbook.

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

From: [e-mail] (Jason Andrew Barshay)
Subject: CASE tools
Date: 30 Sep 92 05:24:14 GMT
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA


I am interested in finding any information on CASE tools for the
Macintosh.  If you know of any products, have experience with them, have
the address of vendors, or anything else, I would appreciate the
information you could give me.  Please send your repsonses (or at least
CC) them to this account.

Thanks,
Jason

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

From: [e-mail] (Norman Franke, III)
Date: 30 Sep 92 18:14:38 GMT
Organization: Lawrence Livermore National Laboratory

In article <[e-mail]> Jason Andrew Barshay,
[e-mail] writes:
>I am interested in finding any information on CASE tools for the
>Macintosh.  If you know of any products, have experience with them, have
>the address of vendors, or anything else, I would appreciate the
>information you could give me.  Please send your repsonses (or at least
>CC) them to this account.

I posted a similar question here are the responses I got:

But first, we "selected" TurboCASE from Struct Soft, Inc.

206-644-9834

However, TurboCASE is probably the worst piece of software I have ever
seen for the Mac. It has numerous bugs, and the WORST interface known
to MacMan. But, it's also the least expensive. Also, the manual is
worthless and seems to be written for a different version of the
software.

(The US Number for DEFT, is 617-238-6100, and I spoke with John Baron for
an evaluation copy.)

= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Date: Tue, 15 Sep 92 11:12:56 PDT
From: [e-mail] (Bob Hoyt)
Subject: RE: CASE Software
To: [e-mail]
Organization: Quotron Systems, Inc.

You ought to at least look at Deft, a CASE tool which we have had here at
Quotron Systems for a couple of years.  It does Data Flow Diagrams, Entity
Relationship Diagrams, Program Structure Diagram, and from these will
create
forms and/or reports.  It keeps a data base of everything that you enter,
so even misspellings can be caught.

When we first considered it, they had a free demo which showed off most of
their features.  For that, or more specific information, you can contact
them at:

    DEFT            (Home Office)
    Suite 111, 557 Dixon Rd.
    Toronto (Rexdale), Ontario
    M9W 1H7, Canada
    Sales:    [phone]
    FAX:    [phone]

(They have a West Coast office, but I believe that my address for that is
out of date.  Let me know if you need me to look it up.

As usual, it's disclaimer time.  These statements represent my opinion
only,
not that of Quotron Systems, Inc., its management, etc., etc.

Good luck,

Bob Hoyt
- --
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
Email address:    [e-mail]    |  The first to plead his case seems
just,
                    |  until another comes and examines him.
Phone Number:    [phone]        |  Prov. 18:17
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++

= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Date: Tue, 15 Sep 92 12:26:10 MST
From: [e-mail] (Duke Beattie)
Subject: RE: CASE Software
To: [e-mail]
Organization: Motorola ASIC

You might try contacting Excel Software at:
                             PO Box 1414
                             Marshalltown, Iowa 50158
                             [phone]
They have pretty good Analysis and Design programs.

Duke

= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Date: Sat, 19 Sep 92 14:37:01 -0500
From: [e-mail] (Anthony Rich)
Subject: RE: CASE Software
To: [e-mail]
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

Hi, Norman.  You write:

I'm teaching a SE class here at UW-Eau Claire this semester.  In the
Instructor's Guide to the textbook "Software Engineering with Student
Project Guidance" by Barbee Teasley Mynatt (Prentice-Hall) is a list of
available CASE tools for lots of platforms.  The book is copyright 1990,
so
this info may be out of date.  No platform is specified for some of the
software listed; here are the ones that it says will run on the Mac.
I haven't used any of them.

  -- Tony



Design/2.0
Meta Software Corp.
150 Cambridge Park Drive
Cambridge, MA 02140
[phone]
[phone]

A drawing package that facilitates the manipulation of text and
graphics components.  System designs, org charts, flowcharts,
and presentation graphics can be created.  Allows the user
connect objects; connected objects are automatically rebuilt
when a diagram is edited.


MacBubbles
StarSys, Inc.
11113 Norles Drive
Silver Spring, MD 20902
[phone]

A dataflow diagram editor for the Mac.


Powertools (formerly Prism)
Iconix Software Engineering
1037 Third Street
Suite 105
Santa Monica, CA 90403
[phone]

A variety of tools, including Free-Flow (a dataflow diagram editor
with mini-specifications), FastTask (for real-time software development),
PowerPDL (a pseudocode processor that generates formatted documentation),
and SmartChart (a structure chart generator).

= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -

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

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

From: [e-mail] (Jason Andrew Barshay)
Date: 4 Oct 92 16:29:27 GMT
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA


I am interested in finding any information on CASE tools for the
Macintosh.  If you know of any products, have experience with them, have
the address of vendors, or anything else, I would appreciate the
information you could give me.  Please send your repsonses (or at least
CC) them to this account.

Thanks,
Jason

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

From: [e-mail] (KRILLE_KROKODIL)
Subject: Changing 'STR#'s
Organization: KTH, Royal Institute of Technology, School of Electrical Engineering
Date: Thu, 1 Oct 1992 01:01:10 GMT

How do I change the contents of STR  and STR# recources from Think Pascal?

Martin

- -------------------------------------------------------------------------------
                                    If you have a living frog for breakfast,
                                    nothing worse can happen during the day.

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

From: [e-mail] (David J. Harr)
Organization: The programmers who say NEE!
Date: Sun, 4 Oct 1992 15:58:20 GMT

In article <[e-mail]> [e-mail] (KRILLE_KROKODIL) writes:
>How do I change the contents of STR  and STR# recources from Think Pascal?
>
>Martin
>
>-------------------------------------------------------------------------------
>                                    If you have a living frog for breakfast,
>                                    nothing worse can happen during the day.

Here's a routine I use for changing the contents of a STR# resource on the
fly. Caveats: I quickly adapted it from another routine that does almost the
same thing but is a bit more specialized, so it may have a bug or two due to
the quick dismemberment/reassembly from the old routine, and it will allocate
a temporary handle the size of the new STR# resource, so if you have a very
large STR# resource you are trying to change and you are short on space, it
will fail without returniing any warning (because it is a void function).
It is not in Pascal, but it should be fairly simple to translate.
Here is the code:

void write_str(short index, short res_id, Str255 new_str)
{
    Handle str_handle, temp_handle;
    short res_id, num_strings, i;
    long lead_bytes, end_bytes, hand_size, new_hand_size;

    str_handle = Get1Resource('STR#', res_id);
    if(!str_handle)
        return;
    hand_size = GetHandleSize(str_handle);
    if(MemError())
        return;
    num_strings = **((short**)str_handle);
    lead_bytes = 2;        /* skip over number of strings in STR# resource */
    for(i = 1; i < index; i++)
    {
        lead_bytes += (*((unsigned char**)str_handle))[lead_bytes] + 1;
    }
    if(index != num_strings)
        end_bytes = lead_bytes + (*((unsigned char**)str_handle))[lead_bytes] + 1;
    else
        end_bytes = 0;
    new_hand_size = lead_bytes;
    new_hand_size += (unsigned char)new_str[0] + 1;
    if(end_bytes)
        new_hand_size += hand_size - end_bytes;
    temp_handle = NewHandle(new_hand_size);
    if(!temp_handle)
        return;        /* NewHandle failed */
    HLock(str_handle);
    HLock(temp_handle);
    memcpy(*temp_handle, *str_handle, lead_bytes);
    memcpy(*temp_handle + lead_bytes, new_str, new_str[0] + 1);
    if(end_bytes)
        memcpy(*temp_handle + lead_bytes + new_str[0] + 1,
                    *str_handle + end_bytes, hand_size - end_bytes);
    HUnlock(temp_handle);
    HUnlock(str_handle);
    SetHandleSize(str_handle, new_hand_size);
    HLock(str_handle);
    HLock(temp_handle);
    memcpy(*str_handle, *temp_handle, new_hand_size);
    HUnlock(temp_handle);
    HUnlock(str_handle);
    DisposeHandle(temp_handle);
    ChangedResource(str_handle);
    if(ResError())
        return;
    WriteResource(str_handle);
}



Hope this is of some interest to the folks on the net!

David.

"Your excellency, the workers of Freedonia are demanding shorter hours!"
"We'll give them shorter hours. Cut their lunch hour to twenty minutes."

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

From: [e-mail] (Daryl Biberdorf)
Subject: Vendors for Mac assemblers?  Which are decent?
Organization: Texas A&M University, College Station
Date: Sat, 3 Oct 1992 06:04:39 GMT

In the near future (right now!), I'll be doing a lot more 68k development
work in assembly, not all of it for my Mac.  As a result of this, I'd
like to get a 68k assembler for my PowerBook 100.

So far I haven't been able to find many assemblers, and the ones I've
found I've heard nothing about.

Can anyone tell me what vendors offer assemblers for the Mac as well
as approximate prices and whether the product is any good?  I'd
really like to be able to single-step through the code and set breakpoints,
if these are not common features.

Thanks in advance for any advice.

Daryl


- --
Daryl Biberdorf  N5GJM    [e-mail] or  [e-mail]


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

From: [e-mail] (David Snearline)
Date: Sat, 03 Oct 92 06:51:16 EDT
Organization: University of Michigan Engineering, Ann Arbor

In article <[e-mail]> [e-mail] (Daryl Biberdorf) writes:
>In the near future (right now!), I'll be doing a lot more 68k development
>work in assembly, not all of it for my Mac.  As a result of this, I'd
>like to get a 68k assembler for my PowerBook 100.
>
>So far I haven't been able to find many assemblers, and the ones I've
>found I've heard nothing about.
>
>Can anyone tell me what vendors offer assemblers for the Mac as well
>as approximate prices and whether the product is any good?  I'd
>really like to be able to single-step through the code and set breakpoints,
>if these are not common features.
>
>Thanks in advance for any advice.

For serious work with 68k assembler on the Mac, I would recommend Apple's
MPW assembler.  As is the usual recommendation for MPW, disk space and
memory are a must, although it is possible to strip MPW down to 2 megs
or so if you are only using the assembler.  In conjunction with MacsBug,
this should be everything you need.

For occasional assembler coding, the THINK C inline assembler is decent
if you don't need macro capabilities.  I like using the inline assembler
for routines within a larger THINK C or Pascal project.

- --
David Snearline            CAEN Networking and Operations
[e-mail]        University of Michigan Engineering

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

From: [e-mail] (Glen Stewart)
Date: 6 Oct 92 01:18:11 GMT
Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI

How about this one?

Programming - #13, 139 files
============================

mcassembly 7.6.cpt  :   495k+:by Dave McWherter - an assembler, rsrc compiler,
                        linker, and job controller for the Macintosh. Includes
                        "local symbols", macros, source print formatting.
                        McAssembly also contains a built-in Resource Compiler
                        which can assemble resource definitions. Simple docs,
                        more upon registration. $50 ShareWare.


You can call this BBS at 313-695-6744 (HST) or 313-695-6955 (v.32bis)
Downloads available on first call.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Glen Stewart - Internet: [e-mail]

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

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