mjohnson@Apple.COM (Mark B. Johnson) (03/02/90)
Following is some explanation about this latest version of the movable-
modal WDEF and problems developers were having implementing the first
version. These are both available for FTP on Apple.com in the
~ftp/pub/dts/human.interface/goodies directory, but I am posting them
here (they are relatively small) for wide distribution due to the number
of requests we have received for the original version...
Zen and the Art of the Movable-Modal Dialog Window
**********
A developer asks:
"I handle dragging in my ModalDialog filterProc by detecting mouse clicks,
checking FindWindow=inDrag+whichWindow=myDialog, and then DragWindow. I let
ModalDialog() field the update events generated when I am dragging the dialog
from partially-offscreen to totally-onscreen. Unfortunately, the
update-response draws a zoom box. If I move the initial zoomboxless window to
the point where half an imaginary zoombox would be offscreen, and then drag
back, sure enough--I get the half zoombox drawn in.
Am I doing something wrong with my resource numbering?
I notice that this behavior also happens if I renumber it to WDEF#0, letting it
become responsible for drawing all my window types. (I set procID to 5 in this
case, of course.)"
**********
Before I explain what's wrong, I have to make something perfectly clear. The
movable-modal dialog should NOT be used in the call to _ModalDialog. (Note:
Along with the information in this release note, you should check Human
Interface Note #4 for a discussion of the important interface issued involved
with this new window type.) There are two technical reasons for this. First,
and most importantly, is that calling _ModalDialog prevents switching to take
place under MultiFinder. This is opposed to the design of the new window,
since it is designed to allow switching. Second, a dialog filter procedure
does not facilitate the proper usage of the new window. Since the new window
can be moved, the window underneath needs to be updated. Updating windows in
the background is not easily accomplished from a dialog filter. Furthermore,
there are all the other events that need to be handled, such as
activate/deactivate, suspend/resume, drag, zoom, etc. This is all a
duplication of the standard event loop.
The movable-modal dialog handler should go through the normal event loop.
Before you object and say this isn't easy, I have tried to point out how
difficult it is trying to use a dialog filter, and you can get more information
about this in Technical Note #203, Don't Abuse the Managers. It is also
incorrect to call _ModalDialog since this prevents switching. Now you may be
thinking that you can use a modeless dialog. This also has a nasty problem.
In the course of handling a modeless dialog, the application uses
_IsDialogEvent and _DialogSelect.
_IsDialogEvent always returns true for any events (except for mouse down,
activate and update) when a dialog is the frontmost window. (Note that even if
you are doing things correctly, there is a bug in _IsDialogEvent which causes
it to fail if there isn't a window, i.e., FrontWind = NIL.) Applications that
are MultiFinderAware (bit in 'SIZE' resource) need to make a fake activate
event to pass to _DialogSelect if their frontmost window is a modeless dialog
when they get a suspend or resume event. Since _IsDialogEvent does this, the
application has to check for osEvents before calling _IsDialogEvent, or ignore
the result from _IsDialogEvent. Note that if the event gets passed to
_DialogSelect, it handles the event as if it is a nullEvt (it does that with
events it does not recognize), which is harmless, but if the application misses
it, there could be a problem.
Handling a movable-modal dialog is just like any other window. There are
really only two differences. If the front window is the movable-modal, then
you ignore any click outside the window. Also ignore menu command keys. The
latter is currently a subject of discussion with the Human Interface group.
I've found that it's very difficult to handle the menu if the window is modal.
The biggest problem is what items would be enabled? Should a desk accessory be
allowed to be opened? Maybe the solution is to disable ALL of the menu items.
That's up to the Human Interface group to come up with some guidelines.
I've found that adding the movable-modal dialog support to my standard event
loop only changed a couple lines of code. I'm working on a example that
demonstrates how to use this new window type correctly and that covers both the
technical and user interface issues. It will be published from DTS as soon as
it is finished.
Another point that should be covered is this 'WDEF' is NOT a replacement for
the standard system 'WDEF'. The 'WDEF' that supports the new window type will
be built into System 7.0. Until then, applications can include a modified
version of the current 'WDEF'. This modified version should only be used to
obtain the movable-modal window type. The 'WDEF' resource ID is 128, therefore
the ProcID should be (16 * 128) + 5 = 2053. To support zooming, you add 8. Do
not use this 'WDEF' as ResID = 0. This would override the standard 'WDEF', and
things are changing. System Software after 6.0.4 has a very slight change in
the window's drop shadow on a multibit depth Macintosh.
Furthermore, the window may change slightly in look and behavior for System
7.0. The current version of the movable-modal draws a gray frame when the
window is deactivated. This was done because the application can be switched
into the background and the movable-modal should not appear as a modal dialog.
You should use the standard 'WDEF' while running System 7.0. In this case, the
ProcID is (16 * 0) + 5 = 5. This is a little tricky and I'll leave the
explanation to my sample code. I promise I'll release this very soon (I just
got the 'WDEF' finished).
"What about that bug we saw?"
The problem reported in the first release of the 'WDEF' has been found and
solved. The real problem is not in the 'WDEF', but that it is being used
incorrectly. Namely, this new window should not be used with _ModalDialog.
The problem is a conflict with the Window Manager and MultiFinder's patch to
_ModalDialog. There is a field in the Window Record used by the 'WDEF'.
Originally this field was named "spareFlag." When zoomable windows were
invented, this flag was used to determine if the window supported the zoom box.
Since that time, this same field has become known as "wZoom."
MultiFinder uses this field in its patch to _ModalDialog which prevents
switching to another application. Hitherto unknown, this conflict wasn't a
problem because modal windows had no title bars. I've made a change in the
'WDEF' to ignore this field of the window record. That solves the conflict of
MultiFinder's patch to _ModalDialog.
The fixed version is a ResEdit file created: Mar 1, 1990
You can also verify you have the right WDEF resource by looking at the first
few bytes.
$600A0000 This is a JMP instruction
$57444546 This is ASCII for "WDEF"
$0080 This is the ResID=128
$0065 This is the version number 1.01
Finally, I've named this 'WDEF' resource "movable-modal 1.01."
Jim Reekes E.O., Macintosh Developer Technical Support
Thursday, March 1, 1990 5:08 PM
The WDEF itself follows...
(This file must be converted with BinHex 4.0)
:'de[GQ&LE'8Y6@pNB@`J9d4&4L!a,M!a,R0TG!"6593K8dP8)3#3""F8!*!%B*e
6593K!!)!!"F8FNaKG3%!N!J#(9TPEL"KEQ3J6@pfB@*XC5e0Ef4KE#"%D@&XEfG
c!*!LG(4bEh4dH(3"!+)6+'QL%bKT!*!''`-!N!B1Q3!!j$X!N!DFAPV+Z!%4aJd
C%(63P!%44!iG%'r-)&3)SXNE1f(%X#R6`L+C-'a!%%N$mXdC%&I5'(acTd%$&6"
MbR3C"!5C-RE+X(N$Ti`FJR2@c0(K8N35%'J+NYPS8dkB-fG8RP3*SNfHLQmqXKP
CmU5C0'cSq)3LjmdB%'+ZhK3lKSl8UQrUc&NiKNfD-8*CJ"LM%1pE)bV*T&ajTiG
+)Nl2V,L$jLkD`@4BpV$+GHFC[8SR#K5C'$*,&b"!(0hid#2)bLC4T!$a9HI"K![
V`2NS&J41JA6QJ$JMd'FBX3FCEciDTNh6Te(GR)4YNk4PeQ@0``RMd$QE2#dLQTN
c4NkCcA6H)(a$"q6el'kiHaF)'N390fEH1+cMjVI12(UCbkE0dIXF1'qNYa!C6Yf
K@aJJk2(''mD*m3BHl58Kd9&YA,33FbUPi4C)#5lBKS0iE$5(ERF%aY*iQS%!S%S
2#HFG8L"*9"!)DE6aP%V8AD8JJb##F%GFE"`NaN,DUIHG'jJCT0P!"$k&9KKik69
((5m+&0FCD,63`P'm2F4F8Qa)Y11($ajhad!UZ8#6F8G&pYBF$*D4d&YhP+@FMaU
L8G99rX8PaaJ,Z9((Kcj*pB0,4lP"hPdA*Z9PBlS0QC3GDFK(%"Y``JK(6qR41#%
)hJP+k%mDSRJ&%88B-3)-HT(QeTfP$MP'R+#@m9q!Fk5Kd8,arG4NLAHDYbHHK#'
84dpcJ)E#8A-p"%GCBb4"")Sed$M3R,U0%FCFHN@dPjpcZC!!JJJZb@5Z#Li*88D
[#ae9"Kj`X"%'9BcpGJ+*GPiQ'S`jS@MM'J["fBDFMGhCNaaQP0(@GAYY4&el9&"
8)8DlYP#K9Xee"F)FD!"jN!!66e#"9Qac(839FpUb%9*i)(aKfPE1QG3H#Nk3!&H
'$U%&XG1G*5D8SNUpfZK@J0C1P)CZhMNm&`L+LU9A(R&Yh(%G3Hl9eaSJ)$(SM%Q
i)4E#8#j8FfdMd-#DT3L5FI3BFZ9+Y,FBYJ'J3`8pa+*2CS40iiKeP''b'hDm`8C
1`H9TY'jZP(%(XC%Y6XHaCBJE@X3q,86GK6mLT$!DEYc&SAIEiRVf6pLf"jJFFp#
4j%%9TNkMh2+9jr9eHKdpd@plQIH@beQG&[0*cplQY@jcp-cA@bbA"l#+mJ)+!Rd
hrG3%e@i"CT!!6a"$ZMG%Qlj4-SV-hC6V'32"69(LL`2EZ*3U19qUlH+R3ElI+*T
hB[%D(UpFHe-S(#!CQ-RBFli5&TqS#&TqSp+!hQ!VTT'(09!#LiEXNk*RmF5!FRN
+N56#(23alM1KQ8,l'K8SaAe`FGSDb*!!i%+ir&"%I5H#RNm5paXp*Fj[ZQ(C#[G
M(c+dT`Ucq3fG6'5JSM&($&"D`aR+!VhY0Fdff`,,9D!d+lRCK@2d-d0d##*!Nl!
',&mc(C9J)iF+HFH&P52)Li6&(2)Sj#I#bmhY(R,$eiKRK8Nab%B!Z,%km!8S"'P
,'M!LPKIF"%TZ)@3CT#3A6T(K"IiCe#+2Skmak891BmLHl@`RV,6*aLlD'PVj1%L
4e#Q&1JH*)`Kf`K-e0B"b,-c)4Lc@Zj!!U%eMH9b+!6RQXGf)*b&-a&++&&9'$UQ
5PA"SMlVB"3+Se3%LBP#$`Kk5Q6Q%i5VBfTXE6[#3!$*X#crlQY5&j*!!"[UaE%9
HJdJG(Y+aaDR0$&pK@eKSC,FFbL%2b"12A#cA4Dq!d5HVDfE88VJE1F(P48#6Mp!
U0C!!M-6P8CXF#"8felQ8J@"X#aQ"$'!`!ld3)8$FC)JBpTQL*K4%JkL,8$d[PDR
fbFFlE8&4bN,#1kfJjL5jFS2cXKQmR!a[BmBVf"RD8l2&1E-UeabCdGb`"Z3j5U$
2*#K*%A3aRGK+0lHdM#B2K#Ra*19!60[@i`liKPfe)8,ASXLXU,3dEqA5,X'#bde
%K0AISC%JQ`+P%)Qf6pem)3PcZ'N4I%T0*AhKT[hE5&YFqGI!rQk`Z,R8(Dk*0$P
4U90dN!"$hdC(%$GF*Bkk3F'l!!@(Kr3+,L4Y(*)#Q8J+CSD(BPQ0F"VDcqda4iX
"SN2V@N6%Q@&dMVEaUDHJUXB&1P8UfAVT0'QR'B5#GD46'8KM"8YB(cAQMpVU+ce
4P$H`$*H-#cRD0UPj`YUj)(*k-B+Gk!!C%26JSNPJJZ3BNPI2L6+(6leF4DLA"ZY
&,`L6I4%+a2#qJCaJ#NR33K&18#Xi83P3UkQM[m+`2!6PVF+#9'4`)h[1EH932)I
pA@+Rq9f&T1%RZ2ADENqi2DTQaDSMUZeX0A19,R&a5[m4b%%X&FQ"EGKVr"YKb`"
,hFK'TS(BZQXBkKY+KX,S`eC6'0C1kch)rR4)c*cTlSMm@-*fLe6NN`m*'d`pk$"
Sb)lYLTAT3&5E!6F0T&b)+VZNQqQ-b*`J4Ua9fe)lGLT&4#P5jED'qck`#NTPJhd
)#NTeC2cLVQGk!Zef'qh!Km$8**h63aP5S"I'1'Cl55NMAI8b8V[&'DraXUq6fh#
dZHK'3fKmd9UVYN)%@G#XVN6#RprLBSV0mQ)FbUSAEDF'Z6c%,KAf,%6)H-,XT9'
rS&2C93,%-$TNlTd*#a@JNK8D#D8SaE`YPZfB-c&CFJ6BE%$M3)iU2f*D6YPeZ3[
@(TUVQk3)KRGSMmjD'ZBA$8a3hfU$MC3%X$a`'`5`P"FG[VBpYXNK9(4J')+Q&%d
5HdYYh'QENb'G)Ud0A$4H`j[HPKLAC(El"2f+6a-6JMX0h3X%1EPRFq"jPc+cl+e
Mr[FciAa[)Qi2hFj'LraiilTEEm3iYUZAhF65"K,eFS8#-6FCIK$#U98YEEE#'K@
[+TqVe&TP,-'c8LqBZ+Q(aU4j@#&ci-5'G6Tjh1,"Z,NC`J3Q31681UGR'CUH2A[
T4MEJSiM(Z4CbX$Q2j)"R@49M!`Fmq8aJ#cP$(G)`9jABbT9*3$Q[iU)NPP16$'U
l%lN[BQjDBNcB1*A0h,`N(UYX6(BIN8-UUiY-L,L"BA`T#'m1JU#eaQXKF'fJYfC
eN`LG`$JrNN06ld3d",fV1,m(lNdUP*l-fNFhl8345E2T3A`EUbIIH[KbTpMjTmi
UjT&bBiVB`MR2KH5eFb&9iI2Q2VjG[YZm9CP5i9!(M4a0)3H"@mC""&3`"B!%*mh
hDL[e&Cf$46j%%dhc4LVb"L`#A,a%08*#&aEL(5D$AlCc!UH5+JaQ1b!M-JML(I%
50[pQ@TDbGV#(5KYMF%`(!L#)+NC`!N&AJb*SJDSA1rK93ZRMFim$IL@LIbXd8Q"
N,5`c"6+iGb"`!bi!!crN0Gi&'kZeC+R@C+*$81h6G[EQBZp86JH"INjQ2R4"*4"
(Jb&iJeXP9h!QKM$R%fic%"GB0G6QG53MGQ99(LFM-D4A-HM'BN-B1C0$%6TiJ`h
Q*miM,GX6!c+!!l'f,Q+@)Q4K&SaBKaN)!LJ3!cB!!LS!!Sk)!kZa!L"3,Hqe868
`!a!M(P2523l4)3`L&8m60@%!HL#!!qha8CAf2%Z66BI)B)-Q"EE#L1mPKB@BG,f
dJH4NEbji5V+RKMCi!J%e*mTa),+@4mNa9#(8K-Ba"4&KEIS9"QE!F$B3K5jJ0Pr
&46&h&A0J&eMb%,QR(1'99JZ"Ebp()$`K0E9i)XeA&Ia&B!pa%k@P*bBe"LcL2@M
J5NB`4QpN4T2%(0jR)eF4Mlba-Hk)"K&h&96"5PUR**)5"T4L+DI&K+RMK&"SM!L
R9QJB@@6i0RMhKlp@5fB#9NZ89&T8(2@S%26)B[$M64R@3fdi@9J9)!XK+f'`I45
"KASP5VQM3J%6924cN!!TJN4iJAK+NKQMjf[R*T1BZ)YBk%dr-@KJ''brdajC%$9
GLC3"mi,2q)[@"4B,S9PZd$Ph3T)cH**SG6Lj`bf8##f-D$ZEf)QI#!1M@)VZ9BT
Yb%QVT#%40dlb4Ri(NARkjc$p`Kc[NS,e`C3XihV@C%8D@(cG4PDXYM55'4**idf
pU$hVZ$%,-K$,!J,&jMTRm%$-iCB-q(pqN`+Z*!*AN!"I$V*1`!9G2K)`BA!(2d!
ZVd344ZH%+"Jl8EQ6Ai%kPQC9fl*"+H+@k6JNQk&b9kNNE%Fi34GYC'9@6[4!IEJ
3[dKU`1Pjff8l3r)@qr3hXb*q#j-(4)@6c-9p*Z4pAIP%1r3p(&G6[Y-93EHF5!G
@X`)IS-4E2X-FRV%i*P8I["'@5M)pBG&IJH%6,cFGG2"(,#1J-%1JKCK'LYND9A1
H+1&c`MLI"a'ID)&0KVL'1"JD6d"1b@%H-'Sl*KSFJeBI!h-3)[!IPf-%mM*8)K!
D[ENCBc*hq%BL*!SiZ1%h,U5M4HSMJqDL,,-@2X&UL90LpHKcVEKkjN34Bi)@$a*
N1Y8SZ1-@!c1Pa)16Aq3D6cBbL`F#Dk!SC`*))R!(@Z!K,S#F&PSp'IS6fT901eS
d'P*R[q'K)2Bb0r@@Ip46Z%%m3C92RH9'"U58UKBJlB%%HH)6,%-IGmS5Uj90#@S
'#fUPFc"HA'5JG(U85a1)63SM"k%S#+%K6)&%+A9br@)MAfJeZMH2ebQM+0*ZNfL
Sj@5(TqCpPbClIIF3hiPNDK8JU(SA$q%YJBUKeb-('lUSH[+KMPU@,J&,Ai%(p01
5D!*@`MJ(4D!fTJ@AH`%k`)%c&8%GS+JA-C!!!cN!!bjaPP%e)b#4+6%(CeGa91+
8)MD+N5KKJiRiB%9j&4c*Dir#+bIQ1JQc1'NK&XRL%L4J!c!!!d(`X4mE'XIiDQ#
P"%d!"GD51TSP5!(5!#43!cG!!c4E!c63L53E-CZN'd%`"813!!4(F9UmDB2N3J)
IL`-`3,*+Qj)lQb,V+Ldp%)S`ql%f8#e,@l+f44(SbM5$-L3r%304'!-ZB6diUKH
Cebmq1UBI5+apiV!J)!,P"SJb#EB`!,E)f3"+8#-J))aP!$#k833Zm!3ZS"F&HC!
!(#-5Yl%6"i0`&19q)$!&2HJ3bFP@(`&1*[8RHK)$q+U[54XD0D!$-)!$)!!&6H!
5!J!A6@pfB@*XC5e0Ef4KE#"A4%9')$%Z-$&TB@a[Ch-!N#*bFh*M8P0&4!%!SK,
[%D)6*`B!!!Pr!*!'"i8!N!5EQJ#3#0A6!!!%#!JJJBk!#!i',%+`SF1(%#&LD2,
'6TN`BYL8D8'46"Jf)+i3+@)%4!`A-')B%8"3cTb!,Z@-N6+P#*'"!*3"!"'a*`"
4%Yj&H*MJMmqM5*-UAFUdUG1(#'b!84"3*%N!J!#8F@,P(cBNjclJ%H)+!!8'EJ!
B!)"@S)Qf!4QX%FJ"4*8@82kK-j(@34*m#I5aF!%J)@%*#!S!''$&R9F"$!I!1#`
!#)!$$#`AZ1)i'`-m2ri*F$6&mEBa#&lJ51!0e4``BP3hB1%D""l@)[$-4S*Q*fm
!1S+J!`"M5$VL)V!PPi%0#K)S5@$`--Xm#V*rr&"e3X8(LCYrqP4Pm2k2RLS03Ni
*1I0L!C)hDP8*SI)%a"F38%$d4Y!#b6p`S+5!ecrFN!$($LU,q1$#2qaimjdl@"b
"`$%`6H",%'``m%-!NK`K6K,6I-H1$ardF-3rm-"`!!'@05!1%Md!mBmmkD'#63Y
Ir%21C'a"!d33qJ!(c6i!f1!%*#mX5!iUf5Lai$CR5!$#G`#U3*jj&C!!&ai&5HV
P'K2IH)#2%elBj`drE$N"$3"S#)$-!,`!i!!!A"#J!`'812P20QF3)-4FF-!"`5J
LR)!%!)+FJB1Hf*`KJa3V!"!(#9"!SB3)9C!!N!$12iaSqJmNF!bJ*jm#H!&%*'+
J'SdBUm+!``+U4#2&0e+J!%8B!"4!L"0eJ""TSJ5!!!3S)r#U4+4ZR!'!!&J`B!K
"",#a,!bSH))#$JS)S%34CbL!$5%-4(D'!(J!S#H8#-!4J"`!i&S!',J5`%iQV!"
!`!X-S")+!i3dG)B*,a#!bLBrX+$@$a4NF`8UNa4mX-%#4q+`!!Sl(('ei3TNKKL
Mp[N0&9P3JF*d,!Q!VfVCST*+`!168!85D[b$MhEikRXX!'qBB3$-HS&"!-r`d#c
`*LF,[(+qS45YmJ[6$E$B`$c2h%R0S93lUXlEQL'3!"raSR$Z'HQZ5d#mS&ap,p)
RBb[!d[Q1JS2""YK!J#A5#Q$*A)U)-`3FfNB+alK`J'!,%'`)B!-!eY6p!`'-pNN
!%6Ye5Fi,&k#L4`k3!"Y3majfiIF##J"`3$NUj16`aF'583#0L&)!m3-!$(rY!0p
bM'f["cp-&`!ULB!`Pb%"[J!"+S6i$J$`+NL15Kib$#!0hV)386J1!5L"GjpF%0(
&%$IR6!!B!ERbGES$e)lV!06JQlY!2b`SMmSG)b"&h90)Di$$"Z3`K&SJ8#"!9JH
iM-Y+)#-Xi!X*HKK!DdV41!E!i!)X!S!'B#%p!H!!!+C6#qD@GF!%mJ)9T4##+[k
"KC[p63&&d-F!k%'(GLd,%)e633S(3)S@iNS!GJ#$"k,81![-%"Cd%-!0a6#9'C)
ML$H%!Ur@m`)$h*!!&pXkJ`%k*S#2eD`95[M!'AL3!$8CG1m-,1!4BJ)L!$H)`(K
f`!m)3'F!2$J!%N6J"4$D!!%N!!'15$##(0YJJ&#"$`#H80FI-A&$+6"4FrR#SKB
$SSJ[mJ%%1`-##*C`3hC!ScF'J-4F)%"&,!"KG605!aF-B*N&V-%+*M`$"L"jbF*
S%J!5b!`XhB#!+!"K$6b!`rGdd$JC`-!!Nl`K+9U*J&GDJ)TG!%*QrY'10Ta&4[G
`J`0`&3"jp!N1"J"$(pmP!,ke`$)8-0D#'Q@l!&MMKPb+P"eUpSf4,BZ$NC,$b4L
!-J2!V`KQ8)#+TR!U+SL$%@$J3-B#B!B,R)`(rmK(3Z'h)$iC3%9Ck#FU[K&&!f4
X!'B3RC*1GJ'@S@+L,iLRj%)+!$QJSKbmDQ)p9@B#)laJ![Xme45DU+mI4%S!0V8
A!Di!!!L-VQ&c@F[D)Q'#5rcd"d&G&LSN&LN$l,5R2jM!6hf`#RXY9D9U8aQ[l#+
mpVMQDa6S`K0Hm!$aL*@Xje%AZkKT""48P3)TS)*1jIU!D!(J!F[URXjU0JS`)##
&!@#($G8`X4pF)+I$DeLN+,$8R%S!B3c,U38J'iQ[dE1X&H$#@-Y+!FfkKPGKm))
F$J!'#B3"#cQ`hl,NS!iU6L%)dkLE$0`h$5T-J3TaYCFF)""EHrA@!%(!K`)F!!*
P`!"0!K!#*N!3*`Md&!Pi''j)-#@#+#!K$F[k$5*rN!$F8k##(D#P!!a8Gi3F@)C
a$68$!HURPUh143liS3)58)#*&'$"AU#9j&`%35P,KF%#kJf$",TP2%(B+J`S80G
I!T05#Ea!!f4P@N)AQJSQFZ!pDN&&+kC`!3Km!!T2i*9EHjU#Z9$!AX%8`XRB5!5
4`'GYU1$9KX+J!&@)p`0K))!U+V$9lh"$"Q`8"TS3!!Y")8#+8F#3!$hB&34i3%!
")%#!I9i!!$A*9`Qp)B!DJT8I*GEK(`!!XjJGmSYpJ!!4S&M%QG0mjPqS'3'J@%#
8bib8!!!L!D!S!$#``J&iI!!3"3"#!N#!Nk181FTa4V5FiEcS4#1!cNFCb+!$(4!
1`#%JJ4jdSC(b!A"!!!33m!%%4$$U8S[J!q)JJ!"8VHS$q+-KK6B)3K3#!)B)S3'
%8!!U#-)"!-LJ+L-a!N'SNT@G0%3)$'#""0T3%BaST!A-pJK)6T)51Q3!!!:
--
Mark B. Johnson AppleLink: mjohnson
Developer Technical Support domain: mjohnson@Apple.com
Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson
"You gave your life to become the person you are right now. Was it worth it?"
- Richard Bach, _One_baumgart@esquire.dpw.com (Steve Baumgarten) (03/07/90)
In article <39127@apple.Apple.COM>, mjohnson@Apple (Mark B. Johnson) writes: >Handling a movable-modal dialog is just like any other window. There >are really only two differences. If the front window is the >movable-modal, then you ignore any click outside the window. Also >ignore menu command keys. The latter is currently a subject of >discussion with the Human Interface group. I've found that it's very >difficult to handle the menu if the window is modal. The biggest >problem is what items would be enabled? Should a desk accessory be >allowed to be opened? Maybe the solution is to disable ALL of the >menu items. That's up to the Human Interface group to come up with >some guidelines. I always thought that this was one of the great failings of the Mac user interface. While DTS has preached to us about designing our programs so that the user is in control, so that he's never surprised or locked into a mode, etc., the Mac OS itself violates many of these rules. Specifically, people tend to want to cut and paste in dialog boxes and are continually surprised and annoyed when they can't. Even if it's the kludgy Hypercard script editor solution of supporting the keys and not the Edit menu, anything would be better than forcing people to type things when they shouldn't have to. Nisus solves this problem very, well, nicely. It *always* keeps the Edit menu enabled, so that you can cut and paste anywhere, even in modal and StdFile boxes. I find myself reaching selecting parts of names in other programs' StdFile boxes and trying to use CMD-X and CMD-V, and I'm always frustrated when I can't perform this most basic of Macintosh functions. Best of all, since Nisus allows you to choose cut and paste from the Edit menu, this feature is available to novices as well as experts. So if there's any way to add support for Edit menu items in modal (and non-modal) dialog boxes, I urge the Human Interface group to consider it. It's easy to forget that new users don't know what we veterans have known for a while -- that some things "aren't allowed", but for no justifiable reason (apart from programming, which is never a valid reason when you're trying to explain to your mother why the skills she just used in her MacWrite document suddenly cause the computer to beep). By the way, Nisus also handles the issue of command-key equivalents in dialog boxes with equal aplomb. Instead of forcing you to wade through a manual as Word does, Nisus displays the "cloverleaf-letter" combinations right next to the buttons as soon as you press the command key. So a novice can use the dialog boxes in the traditional point-and-click way, a more experienced user is given reinforcement to aid his memory, or is just allowed to consider the possibility of using command keys without having to haul out the manual, and an expert is not slowed down in the least. All in all, Paragon software has done some serious thinking about their program's user interface and about the low-level Macintosh interface, and I think they've made the right decisions. If the Human Interface group isn't familiar with Nisus, they should definitely check it out. It's also a great word processor, but I'll save that discussion for another group. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." baumgart@esquire.dpw.com | cmcl2!esquire!baumgart | - David Letterman
murat@farcomp.UUCP (Murat Konar) (03/08/90)
In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) writes: >or locked into a mode, etc., the Mac OS itself violates many of these >rules. > >Specifically, people tend to want to cut and paste in dialog boxes and >are continually surprised and annoyed when they can't. Even if it's >the kludgy Hypercard script editor solution of supporting the keys and >not the Edit menu, anything would be better than forcing people to >type things when they shouldn't have to. Guess what? Under MacApp, the Edit menu remains enabled when displaying any kind of dialog box (well ones with edit text items anyway). So, the user interface dudes aren't sleeping after all. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
tecot@Apple.COM (Ed Tecot) (03/27/90)
In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten) writes: >So if there's any way to add support for Edit menu items in modal (and >non-modal) dialog boxes, I urge the Human Interface group to consider >it. Look for this in a future system release. _emt