Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Moving a Textedit field in a modal dialog Message-ID: <8356@hoptoad.uucp> Date: 21 Aug 89 22:13:45 GMT References: <15088@dartvax.Dartmouth.EDU> <21428@cup.portal.com> <58078@tut.cis.ohio-state.edu> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 94 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 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