INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (03/03/87)
INFO-MAC Digest Tuesday, 3 Mar 1987 Volume 5 : Issue 60
Today's Topics:
Me too: Lists in dialogs and problems with filtering
re: shutting dn SCSI disks avoiding long restart delays
RE: MacDraw Font menu scrolling problem
New MacDraw font limitation...
re: userItems
Scientific Calculator Desk Accessory
MacHangul comments
New Products (Very Long)
MACII Announced
help with hard disk hardware
Chinese Macintosh Software
Word 3.0
Delphi Mac Digest V3 #13
----------------------------------------------------------------------
Date: Mon, 2 Mar 87 22:26 N
From: <FRUIN%HLERUL5.BITNET@wiscvm.wisc.edu>
Subject: Me too: Lists in dialogs and problems with filtering
Can somebody *please* give me a clue as to what is wrong with my dialog
filter routine? Something very strange is happening and I'm completely
stuck.
I've made a modal dialog which has a list as one of its items. As far
as I can tell there are three steps involved in getting a list to work
with a dialog:
1) After reading in the dialog template, store a handle to a routine
that will draw the list in the dialog template using SetDItem. My
list item is of type userItem. The drawing routine that gets
installed uses LUpdate to draw the list.
2) Initialize the list, using several List Manager routines such as
LNew and LSetCell.
3) Call ModalDialog with a custom filter routine that will check if the
list userItem was clicked. If so, the filter will call LClick to let
the List Manager handle the event. If I'm not mistaken the filter
routine should be declared as follows when using Aztec C 1.06H:
pascal Boolean
MyFilter(myDialog, myEvent, myItem)
DialogPtr myDialog;
EventRecord *myEvent;
short *myItem;
Looks good, right? Well, it doesn't work and this is what happens: steps
1 and 2 seem to be executed OK, since my dialog appears on screen with
the list nicely drawn. However, the MyFilter routine ALWAYS gets passed
a myItem of -1 (except for the first time, when it's 0), no matter which
item gets clicked! I've checked the other two parameters (myDialog and
myEvent), but their values are always correct. It's just the value of
myItem that inexplicably gets scr*wed up.
The weird thing is that ModalDialog exits with the correct item number.
It's just the item number that gets passed to the filter routine which is
incorrect.
Can anybody help? I've tried everything, but I'm not getting anywhere...
-- Thomas
FRUIN@HLERUL5.BITNET
------------------------------
Date: Fri, 27 Feb 87 09:28:39 est
From: munnari!csadfa.oz!jlo@seismo.CSS.GOV (John O'Neill)
Subject: Re: Re: Altering Save dialog box defaults in MacDraw
Article is from "<DAVEG@slacvm.bitnet>"
>
>
> I'm very sure that you can't change a default value in a dialog like
> you want without actually modifying the program itself (modifying the
> resources with RESEDIT won't cut it). You could interchange the item numbers
> of the buttons in the resource editors but that is merely changing the label
> of the button NOT the functionality. I've found many places where I'd like
> to do exactly what you want to do, but you have to CHANGE the CODE not just
> the resources themselves.
Not that this helps with existing programs, but for developers...
I use a package called AutoDialog from JAM Software (see their adds in
MacTutor) which introduces a new resource type 'DSta' (Dialog State Rsrc).
For each DLOG, you create a DSta using their template editor for ResEdit.
One of the features of a DSta is the ability to cluster radio buttons and
specify the default, which can subsequently be changed by the end user.
This scheme (and other AutoDialog features) sure saves a lot of stereo-
typical code.
(The usual disclaimers apply.)
----
John O'Neill Phone ISD: +61 62 68 8818
Dept. Computer Science Telex: ADFADM AA62030
University College ACSNET/CSNET: jlo@csadfa.oz
Aust. Defence Force Academy UUCP: ...!seismo!munnari!csadfa.oz!jlo
Canberra. ACT. 2600. ARPA: jlo%csadfa.oz@SEISMO.CSS.GOV
AUSTRALIA JANET: jlo@oz.csadfa
------------------------------
Date: Mon, 02 Mar 87 09:31:54 n
From: <LANGOWSKI@FREMBL51.BITNET>
Subject: re: shutting dn SCSI disks avoiding long restart delays
The reason why it takes such a long time for the hard disk to come up again
after an 'illegal' shutdown (i.e. reset without unmounting the volume first)
has been discussed here (I think). There is a flag on the disk that is
set when the shutdown has been done in an orderly way. If on boot up the
system does not find that flag set, it will reconstruct the directory tree
(or parts of it, or some volume information map, I don't have the info at
hand). On my disk (80 MB, 45 MB filled) this takes about 30 secs.
The remedy has been posted here a while ago; it is actually possible to reset
the appropriate flag from within the mini-monitor of the Mac+ (by doing an
_Unmount or _Eject, don't remember).
But the real way to go is to use a debugger which contains an unmount/reset
function. Since you're doing 'highly experimental development work' (and
who does not, I just come back from playing around with Switcher background
processing and bombs galore), you should be using a good debugger anyway.
My experience so far is with TMON. If you do a reset command from within TMON,
no waiting when the disk comes up again. Buy a copy of TMON and try also
to get the Extended User Area. Beats Macsbug by lightyears.
Last comment to INIT routines: As I see it, the directory cleanup is done
BEFORE any INIT routines are called, even before the welcome message is
displayed. Therefore INITs won't help.
Joerg Langowski <LANGOWSKI@FREMBL51>
------------------------------
Date: Thu, 26 Feb 87 15:59 EST
From: Paul Christensen <PCHRISTENSEN%rca.com@RELAY.CS.NET>
Subject: RE: MacDraw Font menu scrolling problem
Below is a copy of the original message I posted on Info-Mac many months
ago, describing how to patch MacDraw 1.9 to allow its font menu to
scroll when more than 11 fonts are in a system file. I decided it might
be beneficial to all readers to repost this patch.
MACDRAW BUG WATCH
Note that MacDraw does not use the Font menu in a standard way. Fonts
are associated with text in a document by their *position* in the font
menu, not their font id. Thus, if you load a MacDraw file you created
using MacDraw on a disk with a different system folder than currently
in use, your fonts will not necessary be what you originally designated.
This creates problems especially for people using the same MacDraw files
on the new 128K ROM machines (which alphabetize the Font menu), and the
older 64K ROM machines (which do not alphabetize unless specially
patched).
I hope this is helpful for someone out there.
Paul Christensen
CSNET: PCHRISTENSEN@RCA.COM
Several days ago, I posted a message explaining some of the bugs in
MacDraw 1.9. At the time, I mentioned a patch I'd been using
successfully for about 3 months that allows MacDraw's Font menu to scroll.
This patch will modify MacDraw *** VERSION 1.9 ONLY ***, disabling its
limitation of 11 fonts in the font menu. This will allow you to use
many more fonts, provided you have a scrolling menu installed on your
system. How can you tell if you have a scrolling menu?
If you have a MacPlus, don't worry ... scrolling menus are part of the
128K ROM. If you're using a Mac with the old 64K ROM, Apple has
included the MacPlus' scrolling menus in the newest system software.
If you use system 3.2 then your menus will scroll. Otherwise, use
ResEdit to copy the MDEF from system 3.2 to the system file you
are using. I have installed the system 3.2 MDEF into system version
2.0 with no problem. I do NOT recommend using system software
prior to Finder 4.1 and System 2.0 (released with Finder 4.1).
Be sure to perform this modification on a COPY of your MacDraw 1.9.
NEVER USE AN ORIGINAL COPY FOR THIS TYPE OF WORK!!! You will have
to use a file-editing program such as John Mitchell's excellent
shareware program FEdit, or commercial programs such as MacZap
or MacTools. Simply open up the FILE MacDraw (don't open the
whole disk) and search for the original data. Be careful to
change only this data to the modifcations listed, double-checking
your typing. Then write the sector back out to disk. You will
have to repeat this process for every line (a total of 22 times).
For this reason, I like automating the process with MacZap Patcher,
included as part of MicroAnalyst's MacZap package. MacZap Patcher
allows you to write your own files that will search for data and
change it many different times. This also helps prevent human
error. Whatever method you use, good luck in your hacking.
NOTE: I make no guarantees as to the stability of this patch.
However, I can assure you that I've been using it for
more than 3 months now with no ill effects.
The following patch originated from Jonathan Hardis at Washington
Apple Pi. If MacDraw does not work properly after you make ALL of
these changes, then try the patch again on a fresh copy of MacDraw.
Be sure you are using MacDraw VERSION 1.9 and double-check your
modifications before writing to disk. I have proofread these
patches and can assure you there are no typographical errors on
my part.
CHANGE MacDraw 1.9:
Search for... Change to ...
41ED FAD6 .......... 41ED F360 9 times
0000 0C60 .......... 0000 0CA0 once
0014 6F02 7C14 ..... 001F 6F02 7C1F once
000B FACE .......... 0016 FACE twice
70E1 ............... 709B 3 times
0001 00E1 .......... 0001 009B 3 times
10E1 ............... 109B once
0C47 0015 .......... 0C47 0020 once
4E56 FFBE .......... 4E56 FF9E once
END.
Paul Christensen
CSNET: PCHRISTENSEN%HENRY@RCA.COM
------------------------------
Date: Sun, 1 Mar 87 17:05 EST
From: Paul Christensen <PCHRISTENSEN%rca.com@RELAY.CS.NET>
Subject: New MacDraw font limitation...
Several months ago, I posted a patch on Info-Mac that will modify
MacDraw so that its font menu will scroll when more than 11 fonts
are installed in the system file.
I've been informed that the new patch limits MacDraw to a maximum of
22 fonts.
This is NOT a limitation of MacDraw. Rather, it is a limitation of
the Macintosh Menu Manager, which cannot enable/disable more than 31
items. Since MacDraw adds 9 items for font size, you are left with
a maximum of 22 fonts.
Note that ALL applications which use menus for font lists are restricted
in this way. Thus MacWrite and MacPaint (which display only font names
in their font menus) are limited to a maximum of 31 fonts.
Applications such as AldusPageMaker and Microsoft Excel which allow the
user to choose fonts from dialog boxes, however, are limited only by
the System File's "physical" limit of 200 fonts.
Paul Christensen
CSNET: PCHRISTENSEN@RCA.COM
------------------------------
Date: Sun, 1 Mar 87 21:34:05 EST
From: Mike Kraley <kraley@ccw.bbn.com>
Subject: re: userItems
daveg@dartvax asked about userItems in dialogs.
I too had a hard time with this and would be glad to share my
knowledge learned mostly by trial and error.
The first thing you mentioned, outlining the OK button, is really
very easy and does not need a userItem. Following is a routine I
use a lot: (it's in LightspeedC - sorry I only read Pascal, I
don't speak it)
/* boldly outlines item 1 in a dialog */
OutlineOK(dp)
DialogPtr dp;
{
int type;
Handle itemH;
Rect box;
PenState myPenState;
GrafPtr savePort;
GetDItem(dp,1,&type,&itemH,&box);
GetPort(&savePort);
SetPort(dp);
GetPenState(&myPenState);
PenSize(3,3);
InsetRect(&box, -4, -4);
FrameRoundRect(&box, 16, 16);
SetPenState(&myPenState);
SetPort(savePort);
}
Call this right after the ShowWindow(). As you can see, you just
draw directly in the Dialog window(port). This suffices for
modal dialogs which will generally not get update events and
hence don't need to be redrawn.
Using the list manager in a dialog is more complex, but
fortunately i made that work too. Following is a code skeleton:
/*
This is called by the Dialog Mgr when our userItem needs updating
*/
pascal void UpdateTheWindow(theWindow, itemNo)
WindowPtr theWindow;
int itemNo;
{ switch (itemNo)
{
case theListItem:
LUpdate((*theWindow).visRgn, theListH);
/* whatever else you have to do for an update */
break;
}
}
/*
filter process for ModalDialog - we come here on every/*
This is called by the Dialog Mgr when our userItem needs updating
*/
pascal void UpdateTheWindow(theWindow, itemNo)
WindowPtr theWindow;
int itemNo;
{
switch (itemNo)
{
case theListItem:
LUpdate((*theWindow).visRgn, theListH);
/* whatever else you have to do for an update */
break;
}
}
/*
filter process for ModalDialog - we come here on every event that
happens during the dialog - we want to take the mouseDown events
that occur within the userItem's box and pass them to the ListMgr.
Everything else can be done by the default handler
*/
pascal Boolean SDFilter (theDialog, theEvent, item)
DialogPtr theDialog;
EventRecord *theEvent;
int *item;
{
GrafPort savePort;
Boolean retVal;
retVal = FALSE; /* default is that we did not handle it */
GetPort(&savePort);
SetPort(theDialog);
if (theEvent->what == mouseDown)
{
/* convert to local coords for LClick */
GlobalToLocal(&(theEvent->where));
/* if the click is in our box, pass it to LClick */
if (PtInRect(theEvent->where, &listBox))
{
LClick(theEvent->where, theEvent->modifiers, theListH);
/* tell ModalDialog that we handled it */
*item = theItemNo;
retVal = TRUE;
}
LocalToGlobal(&(theEvent->where)); /* put it back for
ModalDialog */
} /* endif mouseDown */
/*** should also check for return and enter */
SetPort(savePort);
return (retVal);
}
SetUpListDialog()
{
short type;
Handle theItemH;
short itemHit;
/* read the dialog */
theDialog = GetNewDialog(theDialogID, NIL, (WindowPtr) -1);
/* for the user item, get its handle and set its update proc */
GetDItem(theDialog, theListItem, &type, &theItemH, &listBox);
SetDItem(theDialog, theListItem, type, UpdateTheWindow, &listBox);
/* now we can set up the list stuff */
theListH = LNew(...);
LDoDraw(TRUE, theListH); /* show list */
/* do the dialog until the user pushes OK or Cancel or whatever */
do {
ModalDialog(SDFilter, &itemHit);
} while (itemHit > 2);
/* clean up */
LDispose(theListH);
DisposDialog(theDialog);
}
I've left a lot of the glue out, but hopefully this can give you a head start.
...Mike
------------------------------
Date: Mon, 2 Mar 87 18:03:36 PST
From: woody@Juliet.Caltech.Edu (William E. Woody)
Subject: Scientific Calculator Desk Accessory
Comment: Some assembly required.
This is a Calculator desk top accessory I wrote to learn the SANE
interface. I sorta got carried away with this little program,
until it became a big program.
The calculator does all the interesting functions off a TI-30 (scientific
functions, statistics, trig and hyperbolic trig functions), in an
RPN format. It also has 10 registers.
You may distribute this freely; it is shareware, however--if you keep
it and use it, please send me $10. Also, send me any comments or
questions you may have about the program; I like getting mail.
William Woody
woody@juliet.caltech.edu
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DA-SCIENTIFIC-CALCULATOR.HQX
DoD
]
------------------------------
Date: Mon 2 Mar 87 13:54:55-PST
From: Seung Yoo <YOO@STAR1.STANFORD.EDU>
Subject: MacHangul comments
A few days ago, I posted Mac Hangul (Korean language program).
The author want to make following two comments.
1) MacHangul has been tested with MacWrite earlier version (2.2 or 2.3)
and it's fully compatible with them. Even though MacHangul was
compatible with MacWrite (4.5), there may be some hidden bugs as
MacHangul was not thoroughly tested. It is hoped the bugs to
be reported.
2) MacHangul is compatible with not only MacWrite and MS Word but
also any programs supporting Desk Accessories.
------------------------------
Date: Mon, 2 Mar 87 14:27:50 EST
From: Robert T. Cartolano <rtc%cunixc@columbia.edu>
Subject: New Products (Very Long)
Here are the new product announcements for the Mac SE and Mac II,
downloaded from AppleLink.
Rob Cartolano
Columbia University
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-NEWPRODUCT-ANNOUNCEMENT-MARCH2.1987
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-NEWPRODUCT-PRESSRELEASE-MARCH2.1987
DoD
]
------------------------------
Date: 3 Mar 87 2:17 +0600
From: Grant Delaney <delaney%wnre.aecl.cdn%ubc.csnet@RELAY.CS.NET>
Subject: MACII Announced
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-NEWPRODUCT-COMPUSERVE-MARCH2.1987
DoD
]
------------------------------
Date: Sat 28 Feb 87 17:17:46-PST
From: Emilio Calius <CALIUS@STAR.STANFORD.EDU>
Subject: help with hard disk hardware
Tim Standing's article in the February MacTutor is tempting me to attempt
assembling my own sorely needed hard disk. A local supplier is offering
what seems to be a good deal for someone on my budget:
Rodime RO203E drive (47 mB when RLL formatted).... $425
drive + Shugart 1610 SCSI controller ............. $525
Being "hardware naive", I have no idea of the differences between this Rodime
and a Seagate ST 4000 series drive or between the Adaptec ACB-4000A and the
Shugart controllers.
I am looking for information/words of caution/warnings. Is the RO203E
a reliable drive? does it have some strange idiosincracies? is it really RLL
certified? Does the controller implement SCSI in a reasonable fashion? Does
it take an EE PhD to make them work together? etc..
Thanks in advance for any and all your help.
Emilio P. Calius
Dept. of Aeronautics & Astronautics
Stanford University
------------------------------
Date: Mon, 2 Mar 87 02:47:55 est
From: chi@eniac.seas.upenn.edu (Wei-Juang Chi)
Subject: Chinese Macintosh Software
Since I posted a query about Chinese Macintosh Software last week, I
have received several replies. One is about FeiMa, but was a message
posted last year (Oct/86), anyone has a more updated news on the latest
development about FeiMa? Perhaps someone who has a demo version can post
to the net since I also got several messages indicating definite interest
in FeiMa or any Chinese Mac Software. There are quite a few people that
show great interests in this, but unfortunately don't have the experience
or access to the software. HELP!
To my surprise, there are several replies about "KanjiTalk" which is a
Japanese System for the Mac+, it has the ability to convert Japanese to
Kanji (or rather Chinese character), but you need to be proficient enough
in Japanese to know the pronunciation for each Kanji. Of course, for the
same Chinese character, the pronunciation in Japanese and in Chinese are
quite different, so although it is OK to use it as a Japanese Kanji
generator, it is not an efficient method to generate Chinese character.
Lastly, about the "Hanzi Script Interface System for Chinese Character
Input" mentioned in Feb'87 MacUser, it seems to me the way to go for
Chinese application, unfortunately I get nothing regarding this system.
Since Apple held a conference in China and ran a demo on this software,
presumably,it exists.Can someone from Apple provide any information on
this?
Wei-Kuang Chi
chi@eniac.seas.upenn.edu (ARPANET, CSNET)
University of Pennsylvania
Department of Chemical Engineering, Towne Building D3
220 South 33rd Street
Philadelphia, PA 19104
(215) 898-5593 (office)
(215) 222-0808 (home)
------------------------------
Date: Mon, 2 Mar 87 12:19:19 PST
From: chuq@Sun.COM (Chuq Von Rospach)
Subject: Word 3.0
A few comments on Word 3.0, now that I've played with it a bit:
o I've found a good reason why shipping was delayed, bugs or no. If you
read the release notes, you'll see that Word 3.0 is Appleshare
compatible. I'm sure one reason Microsoft delayed shipment was
because they couldn't say they were Appleshare compatible until
after Apple announced Appleshare...
o Style sheets are really nice, but I find them somewhat non-intuitive. I'm
getting used to it, though. Between shoving stuff in glossaries
and sticking formats in style sheets, I find I can do things like
letters in a much cleaner setup.
o One thing that hasn't been mentioned for some reason is that there have
been major changes in the user interface. Two things I'm constantly
tripping over, for instances, is the different way you access
the glossary and the changed definition of the delete-previous-word
keystroke. Word 3.0 is NOT really upwards compatible from Word 1.05,
they are similar but very separate beasts. Expect to take time not
only learning new features, but re-training your fingers.
o Deleting does NOT cross a style boundary. If you have a couple of styles
defined in a document, if you try to backspace across the paragraph
marker holding the style, it'll beep at you (or equivalent). This
is somewhat non-intuitive, but probably a good idea to keep you
from accidently eating styles. But be aware that hack&burn
editors (like me) will find they have to be a bit more careful.
I'm really happy with this, frankly. neat software. It's going to give
me WEEKS of excuses before I have no reason not to write... (I mean, you
can't do any serious writing until you know how to use your Word Processor,
right? Right??)
chuq
------------------------------
Date: Sun, 1 Mar 87 16:08 EDT
From: Jeffrey Shulman <SHULMAN%slb-test.csnet@RELAY.CS.NET>
Subject: Delphi Mac Digest V3 #13
Delphi Mac Digest Sunday, March 1, 1987 Volume 3 : Issue 13
Today's Topics:
Administrativia: Digest distribution changes
RE: Rodime Drives
IMAGEWRITER
BMUG NL Needs Articles
Incomm Modems (2 messages)
Deadline Mac
RE: Hardware Help: Human Touch 3 to 1
Can you change arrow cursor? (2 messages)
Cursor Lock - Need Help (3 messages)
Folders that won't open
Extend Event Queue (3 messages)
MACWEEK MAGAZINE Launch
PostScript repeat pages? (2 messages)
RE: MacRecorder
AppleTalk fileserver benchmark (3 messages)
KANJI FONT FOR THE MAC (2 messages)
RE: Mac Shutdown
halfsies
Word 3 gotcha's
Megaform forms
MacPub<>RSG 3.0
MicroSoft Word 3.0
RE: New Macs Pricing and Model #'s (2 messages)
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV3-13.ARC
DoD
]
------------------------------
End of INFO-MAC Digest
**********************