From: owner-csmp@ee.mcgill.ca
Subject: csmp digest Vol 4 No 043
C.S.M.P. Digest Mon, 03 Nov 97 Volume 4 : Issue 43
Today's Topics:
"Composite" AppleEvents
"Unselecting" a editText item?
Advice needed
Any problem with long GWorlds?
Audio CD control?
Drag 'n drop start up (ie aete resource)
Drawing Directly To The Screen
Event Filter Trap Description and Parameters
Graying out an edit field
Growing resources
Help: Getting and Displaying keys
How do I control the CD-ROM?
How to Assert Serial Port Pins
How to patch traps under PPC
How to set the desktop pattern?
Installing system-wide AE handler from app?
MDEF's - Code-based Installation
PowerPC-CFM Question
Problems with stereo sound positioning
Progress Bar in OS8 and 7.5
Q: CM plug-in example code
Q: How to use AppearanceLib with 68K app?
RegisterAppearanceClient questions (Appearance manager)
ResEdit 'hdlg' resource editor?
Serial port help
Speeding up concave polygon drawing...
VBL programming
Window Size
[Q] Drawing regions really quickly.
[Q] How to Hide Applications Programmatically
[Q] Modem or Printer Port ?
communicating with internal PB modem
copying from serial port
custom boot disk-micro OS?
network PBRead slow in OS8
The Comp.Sys.Mac.Programmer Digest is moderated by Mark Aiken
(marka@ee.mcgill.ca).
The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions. If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail help@anon.penet.fi for more information).
Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject. The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
ee.mcgill.ca). Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest). Article threads that
consist of only one message are generally not included in the digest.
The digests can be obtained by email, ftp or through the World Wide Web.
If you want to receive the digest by mail, send email to
majordomo@ee.mcgill.ca with no subject and one of the following commands
as body:
help Sends you a summary of commands
subscribe csmp Adds you to the mailing list
unsubscribe csmp Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.
Back issues are available by ftp from Info-Mac mirror sites in the
per/csmp subdirectory, e.g.
ftp://sumex-aim.stanford.edu/info-mac/per/csmp/
The contents of all back issues can be searched by accessing the
following URL, courtesy of Andrew Barry (ajbarry@ozemail.com.au):
http://marvin.stattech.com.au/search.html
They can also be searched through the following URLs, thanks to
Tim Tuck (Tim.Tuck@sensei.com.au):
http://wais.sensei.com.au/searchform.html
wais://wais.sensei.com.au:210/csmp?
-------------------------------------------------------
>From i'm@not.here (Jeff Clites)
Subject: "Composite" AppleEvents
Date: Fri, 10 Oct 1997 02:36:56 -0700
Organization: California Institute of Technology, Pasadena
I'm sending several AppleEvents to the same target application, and I was
wondering if there was a way to send them "all at once" since they are
going to the same target. Well, that sounded stupid, so let me phrase it
differently:
I'm sending a bunch of AEs to the Finder, but under OS 8 it has gone a bit
over the edge with multithreading, and for every event the Finder receives
a new thread is spawned to handle it, making things as slow as molasses
(when you dump a bunch of events at it). So, I'm trying to finagle a way
to get my AEs to go into a single thread, so what I'm hankering for is a
way to package several events together (if that even makes sense).
Any suggestions, or alternatives? Thanks.
- ------------------------------------------------------------------------
Jeff Clites Pasadena, California
My account name is jac and the rest of my address has igor and caltech and
edu, separated by dots. Don't spam me or anybody else (please).
+++++++++++++++++++++++++++
>From uzs90z@ibm.rhrz.uni-bonn.de (Michael Schuerig)
Date: Fri, 10 Oct 1997 15:14:53 +0200
Organization: Completely Disorganized
Jeff Clites <i'm@not.here> wrote:
> I'm sending a bunch of AEs to the Finder, but under OS 8 it has gone a bit
> over the edge with multithreading, and for every event the Finder receives
> a new thread is spawned to handle it, making things as slow as molasses
> (when you dump a bunch of events at it). So, I'm trying to finagle a way
> to get my AEs to go into a single thread, so what I'm hankering for is a
> way to package several events together (if that even makes sense).
You're out of luck. Your best hope is to convince Apple that this
behavior on the Finder's part is brain-dead. It ought to service AEs
that come from one client app in one single thread.
I suggested this to Apple quite some time ago. No reaction so far.
Michael
--
Michael Schuerig Most people would rather die than think.
mailto:uzs90z@uni-bonn.de In fact, they do.
http://www.uni-bonn.de/~uzs90z/ -Bertrand Russell
---------------------------
>From Bill.Eccles@noSpam.net (Bill Eccles)
Subject: "Unselecting" a editText item?
Date: Tue, 07 Oct 1997 08:30:40 -0500
Organization: Cable and Wireless, Inc.
Gentleones:
Is there a simple way to use the Dialog Manager to cause the text edit
caret to not be in any editText item in a modeless dialog box?
The scenario: The user clicks on editText item 1, enters her name,
presses tab, goes to editText item 2, enters the other player's name, and
hits return. I'd like the cursor to disappear from all edit text items
upon detection of this return, but I've not found a way to used SelIText
to cause the cursor to "disappear."
Thanks again,
Bill
--
Bill Eccles
Replace the "noSpam" with "USA"
+++++++++++++++++++++++++++
>From dstone@BIT.chem.utoronto.ca (David Stone)
Date: 7 Oct 1997 15:25:11 GMT
Organization: University of Toronto Chemistry
In article <Bill.Eccles-0710970830400001@143.139.33.123>,
Bill.Eccles@noSpam.net (Bill Eccles) wrote:
>
> Gentleones:
>
> Is there a simple way to use the Dialog Manager to cause the text edit
> caret to not be in any editText item in a modeless dialog box?
This is a "feature" of the dialog manager. The IsDialogEvt/DialogSelect
duo (and ModalDialog) contain code that forces at least one of the
edit text items in the dialog to be active at all times. The only
way I have found around this is to double each edit text with a static
text, and make one of each pair invisible (HideDItem (?)). Then you
have to write code to switch the text between the edit and static versions,
hiding and showing as you go. This is messy, plus the modeless dialog
requirements tend to complicate the main event loop somewhat.
A better method is to implement your modeless dialog as a window, and
handle the activate/update events in the normal manner. Although you
have to add the code to make sure the window draws correctly when needed,
overall it greatly simplifies things and the edit text items can be made
to behave the way you want them to.
David Stone
(remove the obvious bit to reply...)
+++++++++++++++++++++++++++
>From ronm@teleport.com (Ron W. Miller)
Date: 8 Oct 1997 18:21:12 GMT
Organization: Twilight Zone Software
In article <dstone-071097111807@csgmac.chem.utoronto.ca>,
dstone@BIT.chem.utoronto.ca (David Stone) wrote:
> In article <Bill.Eccles-0710970830400001@143.139.33.123>,
> Bill.Eccles@noSpam.net (Bill Eccles) wrote:
> >
> > Gentleones:
> >
> > Is there a simple way to use the Dialog Manager to cause the text edit
> > caret to not be in any editText item in a modeless dialog box?
>
> This is a "feature" of the dialog manager. The IsDialogEvt/DialogSelect
> duo (and ModalDialog) contain code that forces at least one of the
> edit text items in the dialog to be active at all times. The only
> way I have found around this is to double each edit text with a static
> text, and make one of each pair invisible (HideDItem (?)). Then you
> have to write code to switch the text between the edit and static versions,
> hiding and showing as you go. This is messy, plus the modeless dialog
> requirements tend to complicate the main event loop somewhat.
>
> A better method is to implement your modeless dialog as a window, and
> handle the activate/update events in the normal manner. Although you
> have to add the code to make sure the window draws correctly when needed,
> overall it greatly simplifies things and the edit text items can be made
> to behave the way you want them to.
>
>
> David Stone
> (remove the obvious bit to reply...)
David,
It is not necessary to go to the extra trouble of extra edit text items.
You can invoke the same behavior by changing the DialogRecord's editField
member to an invalid number. I have done this in the past to make a
textEdit appear disabled( a little more work is involved ). I also
believe that a DTS example application uses this very technique. I can
probably find it if needed.
Sincerely,
Ron W. Miller
--
===============================
Ron W. Miller
Twilight Zone Software
ronm@teleport.com
Contract Software Developer
Macintosh and Microsoft Windows
===============================
---------------------------
>From BHuey@nospam.att.net (Hugh Johnson)
Subject: Advice needed
Date: Sat, 18 Oct 1997 00:07:37 -0600
Organization: Semplice
I got an email from a Japanese magazine wanting to distribute my shareware
on their CD ROM. Okay, that's fine with me. But they also ask for my
permission to distribute it again in the future as many times as they want
without bugging me about it. Is that wise? Should I say okay to a
something like that, or is it liable to jump up and bite me in the future?
--
Hugh Johnson
Replace "nospam" with "worldnet"
+++++++++++++++++++++++++++
>From ALX@ravenware.com (Alex Kinnison)
Date: Sat, 18 Oct 1997 14:12:05 -0700
Organization: Ravenware Software
In article <629g4e$qkc@bgtnsc02.worldnet.att.net>, BHuey@nospam.att.net
(Hugh Johnson) wrote:
> I got an email from a Japanese magazine wanting to distribute my shareware
> on their CD ROM. Okay, that's fine with me. But they also ask for my
> permission to distribute it again in the future as many times as they want
> without bugging me about it. Is that wise? Should I say okay to a
> something like that, or is it liable to jump up and bite me in the future?
Hugh,
The only problem that might pop up is if you later wish to turn your
program into a commercial product.
Ravenware does this all the time (our games are all freeware, kinda like
distributed advertizing) and continual distribution is OK.
If you do get a chance to go commercial, it will generally happen one of
two ways;
1) A game house will ask you to distribute
2) You decide to distribute
In the first case, we always get a "non-exclusive" clause in the
publishing agreement. That means that the game house can sell our stuff,
and we can continue to freeware it. Never had a problem with this, most
game houses aim their products at folks who are not hooked up to a service
(still a whole lot of folks).
In the second case, just change your shareware somewhat. Add a few new
features, call it "XXXX Pro" or "XXXX Plus" and you'll have a new product
and won't be competing (strictly) with the shareware version, and you also
have a "sell-up" for folks who really like your shareware version. Look
how well some commercial software does with this, Eudora is a great
example. Eudora light is free, Eudora Pro costs.
I wouldn't worry about it. As long as you retain copyright (which you do
unless you *specifically* let someone else have the rights (which you
generally shouldn't)) then you still own the game, even if they are
distributing it.
Alex Kinnison ALX@Ravenware.com
Terrorist Technical Writing
+++++++++++++++++++++++++++
>From Ian Russell Ollmann <iano@wong.scripps.edu>
Date: Sat, 18 Oct 1997 13:41:44 -0700
Organization: The Scripps Research Institute, La Jolla, CA
On Sat, 18 Oct 1997, Hugh Johnson wrote:
> I got an email from a Japanese magazine wanting to distribute my shareware
> on their CD ROM. Okay, that's fine with me. But they also ask for my
> permission to distribute it again in the future as many times as they want
> without bugging me about it. Is that wise? Should I say okay to a
> something like that, or is it liable to jump up and bite me in the future?
If you plan to update your software, and want them to ask for the new
version before sending out the old one and all of the support headache
that that entails, then it would be wise to say no to the future
distribution without asking. It is not like you are setting yourself
up for added trouble by asking them to ask again. After all, how hard is
it for you to send them an updated copy of your software? Not very.
Ian Ollmann
---------------------------
>From "Seth Hill" <ferris@proaxis.com>
Subject: Any problem with long GWorlds?
Date: 10 Oct 97 13:34:14 -0700
Organization: All USENET -- http://www.Supernews.com
I was wondering if there was a performance hit to using really long
GWorlds, say 2048x32 or bigger, as compared with using a more rectangular
GWorld. The memory requirements are going to be 64K whether it's long or
rectangular, but (I'm holding a bunch of 32x32 sprites offscreen..)
It would be much easier to deal with a long GWorld as opposed to the
rectangular one... Any weird consequences of doing stuff like this?
_____________________________________________________________________
Seth Hill | ferris@proaxis.com
Troposphere Software | http://www.proaxis.com/~ferris/software/
"What are we going to do tomorrow night, Brain?"
"The same thing we do every night, Pinky - Try to take over the world!
+++++++++++++++++++++++++++
>From erkyrath@netcom.com (Andrew Plotkin)
Date: Sat, 11 Oct 1997 20:19:44 GMT
Organization: Netcom On-Line Services
Seth Hill (ferris@proaxis.com) wrote:
> I was wondering if there was a performance hit to using really long
> GWorlds, say 2048x32 or bigger, as compared with using a more rectangular
> GWorld. The memory requirements are going to be 64K whether it's long or
> rectangular, but (I'm holding a bunch of 32x32 sprites offscreen..)
> It would be much easier to deal with a long GWorld as opposed to the
> rectangular one... Any weird consequences of doing stuff like this?
There's some padding that can occur on each line, so a *narrow* GWorld
(32 wide by 2048 high) might waste a lot of space. But a 2048x32 should
be ok.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
+++++++++++++++++++++++++++
>From masong7@aol.com (MasonG7)
Date: 12 Oct 1997 21:50:17 GMT
Organization: AOL http://www.aol.com
************
Seth Hill (ferris@proaxis.com) wrote:
> I was wondering if there was a performance hit to using really long
> GWorlds, say 2048x32 or bigger, as compared with using a more rectangular
> GWorld. The memory requirements are going to be 64K whether it's long or
> rectangular, but (I'm holding a bunch of 32x32 sprites offscreen..)
> It would be much easier to deal with a long GWorld as opposed to the
> rectangular one... Any weird consequences of doing stuff like this?
There's some padding that can occur on each line, so a *narrow* GWorld
(32 wide by 2048 high) might waste a lot of space. But a 2048x32 should
be ok.
************
Also of note is the fact that copying a wide GWorld is a bit faster than
copying a tall one because of the row calculations that must be performed. Ex:
a copy of a 32x2048 GWorld will spend a good portion of it's time calculating
the next row, while a copy of a 2048x32 GWorld will spend almost all of it's
time copying.
MasonG7@aol dot com
Mason Gup
+++++++++++++++++++++++++++
>From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
Date: Tue, 14 Oct 1997 22:32:17 +1300
Organization: (none)
Seth Hill <ferris@proaxis.com> writes:
> I was wondering if there was a performance hit to using really long
> GWorlds, say 2048x32 or bigger, as compared with using a more rectangular
> GWorld. The memory requirements are going to be 64K whether it's long or
> rectangular, but (I'm holding a bunch of 32x32 sprites offscreen..)
>
> It would be much easier to deal with a long GWorld as opposed to the
> rectangular one... Any weird consequences of doing stuff like this?
What I'd recommend, all else being equal, is to use a GWorld that is
32 pixels wide by 2048 pixels high, rather than the other way around.
This will store each icon will in a continuous region of memory,
rather than smeared out all over the place.
The advantages:
- each icon will be on a single 4K page of memory, saving on virtual
memory swapping (maybe), but certainly saving on the number of TLB
reloads.
- each cache line within a single icon (which at 8 bits per pixel will
be a scan line in the icon) will map to a different set in the cache.
This means that if you're heavily using a particular icon (or a small
number), it will stay entirely in L1 cache, speeding the program.
With a 2048x32 organisation, every scan line of an icon would map to
the same cache set. There are only a small number of cache lines in
each set (eight in PPC601 and PPC750, four in PPC604e, PPC604 and PPC603e,
two in PPC603), so you'd only be able to keep two, four or eight scan lines
from a given icon in L1 cache at the same time. This isn't good.
- if you're using fewer than 8 bits per pixel then you'll get several scan
lines from the same icon into each cache line. With a 2048x32 organisation
you'd need to move 32 cache lines to copy an icon, but a lot of that
space would be wasted.
Hope this helps. Of course, this is for PowerPC. The same issues arise with
the 68K, though the actual numbers are different.
-- Bruce
--
'We have no intention of shipping another bloated operating system and
forcing that down the throats of our Windows customers'
-- Paul Maritz, Microsoft Group Vice President
+++++++++++++++++++++++++++
>From "Seth Hill" <ferris@proaxis.com>
Date: 15 Oct 97 14:56:36 -0700
Organization: All USENET -- http://www.Supernews.com
On Tue, Oct 14, 1997 2:32 AM, Bruce Hoult
<mailto:Bruce@hoult.actrix.gen.nz> wrote:
>What I'd recommend, all else being equal, is to use a GWorld that is
>32 pixels wide by 2048 pixels high, rather than the other way around.
>This will store each icon will in a continuous region of memory,
>rather than smeared out all over the place.
>
>The advantages:
>
>- each icon will be on a single 4K page of memory, saving on virtual
> memory swapping (maybe), but certainly saving on the number of TLB
> reloads.
>
>- each cache line within a single icon (which at 8 bits per pixel will
> be a scan line in the icon) will map to a different set in the cache.
> This means that if you're heavily using a particular icon (or a small
> number), it will stay entirely in L1 cache, speeding the program.
>
> With a 2048x32 organisation, every scan line of an icon would map to
> the same cache set. There are only a small number of cache lines in
> each set (eight in PPC601 and PPC750, four in PPC604e, PPC604 and
PPC603e,
> two in PPC603), so you'd only be able to keep two, four or eight scan
lines
> from a given icon in L1 cache at the same time. This isn't good.
>
>- if you're using fewer than 8 bits per pixel then you'll get several scan
> lines from the same icon into each cache line. With a 2048x32
organisation
> you'd need to move 32 cache lines to copy an icon, but a lot of that
> space would be wasted.
>
>
>Hope this helps. Of course, this is for PowerPC. The same issues arise
with
>the 68K, though the actual numbers are different.
>
>-- Bruce
>
Really! Do you suppose that tacking advantage of the cache like this would
be faster than a long gworld despite the extra address calculations? I
think I'll write a test program to tell me.
_____________________________________________________________________
Seth Hill | ferris@proaxis.com
Troposphere Software | http://www.proaxis.com/~ferris/software/
"What are we going to do tomorrow night, Brain?"
"The same thing we do every night, Pinky - Try to take over the world!
+++++++++++++++++++++++++++
>From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
Date: Sun, 19 Oct 1997 15:41:41 +1300
Organization: (none)
Seth Hill <ferris@proaxis.com> writes:
> On Tue, Oct 14, 1997 2:32 AM, Bruce Hoult
> <mailto:Bruce@hoult.actrix.gen.nz> wrote:
> >What I'd recommend, all else being equal, is to use a GWorld that is
> >32 pixels wide by 2048 pixels high, rather than the other way around.
> >This will store each icon in a continuous region of memory,
> >rather than smeared out all over the place.
>
> Really! Do you suppose that tacking advantage of the cache like this would
> be faster than a long gworld despite the extra address calculations? I
> think I'll write a test program to tell me.
Yes, I think so, for copying icons at random out of the GWorld. Not for copying
the whole GWorld -- but then that's not what you're doing.
-- Bruce
--
'We have no intention of shipping another bloated operating system and
forcing that down the throats of our Windows customers'
-- Paul Maritz, Microsoft Group Vice President
---------------------------
>From nul@bitbucket.com (Greg Parker)
Subject: Audio CD control?
Date: Sat, 11 Oct 1997 18:51:06 -0700
Organization: Hamster Emporium
I'm looking for information about controlling Audio CD's. On Apple's site
I found cd.c and cd.h, which appear to do what I need but they are really
old. Also, they don't work. When I run them (or sample programs using
them) I get -21 errors everywhere. I also found the CD Toolkit HyperCard
stack, which does work, but the code is in XCMD form, which I don't
understand. They are also old and unsupported. Is there any up-to-date CD
control code or information?
I also noticed that Apple's CD Player and the CD Toolkit stack don't quite
work on a PowerCenter Pro - repeat mode doesn't work and changing tracks
while the CD is stopped sometimes doesn't work properly. Is this a PowerCC
problem, or does newer code fix this? I have FWB's CD player, but it
doesn't run programs.
(And this all started because I wanted to automate part of my .sig :-)
-- Greg Parker parker42@stanford.edu
"When in danger, when in doubt, run in circles, scream and shout."
-- J. MacDonald
Current music: "Piano Concerto in A minor, 2nd movement: Adagio", Grieg
+++++++++++++++++++++++++++
>From tyen@earthling.net (Tee Yen)
Date: Thu, 16 Oct 1997 23:42:59 +0800
Organization: YenCo.
In article <nul-1110971851060001@euc-97-129a.stanford.edu>,
nul@bitbucket.com (Greg Parker) wrote:
>I'm looking for information about controlling Audio CD's. On Apple's site
Try looking at the inCDius source that can be found at an info-mac mirror
(in /dev/src/ i think). Also check out the technote on devices #22 (search
the apple site for dv_22.pdf if u cant find it), this contains the calls
you can make to the apple (dunno bout others) CD drivers.
Hope this helps,
yen
- -
tyen@earthling.net
http://tyen.home.ml.org/
---------------------------
>From jk0101@medtronic.com (John W. Komp)
Subject: Drag 'n drop start up (ie aete resource)
Date: 13 Oct 1997 13:41:15 GMT
Organization: Medtronic, Inc.
I'm trying to create an app that will startup when some files
are dropped on it. Following DropShell and David Mark's books
I've added the handlers for the required AE hooks (openDoc,
openApp, printDoc, quitApp) and set the flags in size but I
still can't seem to get things going.
One thing I did notice is that programs like DropShell have
the resources aete and aeue which are covered by chapters
7 and 8 of IM's interapplication communications book.
Is a drag and drop of a file or folder onto an application icon
considered an AE event? If so does CodeWarrior create aete
resources or am I on my own for those (I'm using CW7)? Am I
looking in the wrong place for this documentation (ie maybe
its not an AE event)?
Thanks,
-John
--
****************************************************
This morning I shot six holes in my freezer
I think I've got cabin fever
Somebody sound the alarm
- J. Buffett
****************************************************
+++++++++++++++++++++++++++
>From DavidO@dascorp.com (David Phillip Oster)
Date: Mon, 13 Oct 1997 09:07:49 -0700
Organization: Digital Arts & Sciences Corp.
In article <61t8dr$6ma$2@gazette.corp.medtronic.com>, jk0101@medtronic.com (John W. Komp) wrote:
>I'm trying to create an app that will startup when some files
>are dropped on it. Following DropShell and David Mark's books
>I've added the handlers for the required AE hooks (openDoc,
>openApp, printDoc, quitApp) and set the flags in size but I
>still can't seem to get things going.
Did you also create a correct BNDL resource with associated
FREF resources to let the Finder know what kind of files can
be dropped on your program? Did you also delete any old
copies of your application so that the Finder will re-read the
resources of your ap.
>One thing I did notice is that programs like DropShell have
>the resources aete and aeue which are covered by chapters
>7 and 8 of IM's interapplication communications book.
>Is a drag and drop of a file or folder onto an application icon
>considered an AE event?
Yes. But, it is a required event, that all applications are required
to implement.
>If so does CodeWarrior create aete
>resources or am I on my own for those (I'm using CW7)?
The aete resource is so your application will have a dictionary
that can be opened in Script Editor. (Try using Scrpt Editor to
open the dictionary of some applications like CodewarriorIDE or
Netscape) You don't need an aete for a program to receive and send
apple events, but it is helpful if you expect a person to
write applescripts to use your program.
--
-- Warning: posted from an unlocked cubicle: no guarantee its really me.
"A man hears what he wants to hear and misremembers the rest."
-- Paul Simon, ("The Boxer")
+++++++++++++++++++++++++++
>From drysdallSPAMFREE@waikato.ac.nz (Richard Drysdall)
Date: Wed, 15 Oct 1997 10:22:04 +1300
Organization: University of Waikato
In article <61t8dr$6ma$2@gazette.corp.medtronic.com>, jk0101@medtronic.com
(John W. Komp) wrote:
>I'm trying to create an app that will startup when some files
>are dropped on it. Following DropShell and David Mark's books
>I've added the handlers for the required AE hooks (openDoc,
>openApp, printDoc, quitApp) and set the flags in size but I
>still can't seem to get things going.
>
>One thing I did notice is that programs like DropShell have
>the resources aete and aeue which are covered by chapters
>7 and 8 of IM's interapplication communications book.
>
>Is a drag and drop of a file or folder onto an application icon
>considered an AE event? If so does CodeWarrior create aete
>resources or am I on my own for those (I'm using CW7)? Am I
>looking in the wrong place for this documentation (ie maybe
>its not an AE event)?
Hi.
You don't need an 'aete' resource to handle the four basic Apple Events.
AppleEvents are received as an event in the event loop of your
application.
Check to make sure that your event loop handles a kHightLevelEvent case, i.e.
switch (theEvent.what) {
/* etc */
case kHighLevelEvent:
HandleHighLevel (&theEvent);
break;
The HandleHighLevel procedure looks like this:
/*****************************************************************
* Procedure: HandleHighLevel
*
* Dispatches all high level events to the AppleEvent handler.
*****************************************************************/
void HandleHighLevel (EventRecord *AERecord)
{
AEProcessAppleEvent (AERecord);
}
There's a good article about implementing the four basic AppleEvents in
the Core Technologies section of the May & June 1995 issues of Byte
magazine.
--
Richard Drysdall, University of Waikato, New Zealand
* Please remove the upper case letters from my email address to reply. *
Information gathering organisations are hereby denied permission to use
any personal information pertaining to myself (including my email address)
in any form of commercial transaction.
Unsolicited email will be forwarded to the appropriate postmasters.
---------------------------
>From "Martin Pawloski" <metalink-corp@worldnet.att.net>
Subject: Drawing Directly To The Screen
Date: 5 Oct 1997 22:08:27 GMT
Organization: MetaLink Corp.
Hey everyone,
I am fairly new at Mac Graphics programming, and I have heard at one place
or another that one should not draw directly to the screen. What would be
the pros and cons of drawing directly to the screen? Where could I get
information about how to do this?
Thanks!
-Jason
+++++++++++++++++++++++++++
>From ufo@paston.co.uk (UFO)
Date: Wed, 08 Oct 1997 18:31:55 +0000
Organization: Paston Chase Internet
In article <61934r$j75@bgtnsc02.worldnet.att.net>, "Martin Pawloski"
<metalink-corp@worldnet.att.net> wrote:
> Hey everyone,
>
> I am fairly new at Mac Graphics programming, and I have heard at one place
> or another that one should not draw directly to the screen. What would be
> the pros and cons of drawing directly to the screen? Where could I get
> information about how to do this?
>
> Thanks!
>
> -Jason
There are very few cons to drawing direct to the screen, you really should
only do it when there is need for speed.
You should draw everything you need into an offscreen world(GWorld), then
once you're done just use CopyBits() to transfer the information from
memory to the screen.
If you need extra help e-mail me and I'll send you an online book about
it. Alternatively you could visit:
http://www.AmbrosiaSW.com/alt.sources.mac/macintosh-c/macintosh-c-mw.html
You can download this book in sections or you can download the whole thing
in one go, I recommend getting it all!
Hope it helps
UFO
ufo@paston.co.uk
+++++++++++++++++++++++++++
>From deelight@usa.net (Deelight)
Date: Wed, 8 Oct 1997 20:38:22 +0100
Organization: Hors sujet inc.
Martin Pawloski <metalink-corp@worldnet.att.net> wrote:
> I am fairly new at Mac Graphics programming, and I have heard at one place
> or another that one should not draw directly to the screen. What would be
> the pros and cons of drawing directly to the screen? Where could I get
> information about how to do this?
You can find information on direct screen drawing (and other demomaking
techniques) at:
<http://zerius.victoria.bc.ca/~anton/HowToCodeAKewlMacDemo.html>
Hope this helps.
--
He who has imagination without learning has wings but no feet.
________________________________________________________________________
Deelight (soon) http://www.chez.com/apfelsaft
+++++++++++++++++++++++++++
>From cuthbert@no.spam.leeds.ac.uk
Date: Wed, 8 Oct 1997 20:28:31 +0100 (BST)
Organization: University of Leeds
> You should draw everything you need into an offscreen world (GWorld),
> then once you're done just use CopyBits() to transfer the information
> from memory to the screen.
I am probably adding to my reputation for being being picky but...
1) The technique you describe is the correct and probably the fastest
one for PowerMacs, and,
2) It is not drawing directly to the screen, you don't know what
CopyBits() is doing, it could be using some fancy hardware accelerator
for you know (or care). This technique is also virtually future-proof,
and,
3) In fact it is just the opposite of drawing to the screen, a technique
in which you obtain the base address of the video RAM and set pixels
usually by writing 32 bit integers, and,
4) Apart from weird cases in which your screen is accessed over the SCSI
bus or something, speaking of transferring from memory to screen is
tautology because the screen is memory mapped on the Mac. (You
probably meant copying an image from an off-screen GWorld to video
RAM), and,
5) You can probably get a PP class to all of this for you.
My apologies if any I have offended.
Ben.
---------------------------
>From Yevgeny Binder <binders@earthlink.net>
Subject: Event Filter Trap Description and Parameters
Date: Thu, 16 Oct 1997 22:21:56 -0500
Organization: EarthLink Network, Inc.
I'm trying to write an extension to look into the keyDown event and log
every keystroke within a specific application. The problem is that I
don't have any clue about how the keyDown event is filtered and what
trap is executed when one is present. Can anyone please help me with
this and completely explain how the keyDown event is processed? Thanks
in advance.
+++++++++++++++++++++++++++
>From gurgle@iname.com (Pete Gontier)
Date: Sun, 19 Oct 1997 18:26:45 -0700
Organization: cellular
In article <3446D9C3.F3194243@earthlink.net>,
binders@earthlink.net wrote:
> I'm trying to write an extension to look into the keyDown event and log
> every keystroke within a specific application. The problem is that I
> don't have any clue about how the keyDown event is filtered and what
> trap is executed when one is present. Can anyone please help me with
> this and completely explain how the keyDown event is processed? Thanks
> in advance.
Typing in the whole story is probably beyond the scope of a Usenet post.
You'll want to look at the following web pages, though:
Everything you ever wanted to know about the birth, life, and death
of an EventRecord:
<http://www.devworld.apple.com/dev/techsupport/
insidemac/Toolbox/Toolbox-28.html>
How to filter events:
<http://www.devworld.apple.com/dev/technotes/tn/tn1060.html>
--
Pete Gontier, Integer Poet
<mailto:gurgle@iname.com>
<http://www.ccnet.com/~gurgle>
---------------------------
>From tbenner@aol.com (TBenner)
Subject: Graying out an edit field
Date: 7 Oct 1997 23:17:41 GMT
Organization: AOL http://www.aol.com
Hi
I would like to gray out an edit field in a dialog box, but am not sure how
to do this. Is there a code example of how to do this somewhere?
Tim Benner
tbenner@aol.com
+++++++++++++++++++++++++++
>From bradley@apple.com (Bob Bradley)
Date: Tue, 07 Oct 1997 21:56:22 -0700
Organization: Uh huh huh...It says Organ
In article <19971007231700.TAA27508@ladder02.news.aol.com>,
tbenner@aol.com (TBenner) wrote:
> I would like to gray out an edit field in a dialog box, but am not sure how
> to do this. Is there a code example of how to do this somewhere?
There's example code by James Walker called DimText that shows how to do
this. Another option, if your situation allows it, is to just hide the
edit text field.
+++++++++++++++++++++++++++
>From ronm@teleport.com (Ron W. Miller)
Date: 8 Oct 1997 18:29:32 GMT
Organization: Twilight Zone Software
In article <19971007231700.TAA27508@ladder02.news.aol.com>,
tbenner@aol.com (TBenner) wrote:
> Hi
>
> I would like to gray out an edit field in a dialog box, but am not sure how
> to do this. Is there a code example of how to do this somewhere?
>
> Tim Benner
> tbenner@aol.com
Tim,
There is a code example of how to do this, it can be found on about any
Apple Tool chest CD. The example is called DialogBits.
Ron W. Miller
--
===============================
Ron W. Miller
Twilight Zone Software
ronm@teleport.com
Contract Software Developer
Macintosh and Microsoft Windows
===============================
+++++++++++++++++++++++++++
>From nospam@nospam.kenner.demon.co.uk (Chris Orgill)
Date: Sat, 11 Oct 1997 00:40:54 +0100
Organization: (none)
In article <19971007231700.TAA27508@ladder02.news.aol.com>, tbenner@aol.com
(TBenner) wrote:
> Hi
>
> I would like to gray out an edit field in a dialog box, but am not sure how
> to do this. Is there a code example of how to do this somewhere?
>
> Tim Benner
> tbenner@aol.com
If you believe that Apple will keep its promise and produce the Appearance
extension for MacOS 7.x, making it practical to deliver a MacOS 7.x
compatible app with the same GUI as a MacOS 8 app without jumping through a
large
number of hoops or spending way too much money, then Appearance adoption
will give you the nicest 'gray out' . Get the SDK on the Apple developer
web site
and read the docs.
Best,
Chris Orgill
+++++++++++++++++++++++++++
>From WaterEdgSW@A-O-L.COM (Steve Makohin)
Date: Fri, 10 Oct 1997 20:58:49 -0500
Organization: Water's Edge Software
In article <19971007231700.TAA27508@ladder02.news.aol.com>,
tbenner@aol.com (TBenner) wrote:
> I would like to gray out an edit field in a dialog box, but am not sure how
> to do this. Is there a code example of how to do this somewhere?
Another alternative is to download our Tools Plus libraries from our web
site. You can disable a field with one line of code. You can also do
thousands of other things with one line of code too!
-Steve Makohin | Remove dashes from email
Water's Edge Software | address before replying.
(Makers of Tools Plus and SuperCDEFs) | (Spam is getting bad)
http://www.interlog.com/~wateredg |
---------------------------
>From tyen@earthling.net (Tee Yen)
Subject: Growing resources
Date: Tue, 07 Oct 1997 16:38:08 +0800
Organization: YenCo.
Hi,
This probably really basic, but i jsut can't figure it, if i get a handle
to a resource with a call to GetResource, and then want to increase the
amount of data it holds, how would i do that?
I've tried SetHandleSize, but then when i write the handle with
WriteResource it doesnt show up in the file. I also tried SetResourceSize,
but that ended up with major hangs.
Any ideas?
Thanx in advance,
yen
- -
tyen@earthling.net
http://tyen.home.ml.org/
+++++++++++++++++++++++++++
>From slur@world.std.com (Scott Lahteine)
Date: Sat, 11 Oct 1997 17:46:23 GMT
Organization: Pylon Transit Authority
In article <tyen-0710971638090001@192.168.1.50>, tyen@earthling.net wrote:
>Hi,
>
>This probably really basic, but i jsut can't figure it, if i get a handle
>to a resource with a call to GetResource, and then want to increase the
>amount of data it holds, how would i do that?
>
>I've tried SetHandleSize, but then when i write the handle with
>WriteResource it doesnt show up in the file. I also tried SetResourceSize,
>but that ended up with major hangs.
>
>Any ideas?
You can use the SetResourceSize procedure to change the size of a resource
on disk. This procedure is normally used only with ReadPartialResource and
WritePartialResource.
PROCEDURE SetResourceSize (theResource: Handle; newSize: LongInt);
theResource A handle to a resource.
newSize The size, in bytes, that you want the resource to occupy on disk.
DESCRIPTION
Given a handle to a resource, SetResourceSize sets the size field of the
specified resource on disk without writing the resource data. You can
change the size of any resource, regardless of the amount of memory you
have available.