ts@cup.portal.com (Tim W Smith) (08/19/89)
I've got a modal dialog that sometimes needs a textedit field. So I made a textedit field that was offscreen. When it was time to use it I GetDItem'ed it and SetDItem'ed it to the place I wanted it to appear. That worked fine. It showed up and could be used. All was well in the land. Then I wanted to move it away. I GetDItem'ed it and SetDItem'ed it to Siberia ( actually, somewhere off to the left of the screen ). It did not go away. Does anyone have any idea why I can't move it around like this? I also can't move it to other places on the screen. For the curious, when confronted with this, I said "intercourse SetDItem" and switched to using a filter function in the dialog. When text needs to be edited, I just TENew the record myself where I want it, and handle it all myself from the filter function. When I'm done, I dispose of it. This seems to work great. Is there anything wrong with this approach? Tim Smith
sas@tut.cis.ohio-state.edu (Scott Sutherland) (08/21/89)
In article <21428@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >I've got a modal dialog that sometimes needs a textedit field. >So I made a textedit field that was offscreen. When it was time >to use it I GetDItem'ed it and SetDItem'ed it to the place I wanted >it to appear. The problem with this is that SetDItem (which places the item in the given dialog's item list) pre-supposes that the item is NOT already in the list. Unless I am misunderstanding you, you already have the item in your list, if not at first then at least when it is time to move the TE field offscreen. Also see the note on IM I page 422 (just below the description of SetDItem) that says "Do not use SetDItem...to change or move a control." >That worked fine. It showed up and could be used. All was well >in the land. > >Then I wanted to move it away. I GetDItem'ed it and SetDItem'ed it >to Siberia ( actually, somewhere off to the left of the screen ). Luckily there is a really easy way to do this. Simply call HideDItem. (see IM IV page 59) This will move the item offscreen, deactivate it, erase the items rect and add the rect to the update region. When you want it back, call ShowDItem. You might try starting with the TE item in place and the dialog initially invisible. Then if you want the item offscreen initially, simply cHideDItem before you call ShowWindow. >It did not go away. Does anyone have any idea why I can't move it >around like this? I also can't move it to other places on the screen. > >For the curious, when confronted with this, I said "intercourse >SetDItem" and switched to using a filter function in the dialog. >When text needs to be edited, I just TENew the record myself >where I want it, and handle it all myself from the filter function. >When I'm done, I dispose of it. This seems to work great. > >Is there anything wrong with this approach? While this approach will work, it really makes life harder for you in the longrun. In general, I try not to do anything in my filterProc that I can do in the body of my code. Handling things in the filter often adds alot of unneeded complexity to your code making it harder to debug and update. Hope this helps. I think I spent the better part of a week trying to figure this stuff out before I stumbled over HideDItem and ShowDItem in IM IV. Oh well :-} --- Scott Sutherland sas@cis.ohio-state.edu Staff Software Developer The Ohio State University, Department of Dance
tim@hoptoad.uucp (Tim Maroney) (08/22/89)
In article <21428@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >>I've got a modal dialog that sometimes needs a textedit field. >>So I made a textedit field that was offscreen. When it was time >>to use it I GetDItem'ed it and SetDItem'ed it to the place I wanted >>it to appear. In article <58078@tut.cis.ohio-state.edu> Scott Sutherland <sas@cis.ohio-state.edu> writes: >The problem with this is that SetDItem (which places the item in the given >dialog's item list) pre-supposes that the item is NOT already in the list. >Unless I am misunderstanding you, you already have the item in your list, >if not at first then at least when it is time to move the TE field offscreen. No; in fact, I don't know whether you can use SetDItem to add an item to a dialog item list. The routine description doesn't say that you can. I tend to doubt it, since IM I-412 says that if you're going to make your own item lists, you have to format the data for them as shown in the format of dialog item lists; this would not be so if you could just do SetDItem. I use SetDItem for one thing and one thing only -- binding drawing procedures to user items -- and in every case, the item is already there when I call SetDItem. >Also see the note on IM I page 422 (just below the description of SetDItem) >that says "Do not use SetDItem...to change or move a control." A text edit field is not a control or even remotely similar to a control. >>That worked fine. It showed up and could be used. All was well >>in the land. >> >>Then I wanted to move it away. I GetDItem'ed it and SetDItem'ed it >>to Siberia ( actually, somewhere off to the left of the screen ). > >Luckily there is a really easy way to do this. Simply call HideDItem. >(see IM IV page 59) This will move the item offscreen, deactivate it, erase >the items rect and add the rect to the update region. When you want it back, >call ShowDItem. Yes, this is true, so long as you don't care about compatibility with old ROM machines. Few people do these days.... >>It did not go away. Does anyone have any idea why I can't move it >>around like this? I also can't move it to other places on the screen. Sure, I think the answer is pretty clear, but I'm assuming you made a small mistake in evaluating the results of your SetDItem, Tim. The item is getting moved. However, SetDItem does *not* do any drawing. Therefore, when it's off the screen and you move it on, and the dialog has not yet been drawn, the text edit item appears, hey presto, in the first update event. However, after the dialog has been drawn, just moving the item with SetDItem will cause no change in the screen appearance (except for the location of the text caret, if you moved the current editText item). You need to erase the old location (see the caveat on IM IV-59) and do an InvalRect on the new location, or just DrawDialog to get the whole thing redone simply and with a flicker. Of course, if you are moving it completely off the window, you don't need to cause the new location to be redrawn. I hope this is correct -- this kind of remote diagnosis is always tricky. It *is* remotely possible that SetDItem won't let you give an off-window rectangle, but I doubt it. That wouldn't account for your report that you can't move it around to other places within the window. And one subjective note -- I have some aesthetic qualms about dialogs that change their appearance. In a very few cases they make sense, and for all I know this may be one of them. In general, though, they are confusing to users for a variety of reasons. First, they're intrinsically modal -- the dialog has a number of states, and how to get from one to the other is going to be anything but clear to many users, especially the majority of users who don't have the programmers' ability to keep a mental map of states and transitions. Second, they can blow away screen shots in the documentation if the position of an item depends on some external factor -- the user is tracking along through the manual and encounters a dialog that is different from the one that the manual says should be encountered, throws the book across the room, cries, and calls technical support. So, I'm not saying you should never move dialog items around, but you should always think it through very carefully before you do, and take any reasonable alternative that presents itself. Jumpy dialogs are very rewarding to program (I've done a few, long ago) but tend to be very irritating to many users. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
cyosta@taux01.UUCP ( Yossie Silverman ) (08/22/89)
I had to do this once for a program that had a Dialog which served as a small spread-sheet. I used the List manager to put up the spreadsheet display itself (grid and data) and a TE item for input into the active cell. The way I moved the TE item around was the following sequence: HideDItem GetDItem SetDitem (to new location with 16384 added to the horizontal coordinates) ShowDItem The 16384 is the "magic" constant that Hide/ShowDitem use to move the item rect offscreen. A later version of the program had the Dialog modeless and yet a later version got rid of the Dialog all together and used a Window and the TE manager directely. This turned out to include just as much code and was MUCH easier to maintain and read. One interesting aspect was that I had TWO such small spreadsheets on a single window. There are some strange problems associated with using the List Manager for this sort of thing, but nothing that can't be solved (I.e. not bugs, just funny ways of doing it). BTW, to all those that fear using the List Manager, especially in Dialogs, there is NOTHING TO IT! The List Manager has to be one of the simplest and nicest Managers in the Mac. The only problems I have have to do with the LActivate procedure and the lack of means of getting it called for a Modal Dialog (in case an Alert pops up above it). This is an esthetic problem, not a functional one. - Yossie -- Yossie Silverman What did the Caspian sea? National Semiconductor Ltd. (Israel) cyosta%taux01@nsc.nsc.COM or RPR1YOS@TECHNION.BITNET NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOLCAY ITAY
kk@mcnc.org (Krzysztof Kozminski) (08/22/89)
In article <8356@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <58078@tut.cis.ohio-state.edu> Scott Sutherland ><sas@cis.ohio-state.edu> writes: >>The problem with this is that SetDItem (which places the item in the given >>dialog's item list) pre-supposes that the item is NOT already in the list. > >No; in fact, I don't know whether you can use SetDItem to add an item >to a dialog item list. The routine description doesn't say that you can. Seems to me you can't. A couple years ago I tried to use SetDItem to add an item and got a rather spectacular crash. For adding new items to existing dialogs, it might be a good idea to grab some code from the TN that tells how to add items to Print Dialogs (note: only about 20% of the code therein is relevant). >>Luckily there is a really easy way to do this. Simply call HideDItem. > >Yes, this is true, so long as you don't care about compatibility with old >ROM machines. Few people do these days.... Don't system versions from 4.2 onward have patches for old ROMs? It seems to me that you'd have to come up with an (old ROM + ancient system) combination to have HideDItem/ShowDItem fail ... (disclaimer: I am not sure about this). >And one subjective note -- I have some aesthetic qualms about dialogs >that change their appearance. In a very few cases they make sense, and >for all I know this may be one of them. Seconded. From user's point of view it is less confusing if a dialog item gets deactivated (drawn in gray pattern) rather than disappears altogether. It is easy to do with controls (hilite them with 255), somewhat more of a problem with text items (got to deactivate them so that clicks in the item are ignored, and overdraw with grey in Bic mode. I recall also some problems I had with tab key moving the insertion point into inactive text item - if this is indeed a problem and not my false recollection, it can be fixed with a dialog filter routine). >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com KK -- "The party was a masquerade; the guests were all wearing their faces."
ech@cbnewsk.ATT.COM (ned.horvath) (08/23/89)
Someone, long ago: >>>Then I wanted to move it away. I GetDItem'ed it and SetDItem'ed it >>>to Siberia ( actually, somewhere off to the left of the screen ). >>>It did not go away. Does anyone have any idea why I can't move it >>>around like this? I also can't move it to other places on the screen. Tim Maroney: > Sure, I think the answer is pretty clear, but I'm assuming you made a > small mistake in evaluating the results of your SetDItem, Tim. The > item is getting moved. However, SetDItem does *not* do any drawing. There's a worse issue with moving TextEdit items off-screen: they stay "in the loop" for tabbing from field to field. I don't think that HideDItem fixes this issue. This is particularly disturbing to users: hit tab, start typing -- whoops, where's the cursor? Where's my text? Panic, book across room, call to tech support... DLOGs and DITLs are cheap: get prototyper, or ResEdit, and roll up as many as you need. They don't take up appreciable space in your resource file, and the code to choose the right one is cheaper than the code to make one DLOG do too many different things. Crunch all you want... =Ned Horvath=
kk@mcnc.org (Krzysztof Kozminski) (08/23/89)
In article <884@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: > >There's a worse issue with moving TextEdit items off-screen: they stay >"in the loop" for tabbing from field to field. I don't think that >HideDItem fixes this issue. This is particularly disturbing to users: hit >tab, start typing -- whoops, where's the cursor? Where's my text? Panic, >book across room, call to tech support... Sorry, not true. HideDItem does remove these items from the tabbing loop. It works correctly even if the insertion point was in the item being hidden: the vertical blinking bar moves to the next text item in the loop. In any case, the TErecord associated with the hidden item gets deactivated, so even if there are no more edit text items left, the hidden item won't receive any keyboard stuff. >DLOGs and DITLs are cheap: get prototyper, or ResEdit, and roll up as >many as you need. They don't take up appreciable space in your resource >file, and the code to choose the right one is cheaper than the code to make >one DLOG do too many different things. Crunch all you want... Yes, but switching to another dialog differing from the current one in one or two items will redraw the whole dialog window and will be be annoying. Did you really mean this or am I misreading you? Personal opinion: Graying items out seems to be most user friendly; changing the dialog box size (like old MacDraw did for custom rulers) to uncover new items goes second; hiding/showing items goes in the third position for me (even though I do use it occasionally). KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <8356@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Yes, this is true, so long as you don't care about compatibility with old >ROM machines. Few people do these days.... In article <1341@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >Don't system versions from 4.2 onward have patches for old ROMs? It seems to >me that you'd have to come up with an (old ROM + ancient system) combination >to have HideDItem/ShowDItem fail ... (disclaimer: I am not sure about this). Yes, some, but I'm not sure exactly what traps and features are patched in and which ones aren't. Inside Mac doesn't bother to say. I think one Tech Note makes a passing reference to some new traps being patched in, but I don't think it addresses HideDItem and ShowDItem specifically, and I don't remember which one it is, and I don't have the time to search through some 200 tech notes to find out. >>And one subjective note -- I have some aesthetic qualms about dialogs >>that change their appearance. In a very few cases they make sense, and >>for all I know this may be one of them. > >Seconded. From user's point of view it is less confusing if a dialog item >gets deactivated (drawn in gray pattern) rather than disappears altogether. >It is easy to do with controls (hilite them with 255), somewhat more of >a problem with text items (got to deactivate them so that clicks in the >item are ignored, and overdraw with grey in Bic mode. Deactivation is indeed a better solution, though it doesn't completely address the problem of modality. But at least it gives a clear visible indication of the modal behavior. With text edit items, you can always disable them by turning them into user items with SetDItem and binding a "draw light gray" drawing procedure, then doing an InvalRect on the item's surrounding rectangle. I don't think this causes any problems. >I recall also some >problems I had with tab key moving the insertion point into inactive text >item - if this is indeed a problem and not my false recollection, it can be >fixed with a dialog filter routine). I just checked and at least under 6.0.3 on a Mac SE, the Dialog Manager is smart enough to avoid this problem. Tabs will only take you to visible edit text fields. This doesn't mean your memory is faulty -- perhaps this used to be a problem but it was fixed, in which case those concerned about pre-6.0 systems would be well advised to do their own testing. (However, I think that as we approach 1990, it is reasonable to require Mac Plus or later ROM, one megabyte or more of memory, and System 6.0 or higher.) >KK >-- >"The party was a masquerade; the guests were all wearing their faces." Camilla: You, sir, should unmask. Stranger: Indeed? Cassilda: Indeed it's time. We all have laid aside disguise but you. Stranger: I wear no mask. Camilla: (Terrified, aside to Cassilda.) No mask? No mask! THE KING IN YELLOW: Act I -- Scene 2. (Robert W. Chambers, 1895) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Everything that gives us pleasure gives us pain to measure it by." -- The Residents, GOD IN THREE PERSONS
han@Apple.COM (Byron Han) (08/25/89)
In article <8356@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >No; in fact, I don't know whether you can use SetDItem to add an item >to a dialog item list. You cannot use SetDItem to add items to a dialog item list. There is a routine that is included with the Communications Toolbox, AppendDITL (and ShortenDITL) which allow dynamic management of dialog item lists. These routines, when the CommToolbox becomes part of System 7.0, will be included with the standard Macintosh System Software when 7.0 ships. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat Macintosh - Catch the Wave! Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------
siegel@endor.harvard.edu (Rich Siegel) (08/25/89)
In article <34286@apple.Apple.COM> han@Apple.COM (Byron Han) writes: > >There is a routine that is included with the Communications Toolbox, >AppendDITL (and ShortenDITL) which allow dynamic management of dialog >item lists. No need to wait for the Comm Toolbox. AppendDITL appears in Macintosh Technical Note #95. It's a godsend for extending the print dialogs, standard file dialog, or any other "hook-able" standard dialogs. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
isle@eleazar.dartmouth.edu (Ken Hancock) (08/25/89)
In article <2511@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <34286@apple.Apple.COM> han@Apple.COM (Byron Han) writes: >> >>There is a routine that is included with the Communications Toolbox, >>AppendDITL (and ShortenDITL) which allow dynamic management of dialog >>item lists. > > No need to wait for the Comm Toolbox. AppendDITL appears in >Macintosh Technical Note #95. It's a godsend for extending the print >dialogs, standard file dialog, or any other "hook-able" standard dialogs. > > --Rich > I have to add a little flame here on Apple's DTS job on that technote, though. Usually, DTS has been very good about including both C code as well as Pascal. I recently used AppendDITL, but had to translate it from Pascal to C which was a nightmare dealing with all the dereferenced handles and pointers and pointers to dereferenced handles. If you looking in the comments to AppendDITL, it says something to the extent of 'Originally written in C and translated to Pascal' COME ON DTS! If it was originally written in C, why didn't you at least include the C code for it as well! But all the same, thank you for a VERY handy routine... Ken Ken Hancock '90 | E-mail: (BITNET/UUCP/INTERNET) Computer Resource Center Consultant | isle@eleazar.dartmouth.edu -------------------------------------+-------------------------------------- DISCLAIMER? I don't get paid enough to worry about disclaimers.
han@Apple.COM (Byron Han) (08/27/89)
In article <2511@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <34286@apple.Apple.COM> han@Apple.COM (Byron Han) writes: >> >>There is a routine that is included with the Communications Toolbox, >>AppendDITL (and ShortenDITL) which allow dynamic management of dialog >>item lists. > > No need to wait for the Comm Toolbox. AppendDITL appears in >Macintosh Technical Note #95. Actually, the dialog item list appending routine that appears in TN 95 does not cover all cases properly. For example, it does not handle resControls properly, does not support color icons, nor does it handle the case of adding text edit items to dialogs in a general fashion. The CommToolbox version of AppendDITL handles all of these cases correctly in addition to allowing the developer to append dialog item lists relative to the topLeft of the existing dialog, topRight of the existing dialog, or botLeft of the existing dialog. Or the topLeft of an item in the preexisting dialog item list. So, yes indeed you should migrate to use the CommToolbox/7.0 version. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat Macintosh - Catch the Wave! Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------
jeremyr@cs.qmc.ac.uk (Jeremy Roussak) (08/28/89)
>Graying items out seems to be most user friendly; changing the dialog box >size (like old MacDraw did for custom rulers) to uncover new items goes >second; hiding/showing items goes in the third position for me (even though >I do use it occasionally). > >KK >-- >Kris Kozminski kk@mcnc.org >"The party was a masquerade; the guests were all wearing their faces." I also think that greying out irrelevant items is the most user-friendly way to approach the problem. However, it seems to generate a problem of its own when applied to editText items: simply greying it out doesn't appear to stop the user typing into it, since it doesn't remove it from the "tabbing rota". Mind you, I could be missing something: I grey out by overpainting with a mid-grey (as someone recommended not a long time ago), so I don't use any system calls. Should I? Jeremy Roussak