dweisman@umiami.ir.miami.edu (Ordinary Man) (05/16/91)
Is it safe/recommended to draw to a dialog window as if it was a window? I mean I have no userItems in my dialog; I just set the port to the dialog after I create it and draw all sorts of things in it as if it was a window. No problems. I even utilize the ModalDialog's filter function to do some realtime animation in the dialog. No problems still. Is this bad? Also then, what are userItem's good for then? Why not just draw everything straight to the port? (naive question, I know, but just want to get everything out in the open). Thanks, Dan /-------------------------------------------------------------------------\ | Dan Weisman - University of Miami - Florida | || || || || | |--------------------------------------------------| || || ||\ /|| | | INTERNET -----> dweisman@umiami.IR.Miami.edu | || || || | || | | BITNET -----> dweisman@umiami | ||||||| || | || | |-------------------------------------------------------------------------| | "The more I get to see, the less I understand..." - Triumph | \_________________________________________________________________________/
hawley@adobe.COM (Steve Hawley) (05/16/91)
In article <1991May15.131300.9898@umiami.ir.miami.edu> dweisman@umiami.ir.miami.edu (Ordinary Man) writes: > Is it safe/recommended to draw to a dialog window as if it was a window? I can think of no reason why it would not be safe to draw into a dialog window as if it were a window. I would not recommend it. Think about the roots of the Dialog Manager, it is a package designed to group a small set of controls into fairly simple data structure and provide a simple mechanism for bringing up the window that will be used only for a short time, generally to present a message or query the user. This is ideal for things like confirmation boxes ('Do you want to save changes to "Threatening Letter to Grandma"?'), simple font selection, or search/replace boxes. The idea is that you as the programmer accept the fact that the Dialog Box need not worry about absolutely every detail that you handle in your main event loop, and as such, you relinquish event handling to the Dialog Box for the transitory time it will be exciting the phsphors on your screen. When you start hacking your searc/replace dialong to have an option to also provide a keen interface to an online dictionary to define the word you're looking for, or perhaps first look it up in a synonymicon (that's another word for thesaurus, by the way) and give you a pop up control that has a custom doo-dad to let you select from the list of synonyms and do poke-and-drag selection of an appropriate context-sensitive boolean search criteria, you should begin to wonder if you should be using a Dialog Box. Really, the only thing a Dialog Box does is tie together CNTL and WIND resources for you, and do some event handling. When your Dialog Box starts getting out of hand, you should do this yourself. >after I create it and draw all sorts of things in it as if it was a window. No >problems. I even utilize the ModalDialog's filter function to do some realtime >animation in the dialog. No problems still. Is this bad? Also then, what are >userItem's good for then? Why not just draw everything straight to the port? From your description, I think you're better off using a WIND, a set of CNTL's and your own event loop. Steve Hawley hawley@adobe.com -- "Did you know that a cow was *MURDERED* to make that jacket?" "Yes. I didn't think there were any witnesses, so I guess I'll have to kill you too." -Jake Johansen
sdd (Steve Dakin) (05/17/91)
In article <1991May15.131300.9898@umiami.ir.miami.edu> dweisman@umiami.ir.miami.edu (Ordinary Man) writes: > > Is it safe/recommended to draw to a dialog window as if it was a window? > I mean I have no userItems in my dialog; I just set the port to the dialog > after I create it and draw all sorts of things in it as if it was a window. > No problems. I even utilize the ModalDialog's filter function to do some > realtime > animation in the dialog. No problems still. Is this bad? Also then, what are > userItem's good for then? Why not just draw everything straight to the port? > (naive question, I know, but just want to get everything out in the open). > I do this all the time. The only drawback (I have found) is those durn update events. I use a filter proc to handle all the updates. In order to handle the high volume of dialogs that I use and all the drawing that is associated with each one, I wrote a function whose primary purpose is to draw the graphics (lines, etc.) for each dialog box. Inside the filter proc I use, under the updateEvt event, I call this routine to have the text drawn. It's a little bit of a kludge, but it works quite well and I only have to use one filter proc and manage one routine for all the drawing (yes, this routine does get quite large after a while, but only a small portion of it is executed each time through). User Items didn't provide enough functionality for what I wanted so I went for this method instead. Woul someone who is more familiar with User Items want to expand on them? -- +-----------------------------------+ | Steve Dakin | | oceania!sdd@uunet.uu.net | | (NeXT mail) | | tread lighty so others may follow | +-----------------------------------+ -- +-----------------------------------+ | Steve Dakin | | oceania!sdd@uunet.uu.net | | (NeXT mail) |
osborn@ux1.lbl.gov (James R Osborn) (05/17/91)
I have gotten some flack for liking the Dialog Manager and more specifically liking to abuse it! I find that it is much easier to install a userItem to do updating for specific drawing tasks than using a filter procedure and doing the updating myself. I like this because usually you don't need to write a filter proc. So why add one just to do updating in a dialog when a mechanism (the userItem) is provided for you? Another nice thing is that you can reuse the same userItem procedure for a series of different items. Just use a switch inside the draw procedure to select which item to draw. And you can use the same draw procedure to draw the same item all over your dialog. You just set the rectangle different for each item, then in your draw procedure, you retrieve the item rectangle for the item you are drawing (using GetDItem). One other interesting thing. If you use a dialog (instead of a window) that has userItem(s) installed to do your updating, then your window will get updated *BEHIND* a modal dialog that you put up. Try this: 1) go to the finder 2) make sure a folder or disk window is open 3) go to the File menu and choose Page Setup... 4) You get a modal dialog in front of the Finder's windows 5) Now activate your favorite screen saver so that the entire screen goes black or whatever causing the screen to need updating You will notice that the modal dialog will update since it's internal event loop is in control. The Finder's windows (which presumably are not dialog windows) do not get updated until you Cancel/OK out of the modal dialog. This is annoying. For example when printing a long document in the foreground. A modal print dialog comes up and tells you the status. If your screen saver kicks in, then when the screen is redrawn, any documents you have open won't update until you finish printing. If a modeless dialog was used for the document window with userItems to cause text updating, then the documents would be updated properly by the dialog manager. I think this is real neat. It keeps your screen looking good after a screen saver has erased everything. Unfortunately, I think using the dialog manager to do all event processing for an application's documents is considered dialog manager abuse (by the powers that be). Sorry for all the hot air :^o -- james |-----------------------------------------------------------------------| | James R. Osborn | It just goes to show you it's always | | Lawrence Berkeley Laboratory | something. Either it's incorrect tech | | osborn@ux1.lbl.gov | notes or your mac is smoking. It's | | (415) 548-8464 | always something... | |-----------------------------------------------------------------------|
CXT105@psuvm.psu.edu (Christopher Tate) (05/17/91)
The cool thing about userItem's is that once you set them up (by telling the Dialog Manager which procedure to call to draw them) you can just forget about them completely. The Manager will automatically call your procedures if it becomes necessary to update the contents of the dialog (for example, if a screen saver has erased it). This is the recommended way of doing the bold outline around the default button, in fact. You create a userItem that's four pixels bigger than the button in every direction, then use the simple FrameRoundRect() stuff in a userItem procedure to actually draw it. From then on, you don't have to worry about it. Also, the same userItem procedure can be used by more than one dialog, whereas multiple dialogs may not be able to (easily) share the same filterProc. ------- Christopher Tate | etaT rehpotsirhC Bitnet: cxt105@psuvm | mvusp@501txc :tentiB Uucp: ...!psuvax1!psuvm.bitnet!cxt105 | 501txc!tentib.mvusp!1xavusp!... :pcuU Internet: cxt105@psuvm.psu.edu | ude.usp.mvusp@501txc :tenretnI
dweisman@umiami.ir.miami.edu (Ordinary Man) (05/17/91)
In article <13295@dog.ee.lbl.gov>, osborn@ux1.lbl.gov (James R Osborn) writes: > I have gotten some flack for liking the Dialog Manager and more > specifically liking to abuse it! I find that it is much easier > to install a userItem to do updating for specific drawing tasks > than using a filter procedure and doing the updating myself. > > I like this because usually you don't need to write a filter proc. I agree. But what if one of your "userItems" is to be animated, in other words, what if you need it to be updated everytime through ModalDialog's event loop. Then you'd have to use the filter function. And if you're gonna use it anyway, you might as well draw the other items when you get an update event from the filter function. This updates all items even through a screen saver. > Sorry for all the hot air :^o Up, up, and away! :-> > -- james Dan /-------------------------------------------------------------------------\ | Dan Weisman - University of Miami - Florida | || || || || | |--------------------------------------------------| || || ||\ /|| | | INTERNET -----> dweisman@umiami.IR.Miami.edu | || || || | || | | BITNET -----> dweisman@umiami | ||||||| || | || | |-------------------------------------------------------------------------| | "...the fact is- this friction will only be worn by persistance." -RUSH | \_________________________________________________________________________/
lim@iris.ucdavis.edu (Lloyd Lim) (05/17/91)
In article <1991May16.161520.9948@umiami.ir.miami.edu> dweisman@umiami.ir.miami.edu (Ordinary Man) writes: >In article <13295@dog.ee.lbl.gov>, osborn@ux1.lbl.gov (James R Osborn) writes: >> [...] I find that it is much easier >> to install a userItem to do updating for specific drawing tasks >> than using a filter procedure and doing the updating myself. >> >> I like this because usually you don't need to write a filter proc. > >I agree. But what if one of your "userItems" is to be animated, in other words, >what if you need it to be updated everytime through ModalDialog's event loop. >Then you'd have to use the filter function. And if you're gonna use it anyway, >you might as well draw the other items when you get an update event from the >filter function. This updates all items even through a screen saver. If your dialog has things that are animated (like a progress bar, say), then it's probably a better idea to use IsDialogEvent and DialogSelect than to use ModalDialog. This gives you more flexibility both in the processing you can do in your own program and in background processing. To animate your items, you can just call the userItem procedures directly. In general, userItems are more reusable than filterProcs. Toolbox Karma actually works! :-) +++ Lloyd Lim Internet: lim@iris.eecs.ucdavis.edu America Online: LimUnltd Compuserve: 72647,660 US Mail: 215 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
stevec@Apple.COM (Steve Christensen) (05/17/91)
dweisman@umiami.ir.miami.edu (Ordinary Man) writes: > > Is it safe/recommended to draw to a dialog window as if it was a window? >I mean I have no userItems in my dialog; I just set the port to the dialog >after I create it and draw all sorts of things in it as if it was a window. No >problems. I even utilize the ModalDialog's filter function to do some realtime >animation in the dialog. No problems still. Is this bad? Also then, what are >userItem's good for then? Why not just draw everything straight to the port? >(naive question, I know, but just want to get everything out in the open). A dialog window is basically a window, so you can draw into it the same as any other window. The only difference is that because it has an associated item list, various things (like text, pictures, icons, etc.), are automatically drawn in the window for you without your application having to know anything about them. This is very handy for translation into other languages, and for making little changes to the look of a dialog without having to re-write a bunch of code. So why bother with all the "hassle" of userItems, etc., to specify where stuff is drawn? Well, if the dialog needs to be rearranged for, say, translation to another language, you can quickly move the items around with ResEdit instead of having to make changes to your code. Just use the item's bounding rectangle and scale your drawing if possible and/or appropriate... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen Never hit a man with glasses. stevec@apple.com Hit him with a baseball bat.
stevec@Apple.COM (Steve Christensen) (05/17/91)
In article <1991May16.170121.7022@oceania.UUCP> writes: >[...on the subject of dialog windows and userItems...] >I do this all the time. The only drawback (I have found) is those durn >update events. I use a filter proc to handle all the updates. In order to >handle the high volume of dialogs that I use and all the drawing that is >associated with each one, I wrote a function whose primary purpose is to draw >the graphics (lines, etc.) for each dialog box. Inside the filter proc I use, >under the updateEvt event, I call this routine to have the text drawn. It's a >little bit of a kludge, but it works quite well and I only have to use one >filter proc and manage one routine for all the drawing (yes, this routine does >get quite large after a while, but only a small portion of it is executed each >time thru). User Items didn't provide enough functionality for what I wanted >so I went for this method instead. > >Woul someone who is more familiar with User Items want to expand on them? All userItems provide is a hook so that any non-standard drawing (i.e., non text, picture, icon, button) can be handled "automatically" without having to do the kind of special case checking you're doing in your filterProc. All static drawing (lines, boxes, ...) can be handled this way. For instance, to draw boxes and lines, I use something like this: pascal void DrawBox(theDialog, theItem) DialogPtr theDialog; short theItem; { Rect theRect; GetDRect(theDialog, theItem, &theRect); FrameRect(&theRect); }; After it's "installed" with SetDItem(), I don't worry about it anymore. If the bounds grows or shrinks, it doesn't matter. You could even do simple animation this way by having the drawing procedure keep track of its current state instead of a higher-level entity. I've come to the point now where I very rarely use a window, but instead set everything up with dialogs (and userItems for all the weird stuff)... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen Never hit a man with glasses. stevec@apple.com Hit him with a baseball bat.
osborn@ux1.lbl.gov (James R Osborn) (05/17/91)
In article <52986@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >In article <1991May16.170121.7022@oceania.UUCP> writes: > > [stuff deleted] > >I've come to the point now where I >very rarely use a window, but instead set everything up with dialogs (and >userItems for all the weird stuff)... > >steve > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Steve Christensen Never hit a man with glasses. > stevec@apple.com Hit him with a baseball bat. Wait a minute! Is this an indication (from the powers that be) that dialog manager abuse is ok? I'm not alone? I have gotten to the point of using dialogs for everything myself. Very rarely do I have a problem coaxing the dialog manager into doing what I want - no matter how bizarre that might be. -- James |-----------------------------------------------------------------------| | James R. Osborn | It just goes to show you it's always | | Lawrence Berkeley Laboratory | something. Either it's incorrect tech | | osborn@ux1.lbl.gov | notes or your mac is smoking. It's | | (415) 548-8464 | always something... | |-----------------------------------------------------------------------|