======================================================================= Archived Messages: "Dialog Manager" America Online Apple II Developers Forum. Go Keyword ADV! (C) 1992. ===================================================================jrm= This topic is for the discussion of the Apple IIGS Dialog Manager (tool set #21). Type: Response From: A2Pro Tim Date: 88-04-24 03:00:25 EST 88-04-24 03:00:25 EST CC: SYSOP jim Re: filterProc example needed... I need to see an actual example of a filter procedure for use with a modal dialog. I'm trying to use a dialog box with three buttons and I need to determine which one was clicked in by the user. Example source code in C or Pascal would be appreciated... Tim S. Type: Response From: ScottG25 Date: 88-04-24 09:56:04 EST 88-04-24 09:56:04 EST CC: SYSOP jim Re: Re: Dialog Manager I'll vote for an example, too!! Type: Response From: AIIDTS Date: 88-04-24 12:05:33 EST 88-04-24 12:05:33 EST CC: SYSOP jim Re: Re: Dialog Manager I just found a great filter proc example. It is in Gary Little's exploring the IIgs book, on page 302. Sorry to say that it is in assebly, but you might still be able to use it as a guide. Jim Type: Response From: A2Pro Tim Date: 88-04-24 20:04:36 EST 88-04-24 20:04:36 EST CC: SYSOP jim Re: Re: filterProc example... Jim, Thanks! I've nearly got it figured out anyways, but I am POSITIVE that your suggestion will help. Once I get it working, I'll make it into an example and post it somewhere... Tim S. Type: Response From: AFL Doug Date: 88-10-08 19:58:45 EST Re: Re: Dialog Manager Does anyone have an example of code for a Modeless dialog? I can't get mine to display? I don't get any errors and I think I have it right, but it won't show. Any help? Doug Type: Response From: AFL Jim Date: 88-10-09 00:32:15 EST Re: Re: Dialog Manager Doug, How about showing us what you did and then we'll debug it... Jim Type: Response From: ScottG25 Date: 88-10-09 09:25:57 EST Re: Re: Dialog Manager Gary Little's book, "Exploring the Apple IIgs" has a nice simple example of Modeless Dialogs. He also shows how to handle "Modeless Events". Type: Response From: AFL Jim Date: 88-10-09 19:31:23 EST Re: Re: Dialog Manager Thanks for noting that, Scott. I was looking for the right book last night and didn't notice that. Jim Type: Response From: AFL Doug Date: 88-10-10 20:50:56 EST Re: Re: Dialog Manager Ok, I will list the code here later tonight(after my forum). It is in C. I have Gary's book so I will look at that(I think it is the only book I haven't looked at!!! grrr.) Doug Type: Response From: AFL Doug Date: 88-10-11 19:53:10 EST Re: Re: Dialog Manager Ok, here is the offending code for the Modeless dialog GraphPortPtr commanddialog; commanddialog = NewModelessDialog(&dialogRect,"Command",-1,FRAME, Null,0,0,200,320); NewDItem(commanddialog,2,&buttonRect1,radioItem,moveStr,0,0,Null); etc, etc. All the variables are defined fine for a modal dialog(I have changed the NewModeless command to a Modal command and the modal dialog works fine). This code compiles without error, and runs without error. It just never shows the dialog on the screen! I looked at the code in gary's book and it is just like what I am doing as far as I can tell. any ideas? Doug Type: Response From: Dave Lyons Date: 88-10-11 20:05:15 EST Re: NewModeless Dialog from C Gee, hate to tell you this, but it looks like MOST of the NewModelessDailog parameters have something wrong with them! >commanddialog = NewModelessDialog(&dialogRect,"Command", > -1,FRAME,Null,0,0,200,320); "Command" should be "\pCommand" (a Pascal style string). The -1 should be -1L (a long (4-byte) value). Finally, those last 4 parameters are supposed to be one pointer to a rectangle (you're passing the whole rect instead of a pointer to it). Your NewDItem call looks fine, though. (Under C, your program will compile no matter *what* parameters you pass...the compiler couldn't care less.) I hope that helps! (I'm sure it will.) --Dave Type: Response From: ScottG25 Date: 88-10-11 21:57:04 EST Re: Re: Dialog Manager RE: Gary Little's book.. Page 285 has an error in the sample code for _NewModelessDialog... both PLA's should be PHA's...This is the 2nd and 3rd lines from the bottom of the page.. RE: C example..Good job, Dave! Page 221 of Morgan Davis and Dan Gookin's book "Advanced Programming Techniques for the Apple IIgs Toolbox" has a short example of the coding necessary, too--In C. Type: Response From: AFL Doug Date: 88-10-15 14:22:22 EST Re: Re: Dialog Manager Well, with the changes to the NewModelessDialog call my modeless dialog now appears. Thanks for all the suggestions and help. But, none of the items will appear in the dialog. i have even copied items that worked in modal dialogs and they don't appear. what am I doing wrong? I am using the NewDItem call(as shown in my previous plea for help :) Doug Type: Response From: AFL Doug Date: 88-10-15 14:40:49 EST Re: Re: Dialog Manager Here is the code that creates the Modeless dialog but none of the dialog items appear. static char moveStr [] = "\p MOVE "; Rect moveRect = {40,5,0,0}; static char chargeStr [] = "\p CHARGE "; Rect chargeRect = {55,5,0,0}; static char patrolStr [] = "\p PATROL "; Rect patrolRect = {70,5,0,0}; static char retreatStr [] = "\pRETREAT"; Rect retreatRect = {85,5,0,0}; static char defendStr [] = "\p DEFEND "; Rect defendRect = {100,5,0,0}; Rect facingRect = {140,10,0,0}; static char facingStr [] = "\p FACING "; Rect formationRect = {120,10,0,0}; static char formationStr [] = "\pFORMATION"; Rect cRect = {30,205,178,314}; show_command_dialog(x) unsigned int x; { int quit; Word choice,itemHit; GrafPortPtr commanddialog; c2pstr(commandText); commanddialog=NewModelessDialog(&cRect,"\pCommand",-1L,FRAME,0L,&cRect); NewDItem (commanddialog,1,&moveRect,radioItem,moveStr,0,2,NULL); NewDItem (commanddialog,2,&chargeRect,radioItem,chargeStr,0,2,NULL); NewDItem (commanddialog,3,&patrolRect,radioItem,patrolStr,0,2,NULL); NewDItem (commanddialog,4,&retreatRect,radioItem,retreatStr,0,2,NULL); NewDItem (commanddialog,5,&defendRect,radioItem,defendStr,0,2,NULL); NewDItem (commanddialog,6,&facingRect,buttonItem,facingStr,0,0,NULL); NewDItem (commanddialog,7,&formationRect,buttonItem,formationStr,0,0,NULL); while(quit == TRUE){ TaskMaster(0xFFFF,&TheEvent); if (IsDialogEvent(&TheEvent)){ CloseDialog(commanddialog); quit = FALSE; } } } Any Ideas what I am doing wrong? Doug Type: Response From: Dave Lyons Date: 88-10-16 00:28:51 EST Re: DialogSelect, etc. Doug, the problems are in your TaskMaster/IsDialogEvent loop. (Why you repeat until quit is FALSE baffles me, but that isn't a problem...makes sense if you call the var notQuit). Anyway, the items in your modeless dialog won't get processed until you allow DialogSelect to handle events that IsDialogEvent returns true for. The most important one is Update--DialogSelect never gets to handle an update event for your modeless dialog, so the dialog items are never drawn. By the way, that piece of code doesn't look like your program's main event loop. The idea of a MODELESS dialog is that you're not in any special mode--your main loop should continue as before--menus should be usable, other windows should still work, etc. --Dave L Type: Response From: AFL Doug Date: 88-10-16 14:12:57 EST Re: Re: Dialog Manager Thanks for the idea of what is wrong. This code comes from a game that has several different 'modes'. Each mode has its own event loop (games of course can't fit the normal setup). This eventloop however hasn't been added as I have to get the dialog working before I can do anything with the events. :) I will let you know how my floundering around goes! Doug Type: Response From: AFL Doug Date: 88-10-16 15:11:42 EST Re: Re: Dialog Manager Ok, I made the changes (at least I think I did) and still nothing is displayed. Why do you say that the buttons aren't displayed until dialogselect is called? How is that going to be selected until the user selects a button, and if they can't see the buttons how are they going to select? The dialog has to be displayed before any event can happen? But, I changed it like you said and still nothing is displayed(the window opens correctly but the radio buttons are never shown). Maybe you should spell it you for me (list the code), I don't seem to be able to get a handle(no pun intended) on these modeless dialogs. Doug Type: Response From: AFL Doug Date: 88-10-16 20:01:12 EST Re: Re: Dialog Manager After rereading all this I still don't have a solution, but I would like to explain why I am using another event loop. In the context of the game this is for there are several windows open. when the main loop is being processed the game proceeds normally. However, when a player stops play to give commands the game halts( so there is no use to process the main eventloop since nothing is allowed to happen). However, to give the commands the player must at times click in the various windows. A Modal dialog won't work because the user can only click in the Modal dialog box(which would preclude the user being able to click in other windows). So I am trying to use a Modeless dialog and a separate event loop. Once the player finishes giving command the program returns to the main event loop and the game continues. Does that answer your question as to why I am processing it this way? Doug Type: Response From: Dave Lyons Date: 88-10-16 23:26:54 EST Re: Re: Dialog Manager Hmmm...seems like it would be simpler to just have the one main event loop and keep a flag to say what sorts of things are allowed to happen...otherwise it seems like you'll be duplicating a lot of effort for things that can happen in *both* cases (like menu choices?). Anyway, DialogSelect may not be a good name for the tool, leading to some confusion. HandleModelessDialogEvent would explain it better, I think. You're supposed to call DialogSelect with any event that IsDialogEvent returns TRUE for; these events will include things like MouseDown in a modeless dialog window *and* things like Update events for that window. The items in your modeless dialog will be *drawn by* DialogSelect if you call it appropriately when IsDialogEvent says to. It will also take care of enabling/disabling items when Activate events come through for your modelss dlg window. See page 6-39 of Toolbox Ref vol I. The code to call it looks something like this (untested): event = TaskMaster(-1,&event); if(IsDialogEvent(&event)) if(DialogSelect(&event,&dlg,&item)) { /* handle item "item" hit in dialog "dlg" */ } /* go ahead and handle other events here */ Type: Response From: AFL Doug Date: 88-10-17 16:55:00 EST Re: Re: Dialog Manager Thanks for the code, I will let you know how it goes. About the two event loops. If there were ever items that were executed in *BOTH* then I would agree with you. But, believe it or not, NO action is duplicated(not even menu items). The two modes are completely distinct parts. And also, I am straining for every ounce of speed I can squeeze out of this. Every Extra part that I add to the game loop(the loop that is not this dialog loop) slows the game down more. Does this make sense? Doug Type: Response From: AFL Doug Date: 88-10-21 20:07:04 EST Re: Re: Dialog Manager Here is the solution to the problem. Thanks to all for their help. Subj: Modeless problem solved 88-10-18 00:31:42 EDT To: AFL Doug From: AFL Floyd GrafPortPtr theDialogPtr; while(!done){ TaskMaster(0xFFFF,&TheEvent); if (IsDialogEvent(&TheEvent)) if(DialogSelect(&TheEvent, theDialogPtr, &itemHit)) CloseDialog(theDialogPtr); } Note the addition of "theDialogPtr". Since DialogSelect returns a pointer in the second parm, if you use your original (commandDialog) as the pram it will be overwritten with what ever other DialogPtr that the event is in. Secondly, notice the & in front of itemHit. The proper parm is a pointer, not a value. Oh, the above code will close the Dialog for *any* dialog event. You would need to use a switch statement in actual use for handling the different item events. Floyd Type: Response From: Dave Lyons Date: 88-10-21 20:57:33 EST Re: Re: Dialog Manager Doug, you need an "&" in front of that theDialogPtr parameter, too! That parameter tells DialogSelect where to store a pointer to the dialog that it determines the event applies to. (In other words, it's parallel to the itemHit parameter.) Clarification--by "dialog event" Floyd means clicking on some item in a dialog; this is a different meaning from what IsDialogEvent returns true for. IsDialogEvent returns true not only for mouse-down events in a dialog, but also for Update events, etc. When DialogSelect gets fed an Update event or something else similar, it *does* stuff (like redrawing the dialog items), and then it returns FALSE (meaning that no further action needs to be taken by your program). --Dave L Type: Response From: AFL Floyd Date: 88-10-28 07:43:18 EST Re: Re: Dialog Manager Dave, The missing '&' in front of the dialog pointer was a typo (I mentioned it to Doug). :) You know what I meant about the dialog events. This was just a *short* example, I didn't try to explain the entire dialog mgr. ;) Floyd Type: Response From: Don87 Date: 88-11-01 22:36:11 EST Re: Re: Dialog Manager Hi, Here's another question for you all that is probably very simple. I can't figure out why my program won't save the settings of my radio buttons after I close my modal dialog box. They highlight and unhilight just fine but when I close the box and return to it during program execution they are back in their default settings. What I'm using is almost a carbon copy of TML's example program called 'GSDemo' in the procedures PushRadioButtons and DoModalDialog. Thanks for all your help so far. Don Mocarski. Type: Response From: Dave Lyons Date: 88-11-02 00:51:53 EST Re: Re: Dialog Manager Maybe I'm misunderstanding the question, but it seems obvious: if you're actually _closing_ the dialog with CloseDialog, then when you recreate the thing later with NewMode[al,less]Dialog you're starting fresh, and you'll have to use SteDItemValue on your radio buttons again to select the one you want. Does that help? --Dave Lyons Type: Response From: AFL Jim Date: 88-11-02 09:50:07 EST Re: Re: Dialog Manager Don, You should make sure you're using global variables for the default values in your dialog. Local variables within a procedure or function are destroyed when that procedure or function ends. Jim Type: Response From: Don87 Date: 88-11-02 19:14:24 EST Re: Re: Dialog Manager Dave and Jim, Thanks again to you both. I keep using local variables and reassigning them to the default values each time I call a procedure. It's a nasty habit I have. It's funny that I did the right thing for the line edit items and not for the radio buttons. Two more questions ... I have six line edit items each of which is no longer than three characters long. When I press the tab button I'd like the program to select them in the order of their item ID numbers. The program doesn't seem to do that on it's own. Any ideas on what I'm doing wrong? Secondly I'd like the program to refuse input in these line edit items that is out of a specified range. Is that what a filter procedure is for? Thanks again. Don Mocarski Type: Response From: Dave Lyons Date: 88-11-02 20:13:14 EST Re: Re: Dialog Manager The order in which Tab moves through your line edit items depends on the order they were added to the dialog (with NewDItem, for example) rather than on their ID numbers. Mainly out of laziness, I've never tried restricting the contents of a line edit item--but Yes, that's what a filter proc is for Type: Response From: Don87 Date: 88-11-03 19:47:17 EST Re: Re: Dialog Manager Thanks again Dave. Don Mocarski Type: Response From: AFL Jim Date: 88-11-04 15:40:52 EST Re: Re: Dialog Manager Oooops... Wrong button :) I had to grab this one quick from the bit bucket before it was emptied. --Jim Subj: Re: Dialog Manager 88-11-04 06:34:29 est From: SkipS Has anyone had much success using a scroll bar in a dialog box? I've tried using the TML examples but the examples don't really do anything except display a scroll bar. When I try to assign global values to a variable and keep them in sync with the scroll bar I get random values as a result. The IIgs Reference even says it doesn't recommend using a certain call that is shown in the demo. The call 'GetControlDItem' seems to be the problem. Is there a way around the problem with this call. Thanks for any help. Skip Type: Response From: ScottG25 Date: 88-11-04 18:57:40 EST Re: Re: Dialog Manager Skip, I don't know much about TML Pascal, tho I've used _GetControlDItem in a dialog, on a scrollbar from assembly language with out any ill effects. Depending on what you want to do with the Scrollbar, it may be better to use a Scrollbar Action procedure. The scrollbar action procedure's pointer is contained in the item's template at the itemDescr offset if you're using GetNewDItem or GetNewModalDialog. If Mike Westerfields "Vaccine" source is in the libraries, it has a scrollbar action procedure in Orca/Pascal - it should be pretty close to a TML counterpart. I hope this helps. Scott Type: Response From: Dave Lyons Date: 88-11-04 22:34:49 EST Re: Re: Dialog Manager Skip, I don't know why GetControlDItem would be a problem, unless you're fiddling with control attributes that the Dialog Mgr doesn't want you to fiddle with. I've used it before. The only trick to using Global Varaibles inside a proc that gets called by the system is to put {$LongGlobals+} before any procedure that will get executed during a call to your program from the toolbox. The easiest thing (but not the most efficient) is to just put {$LongGlobals+} at the beginning of each UNIT--that's what I did in DIcEd (which is writ all in TML Pascal standalone, by the way!). --Dave Lyons Type: Response From: TMH2 Date: 88-12-17 00:15:34 EST Re: Re: Dialog Manager Is this a bug in my application, or in TaskMaster or DialogManager?: Take a modeless dialog, with a button currently at GLOBAL coordinate (100,100). Place the mouse at GLOBAL (80,100) (in the drag region, above the button) and drag the dialog until the button is at global (80,100) THE POINT AT WHICH THE MOUSE WAS PRESSED TO DRAG THE DIALOG (<--key point). Drop the window there. In my application, the button SELECTS, as if it was pressed. The modeless dialog works fine except for this. What gives??? Z^\GGGGGGGGGGGGGGGGGGG\_ Z R Z T. Mike Howeth II N Z Dallas, Texas N Z (TMH2) V Z B Q ZO WVWVWVWVWVWVWVWVP_ Type: Response From: Dave Lyons Date: 88-12-17 01:27:12 EST Re: phantom dialog events w/ drag Hey, DIcEd used to behave exactly the same way, TMH...the icon-list windows are modeless dialogs. I eventually pretty much figured out what was going on and found a way to stop, and I'll let you know what it was as soon as I dig up my source code & check! Type: Response From: Dave Lyons Date: 88-12-17 02:30:33 EST Re: killing phantom dialog events It turns out to be simpler than I remembered, if I'm piecing this together correctly. The trick is not to call IsDialogEvent/DislogSelect if TaskMaster returns 0. I think if you omit that test and call IDE/DS anyway, it claims the MouseUp event left over from dragging, and for some reason, for me anyway, it was Blinking a button in my dialog without actually taking any action (DS was returning zero, I guess). code := TaskMaster(-1, Event); if code<>0 then if IsDialogEvent(Event) then if DialogSelect(Event,dlog,ditem) then HandleDlog(dlog,ditem); case code of... --Dave Type: Response From: TMH2 Date: 88-12-18 01:59:19 EST Re: Re: Dialog Manager BUT doesn't that cause LineEdit items to behave incorrectly? The refman says the cursor won't behave if you don't call IDE/DS regularly. This definately sounds like a BIG, HAIRY ROACH of a bug... Z^\GGGGGGGGGGGGGGGGGGG\_ Z R Z T. Mike Howeth II N Z Dallas, Texas N Z (TMH2) V Z B Q ZO WVWVWVWVWVWVWVWVP_ Type: Response From: Dave Lyons Date: 88-12-18 11:06:32 EST Re: phantom hilitings Yes, I think not calling IDE/DS when TaskMaster returns 0 will make the insertion points in any LineEdit items in modeless dialogs fail to blink. DIcEd doesn't have any LE items in the modeless dialogs; if it did, I'd try a more complicated test, like omitting the IDE/DS calls only if TaskMaster returned 0 and the Event.what was mouseUp. Type: Response From: TMH2 Date: 88-12-20 00:24:35 EST Re: Re: Dialog Manager Well, this code is going into a program generator that I use to write the base code for desktop apps, so I'll go to that extra trouble, since I need to account for the situation. Thanks. Z^\GGGGGGGGGGGGGGGGGGG\_ Z R Z T. Mike Howeth II N Z Dallas, Texas N Z (TMH2) V Z B Q ZO WVWVWVWVWVWVWVWVP_ Type: Response From: Dave Lyons Date: 89-01-17 23:52:33 EST Re: How to write a modal FilterProc? (forwarded from duplicate folder) Subj: Dialog Manager 89-01-17 23:38:55 est From: Clayburn HELP!... I am writing a IIgs program. This is my first effort at a IIgs program and there are still a lot of things that I don't understand. What I need help with right now is dialog boxes. ModalDialog has a pointer for a filter procedure. What I would like to do is cause the cancel button to be activated with <.> press. But I don't understand what the filter procedure is supposed to do and how it is supposed to be contructed. I have the Apple toolbox reference manuals and it tells me certain parameters must be used, but I can't see what they mean. I would greatly appreciate an solution to my problem. Clay Type: Response From: Dave Lyons Date: 89-01-17 23:54:19 EST Re: how to write a modal FilterProc Clay, I've never done it myself, but that's a perfectly reasonable thing to do, and I'll see if I can figure out what you need to do from the docs. By the way, what language are you writing in? Your FilterProc receives 3 parameters and returns one value. The return parameter being nonzero tells the dialog manager that no further action is needed for the event that occured. Let's call the 3 parameters theDialogPtr, eventPtr, and itemHitPtr (as on page 6-25 of Toolbox Ref, vol I). To have Apple-. work like your Cancel button, you'll want to check for the following conditions, and just return 0 if they aren't met. The "what" field of the event is keyDown or autoKey; the low word of the "message" field of the event is $2e (period); and the appleKey bit of the "modifiers" field of the event is set. So if you find Apple-. has been hit, then you store the code for your Cancel button whereever itemHitPtr points, and then you return zero (like before). I think if you want the Cancel button to actually blink, you'll need to use GetCtlDItem (using theDialogPtr and the button's item number) to get the button control's handle (let's call it CancelBtn), and call HiliteControl(255,CancelBtn) followed by HiliteControl(0,CancelBtn). --Dave Lyons Type: Response From: Dave Lyons Date: 89-01-18 00:30:42 EST Re: HiliteControl (oops!) Silly me...in the previous message I should have said that you "blink" a control by using HiliteControl(1,ctrlHandle) followed by HiliteControl(0,ctrlHandle). I used 255 instead of 1; 255 is used to make a control _inactive_, not to hilite it. --Dave Type: Response From: Clayburn Date: 89-01-18 20:24:51 EST Re: Re: Dialog Manager Dave, I am writing in assembly language. Using Merlin 8/16. Are you saying when my filter procedure is called the three parameters have already been pushed onto the stack. And when my procedure finishes it needs to push a value onto the stack. If not explain more. Thanks a bunch for the information. If you would like to know I am trying to write a graphics and sound generating program. Clay Type: Response From: Dave Lyons Date: 89-01-19 03:54:09 EST Re: filter proc calling environment Clay, yes--the parameters are already on the stack when your filter proc is called. The parameter passing actually works just like a tool call, except there's 3 bytes less junk on the stack after the parameters than if you were writing a tool. Before calling your routine, the system pushes 2 bytes of space for your procedure's result; then it pushes the 3 parameters and JSLs to your routine. Since the stack pointer points to the free byte on the stack, and since the stack builds down, LDA 4,S will get you the low word of the itemHitPtr, LDA 6,S gets the high word; 8,S and $A,S get the eventPtr; and $C,S and $E,S get theDialogPtr; and STA $10,S stores your return value. Course, those offsets change if you push anything on the stack, even by doing a JSR! It's probably advisable to preserve the direct page register and then set D to point into this "stack frame" so you can use direct-page addresses to get at the parameters, without worrying about the stack. Actually, there's a pair of macros somewhere for assembly called LINK and UNLINK that would be perfect here (are they in the libraries, guys?); the UNLINK macro would save you the trouble of removing the input parameters from the stack before you return, which is your routine's responsibility. Note that this means copying the 3-byte RTL address to a new position in the stack, adjusting the stack pointer, and RTLing. --Dave Type: Response From: AFL Scott Date: 89-01-20 01:20:33 EST Re: Re: Dialog Manager Dave, I uploaded Link/Unlink to the libs about 2 months ago... I think Jim might have had a problem getting them cleared, tho.. Scott Type: Response From: Clayburn Date: 89-01-24 20:14:12 EST Re: Re: Filter procedure The following is an example of dialog box and a custom filter. It is from a program I am writing so I know that it works. By the way the program that called savetbl loaded the address for st23. * This subroutine creates a dialog box with three buttons and some text savetbl ~GetNewModalDialog #svtbltmp PullLong stblptr pha ;Result space lda #^myfilter ;Address of my filter ora #%1000_0000_0000_0000 ;Set bit 31 to also do default filter pha lda #myfilter pha _ModalDialog ~CloseDialog stblptr pla rts * This is a custom filter procedure. It checks to see if <.> is pressed. * If it is it activates the cancel button. myfilter PullWord :rtl ;Save return address from stack sep #MODE816 ;Pull one byte pla sta :rtl+2 rep #MODE816 ;Return to two bytes ;Three long values and a word were put on the stack ;by ModalDialog That are needde by myfilter. They ;need to be pulled off the stack and saved before ;The program is set to for this data bank and direct ;page PullLong :hitptr ;Pointer to item hit address PullLong :event ;Pointer to event record PullLong :dialptr ;Pointer to dialogs grafport pla ;Result space phb ;Save other's data bank phk ;Get our data bank plb ;Data bank = ours phd ;Save direct page lda mydp ;Use our direct page tcd lda :event ;Load pointer of event record in zero page pointer sta PTR lda :event+2 sta PTR+2 lda :hitptr ;Load pointer of item hit address in zero page sta PTR2 ;pointer lda :hitptr+2 sta PTR2+2 stz :hit ;On each pass through myfilter first say didn't hit ;any button at first lda [PTR] ;Type of event and #$FF ;Only want to look at low byte cmp #3 ;Is It a key press? bne :exit ;If not just exit ldy #2 lda [PTR],y ;Get ASCII code from event record and #$FF ;Only want to look at low byte cmp #'.' ;Is it a period? bne :exit ;If not just exit ldy #14 lda [PTR],y ;Check modifier field. bit #%0000_0001_0000_0000 ;Is the apple key pressed? beq :exit ;If not just exit ~GetControlDItem :dialptr;#2 ;Get the handle of the cancel button PullLong :chandle ;(control #2) ~HiliteControl #2;:chandle ;Hilite and then unhilite it ~HiliteControl #0;:chandle lda #2 ;Say that you hit control #2 sta [PTR2] sta :hit ;Say to handle request from myfilter :exit lda :hit ;If 0 ignore myfilter. If not zero handle myfilter ;request pld ;Restore direct page plb ;Restore data bank pha ;Do myfilter or not (from :hit) sep #MODE816 ;Push one byte lda :rtl+2 ;Restore return pointer to stack pha rep #MODE816 ;Return to two bytes PushWord :rtl rtl * Storage space for myfilter :rtl ds 3 :hit da 0 :hitptr adrl 0 :event adrl 0 :dialptr adrl 0 :chandle adrl 0 stblptr adrl 0 * Template for dialog box svtbltmp da 58,40,141,280 ;Size and position da TRUE ;Make it visible adrl 0 adrl sb3 ;button 3 "No" adrl sb2 ;Button 2 "Cancel" adrl sb1 ;Button 1 "Yes" adrl st2 ;Text adrl st1 ;Text adrl 0 st1 da 4 ;Item ID number da 8,8,17,88 ;Position and size in dialog box da $F ;Type (text) adrl st12 ;Address of text da 0 ;Item value da TRUE ;Visible adrl 0 ;Standard color table st12 str 'Save table' st2 da 5 da 25,8,34,232 da $F st23 adrl 0 ;Put text string address here da 0 da TRUE adrl 0 newstr str 'before initialing new table?' loadstr str 'before loading new table?' sb1 da 1 da 42,8,54,40 da $A adrl sb12 da 0 da FALSE adrl 0 sb12 str 'Yes' sb2 da 3 da 62,8,74,40 da $A adrl sb22 da 0 da FALSE adrl 0 sb22 str 'No' sb3 da 2 da 62,72,74,128 da $A adrl sb32 da 0 da FALSE adrl 0 sb32 str 'Cancel' Type: Response From: AFL Jim Date: 89-01-30 00:17:31 EST Re: Modeless Dialog (moved message) Subj: modeless dialog 89-01-29 16:25:26 est From: Windrider5 Msgs: 1 (89-01-29) I am developing a program for the IIgs using APWC complier and I have a question regarding the use of Modeless dialogs. In my program I have two Modeless dialogs called page1 and page2. The first dialog page1 is called from a menu and after that modeless dialog is closed (using the CloseDialog call) the second dailog page2 is called. My main event loop first calls TaskMaster then enters a while loop first using a switch statement checking for Menu events (wInMenuBar) then wInContent events. I then use an if statement with a IsDialogEvent() call. If there is a dialog event a routine is called which calls DialogSelect(&EventRec, &MDPtr, &itemHit). My problem occurs after the first modeless dialog is called and closed and the second modeless dialog called. The GrafPortPtr, MDPtr, used in the DialogSelect call points not only to the second modeless dialog page2, but also to the first modeless dialog page1. This presents a great deal of confusion especially if the first dialog is called a second time since MDPtr continues to point to the second dialog. I hope I have made my problem clear, in essence the problem seems to involve the way in which Modeless dialogs are closed and the way in which the handle to the GrafPort in DialogSelect works. Also why does both IsDialogEvent and DialogSelect have to be called before a Modeless Dialog will appear? Type: Response From: Dave Lyons Date: 89-01-30 22:47:52 EST Re: modeless dialogs Easy question first: the items inside a modeless dialog don't appear until you call DialogSelect because Update events for your modeless dialog are one kind of event that DialogSelect takes care of. The dialog window itself should appear when you create it, unless you create it as Invisible and then use ShowWindow on it (in which case it appears when you ShowWindow). I'm not sure if I understand the other question, but I _think_ you're saying this: You open the first dialog & get a dialog pointer to it; you close the dialog and open another one, and the second pointer points to the same place. Right? Well, that makes perfect sense: When you _close_ a dialog (or a window, or a grafport, for that matter), it no longer exists. Any pointers to that area are invalid, and you shouldn't use them. The system has no way of _knowing_ they're invalid, especially after you open _another_ dialog, which is _likely_ to be allocated in exactly the same spot in memory the old one was, since it's asking the memory manager for a block of memory exactly the same size. So: It may be more appropriate for your program to open the two dialogs as Invisible and use ShowWindow and HideWindow as appropriate, so that you can keep two separate pointers to them. An invisible dialog or window still exists even in memory even though you can't see it. --Dave Type: Response From: AFL Jim Date: 89-01-31 23:41:43 EST Re: Modeless Dialog (moved) (Moved Message) Subj: modeless dialog 89-01-31 23:32:15 est From: Windrider5 Msgs: 1 (89-01-31) I tried your suggestion regarding using HideWindow and ShowWindow with my modeless dialog windows. Unfortunately the problem still exist. The trouble seems to center around the DialogSelect call and one of its 3 parameters, namely the pointer to the GrafPortPtr. The problem is that whether I _close_ the 1st modeless dialog or use the HideWindow call this pointer parameter is pointing to both modeless dialogs. For example, let's say that &MDPtr is my resultPtr for the DialogSelect which, as I understand, is where the pointer to the active modeless dialog's GrafPort is stored if DialogSelect returns TRUE. Let's also say that my 2 modeless dialogs are 2 GrafPortPtrs called page1 and page2. I have found that after page2 is created the both statements following the DialogSelect call are true . if(DialogSelect(&theEventRec, &MDPtr, &itemHit)) MDPtr == page1 /*statement #1 */ MDPtr == page2 /* statement #2 */ As I said before I found this to be the case whether I _close_ page1 or use HideWindow. I can not understand how MDPtr could be equivalent to both GrafPortPtr. Type: Response From: Dave Lyons Date: 89-02-01 19:44:43 EST Re: Re: Dialog Manager Windrider5, how about posting the code that creates the dialogs (specifically, the part that assigns values to page1 and page2)? If something is really equal to both page1 and to page2, then page1 must be equal to page2, which isn't good if they're supposed to be separate dialogs. You might also check for "obvious" things like using a single "=" where you meant to use "==" (since if(a=b)... will always seem like a "true" comparison if b is nonzero!). Type: Response From: Windrider5 Date: 89-02-07 20:51:14 EST Re: Re: Dialog Manager /* * This is a small "C" program which has two modeless dialogs, page1 * and page2. The first modeless dialog is created by selecting the Page 1 * item under Modeless in the MENU bar. This dialog has a NEXT PAGE button * which _closes_ page1 and creates the page2 dialog. Both modeless dialogs * have a checkbox item which does nothing but simply allow you to click * on an active item in each dialog. * In order to do some checking I use the SysBeep() call. One beep for events in * page 1 and 2 beeps for events in the page2 modeless dialog. The * SysBeep() calls are in the MDChkOut subroutine which contain the * DialogSelect() call. You might note that I have used two if statements * following the DialogSelect call, instead of using an if and else combination. * This was done so that you can see that after page1 is _closed_ and page2 is * _opened_ the resultPtr (MDPtr) of the DialogSelect call recognizes both * page1 and page2. When you click the checkbox item in page2 you will * hear three beeps. Furthermore if you close the page2 dialog and again * select the PAGE 1 menu item, when you click on the checkbox in page1 you * will hear 3 beeps. * In the program that I am working on I have several modeless dialogs each of * which has several control items. In this program HideWindow and ShowWindow * seems to work fairly well, although there are still some problems apparantly * related to the situation I described above. However, when I tried using * HideWindow/ShowWindow instead of the CloseDialog call with this smaller * program I was unsuccessful. The page2 dialog window would appear but none * of the control items i.e. button or checkbox would be visible. * * Well I hope you can figure out what's going on with the modeless dialogs and * their associated routines particulary DialogSelect. These dialogs are very * useful, if I could get them working properly. */ #include #include #include #include #include #include #include #include #include #include WmTaskRec EventRec; Word Event, UserID, MemID, QFlag; char *DPBase; word tlErrCode; ErrChk() { tlErrCode = _toolErr; if(tlErrCode) SysFailMgr(tlErrCode, nil); } char *GetDP(bytes) word bytes; { char *OldDP = DPBase; DPBase += bytes; return(OldDP); } Word Toolist[] = { 4, 14, 0, /*Window Mgr*/ 16, 0, /*Control Mgr*/ 15, 0, /*Menu Mgr*/ 21, 0, /*Dialog Mgr*/ }; StartUpTools() { Word GetDP(); TLStartUp(); ErrChk(); UserID = MMStartUp(); ErrChk(); MemID = UserID | 256; LoadTools(Toolist); ErrChk(); MTStartUp(); ErrChk(); DPBase = *(NewHandle(0x600L, MemID, 0xC005, nil)); ErrChk(); QDStartUp(GetDP(0x300), 0x0080, 0xA0, UserID); ErrChk(); SetBackColor(0); SetForeColor(3); EMStartUp(GetDP(0x100), 0x14, 0, 0x280, 0, 0xC8, UserID); ErrChk(); WindStartUp(UserID); ErrChk(); CtlStartUp(UserID, GetDP(0x100)); ErrChk(); MenuStartUp(UserID, GetDP(0x100)); ErrChk(); DialogStartUp(UserID); ErrChk(); } ShutDownTools() { DialogShutDown(); MenuShutDown(); CtlShutDown(); WindShutDown(); EMShutDown(); QDShutDown(); MTShutDown(); DisposeAll(MemID); MMShutDown(UserID); TLShutDown(); } PrepDeskTop() { static char *ModelessMenu[] ={ ">> MODELESS \\N3", "-- PAGE1 \\N261", ">" }; static char *FileMenu[] ={ ">> File \\N2", "-- Quit \\N262*Qq", ">" }; RefreshDesktop(nil); InitCursor(); InsertMenu(NewMenu(ModelessMenu[0]), 0); InsertMenu(NewMenu(FileMenu[0]), 0); FixMenuBar(); DrawMenuBar(); } GrafPortPtr page1; Rect page1Rect = {50, 20, 150, 620}; Rect page1okRect = {20, 20, 0, 0,}; Rect page1chkRect = {50, 20, 0, 0}; GrafPortPtr page2; Rect page2Rect = {50, 20, 150, 620}; Rect page2okRect = {20, 20, 0, 0,}; Rect page2chkRect = {50, 20, 0, 0}; DoPage1() { page1 = NewModelessDialog(&page1Rect, NULL, topMost, 0x20, NULL,NULL); NewDItem(page1, 9, &page1okRect, buttonItem, "\pNEXT PAGE", 0,2,NULL); NewDItem(page1, 10, &page1chkRect, checkItem, "\pPage 1 Check", 0,0,NULL); } DoPage2() { page2 = NewModelessDialog(&page2Rect, NULL, bottomMost, 0x20, NULL,NULL); NewDItem(page1, 19, &page2okRect, buttonItem, "\pDONE", 0,2,NULL); NewDItem(page1, 20, &page2chkRect, checkItem, "\pPage 2 Check", 0,0,NULL); } DoMenu() { switch(EventRec.wmTaskData) { case 261: DoPage1(); break; case 262: QFlag = TRUE; break; } HiliteMenu(FALSE, EventRec.wmTaskData >> 16); } MDChkOut() { GrafPortPtr MDPtr; Word itemHit; if(DialogSelect(&EventRec, &MDPtr, &itemHit)) { if(MDPtr == page1) { SysBeep(); if(itemHit == 9) { CloseDialog(page1); DoPage2(); } } if(MDPtr == page2) { SysBeep(); SysBeep(); if(itemHit == 19) CloseDialog(page2); } } } main() { StartUpTools(); PrepDeskTop(); QFlag = FALSE; EventRec.wmTaskMask = 0x00001fff; while(!QFlag) { Event = TaskMaster(0xffff, &EventRec); switch(Event) { case wInMenuBar: DoMenu(); break; case wInContent: break; } if(IsDialogEvent(&EventRec)) MDChkOut(); } ShutDownTools(); exit(0); } Type: Response From: Coach101 Date: 89-02-08 00:13:55 EST Re: Re: How About Using dRefCon Windrider, The code you posted was for the create/close/create/... case. As Dave suspected, you are trying to identify things by the addresses that the memory manager __happened__ to give them. One of the arguments to NewModelessDialog is dRefCon. This is a longword whose use is reserved for the application. One of the uses that I make of this is place a flag that tells me what kind (and which of what kind) of Dialog box I have. The trick (not documented or alluded to in the manuals) is getting the value for dRefCon back from the system. What you can do is use the window manager routine GetWRefCon (check my spelling) with the MDPtr returned from DialogSelect. For example, define two constants at the beginning of your program: #define page1_refcon 0xdead0001 #define page2_refcon 0xdead0002 Now when you create the modeless dialog's pass these values as the dRefCon (the second from the last argument in the NewModelessDialog call). For example: page1 = NewModelessDialog (&page1rect, nil, bottomMost, 0x20, page1_refcon, nil) ; Now when you test to see which dialog has been hit change the test to: if (GetWRefcon(MDPtr) == page1_refcon) This type of thing works great for me. As to why the show/hide did not work, I do not know. If you have the memory, I would think that show/hide would be faster. How about posting the actual failing code for the show/hide failure? Type: Response From: Coach101 Date: 89-02-08 00:28:42 EST Re: Re: Frame Scroll Bars.... Can I make the window frame scroll bars (turned on with the frame flag bits on the call to NewModelessDialog) operational in the same way they work with windows (i.e., let TaskMaster do the work)? I have caused the scroll bars to be generated by setting the bits in the frame control word but the bars always come up white as the driven snow (i.e., no thumb or shading). The Size box is also asked for and it seems to work fine? I set the sizes of the two rectangles (initial and zoomed) differently (i.e., zoomed is bigger than initial) and hitting the zoom box does enlarge my window. I read some place that DIcEd uses Modeless dialog boxes and its scroll bars work as in a normal window (at least in the Icon editing box/window). Do I need to look further at my code or am I trying to do something that is not doable? Type: Response From: AFL Scott Date: 89-02-08 18:18:27 EST Re: Re: Dialog Manager If I'm not mistaken Coach, Dave uses plain windows... I might be wrong... it's been a long time since I ran Nifty List through his code. Scott Type: Response From: Dave Lyons Date: 89-02-08 21:14:01 EST Re: Modeless dlgs can't scroll? Coach, as far as I can tell the system doesn't currently support modeless dialogs scrolling. DIcEd does indeed use modeless dialogs for the Icon File windows, but _not_ for the Edit Icon windows. (Early versions used modeless dialogs for everything, but I couldn't make them scroll!) Type: Response From: Dave Lyons Date: 89-02-08 21:15:28 EST Re: Windrider's modeless dlgs Windrider, I couldn't see the end of the code you posted--I'm using the IIe version of the ALPE software, and I got a BUFFER FULL before it was all here. Like Coach says, one way to go is using the RefCons (reference constants). But the dialogs _do_ stay put in memory between the time you open them and the time you close them, so comparing the pointers is okay, too. The only fishy thing I noticed in the part of your code I saw is that GetDP is declared as char * when it's defined, but redeclared as Word inside your tool startup function. Apparently this doesn't cause a crash, but it scares me--you ought to declare GetDP as a Word in the first place, and have it do "return( (Word) xxx );" instead of "return(xxx);". Type: Response From: Coach101 Date: 89-02-09 00:07:32 EST Re: Re: Windrider Compared Pointers As you deduced early on Dave, Windrider is closing a dialog, opening a second, and then looking at the pointer returned by DialogSelect to see which dialog an event is posted against. Thats almost surely doomed to failure in the long run. But, Windrider also says that the Show/Hide (without closing, thereby releasing memory for re-use) also failed. That code I would like to look at to see what is going on there (the pointer technique should be valid in that case). Type: Response From: Matt DTS Date: 89-02-11 02:14:36 EST Re: Re: Dialog Manager We interrupt this discussion for a general editorial. Folks, if you're having really bad problems getting the Dialog Manager to do what you want, please give consideration to just doing it in a window and using the Window and Control Managers to keep track of things. It's not that much more difficult and gives a lot more flexibility. We now return you to the discussion in progress. Type: Response From: Coach101 Date: 89-02-12 12:25:08 EST Re: Re: Default Buttons - ReSetting My ModeLess dialog contains three critical _action_ buttons for the user (Validate, Calculate, Output). The dialog is created with _Validate_ as the default button. Once _Validate_ is successfully completed, _Calculate_ is to become the default button. Other user actions (and program reactions to errors and problems) will cause the current default button to move around. My first take at this was to use SetDefButton to move things around. This seems to work in that the new default button gets its _double-box_ enhancement, but the previous default button's appearance does not change (i.e., it is also a benefactor of the _double-box_ visual enhancement). I have two questions: 1) What is the accepted (i.e., violates no Apple commandments and should work with future ToolBox releases) way to change default buttons and have the graphic rendition properly reflected to the user? 2) How do you get rid of a button's default status and not make some other button the default (e.g., convert to a dialog that has _no_ default buttons from a dialog that has a default button)? I have not tried using SetDefButton with an Id of zero (the last time I used an ItemId of zero I spent several days chasing what had gone wrong) and I have not put in code to RemoveDItem and then NewDItem (it would undoubtedly work, but it seems like overkill for what I am trying to do). Type: Response From: Dave Lyons Date: 89-02-12 18:12:18 EST Re: changing default buttons Hmmm...don't know how to switch to having _no_ default button; good question. RemoveDItem and NewDItem w/ a different item number would be one way...so that there is no item with the button number of the default button. To make the old control redraw, first be sure the port is set to your dialog and then use InvalRect(controlHandle^.boundsRect). Type: Response From: Dave Lyons Date: 89-02-12 18:14:10 EST Re: Err... I mean InvalRect(ControlHandle^^.boundsRect), I spoze. Type: Response From: Coach101 Date: 89-02-12 20:17:24 EST Re: Re: InvalRect I Guess.... I tried a Hide/Show (after discovering that any part of the ex-default-button that had to be redrawn was drawn _without_ the accent) but all that gets me is a "flash to white" follwed by the accented button again. I was going to use GetDItemRect (if thats spelled correctly) and was wrestling with how to guess what level of expansion to apply in order to get the button outline (which is outside the bounds-rect I gave to DialogManager). I gather by the fact that you are suggesting it, that the control record rectangle includes the space occupied by the the button outline. Since DialogManager knows all the info when I call SetDefButton, it would have been nice of him/her/it to do it for me; but, I guess you can only fit so much in a finite ROM space. Thanks for the suggestion Dave. I will give it a try and report its success back to you. Type: Response From: Coach101 Date: 89-02-17 22:27:39 EST Re: Re: Changing Default Buttons Grrrrrr....... First, both GetDItemBox and the rectangle from the control record define a space that does _not_ include the button outline(s). I am still checking my code, but with the help of NiftyList and a few printf statements I am fairly certain I am doing things correctly. I put all the code in an external function so I could use it from several places. I pass two arguments to the function (Dialog_ and DItem). The first thing I do is GetPort and save the result. I then SetPort to Dialog_. Having secured the previous environment and _guaranteed_ I am pointing to the correct port (verified via printf and NiftyList ~w) I then use GetDItemBox to get the bounds rectangle of the buttonItem that I am playing with. My first take just passed a pointer to the rectangle I obtained on to InvalRect, restored the GrafPort that was in effect on entry (in case it was different) and then returned to the caller. This does not work! I am in the process of adjusting the rectangle that I pass to InvalRect but at the present time, it looks like a loser to me. This simple little task may well be on the road to being more work than it merits! I have a little more work to do in order to absolutely convince myselft that I do not have a bug and I will post another message back here when I come to a final conclusion. Dave, have you ever made this work? Type: Response From: Coach101 Date: 89-02-17 23:38:30 EST Re: Re: Default Buttons -- I Give Up Well, I see nothing abnormal in my code. I went back and changed the code to NewRgn/RectRgn/UpdateDialog/DisposeRgn and that just gets me a flashing button for a second. I played around with a simple EraseRect and got some interesting results. I erase the the button, and somebody redraws it for me (without the default enhancements). Looks good until you obscure the button with some other window. When the obscuring window is removed, the part of the button that was not obscured is fine but the part of the button that was obscured (and was there before the obscuring window encroached) is now erased (i.e., white). I am thoroughly confused and have no idea who is doing what to whom when? Any thoughts? Type: Response From: Matt DTS Date: 89-02-17 23:48:27 EST Re: Re: Dialog Manager Gee, someday we'll have to do something like an _InvalControls call to make this easier, I suppose. Coach - if the button outline is outside the Control Rectangle (and you can prove it will be on the bottom of page 4-14 of the Toolbox Reference), you can try a few things. What seems to be happening (Dave will correct me if I'm wrong) is that the Dialog Manager or someone has changed the status of the control in memory, but no one has redrawn it in the window. An _InvalRect on the control's rect won't work because the offending shadow is outside the control's rect. So, one thing to try might be to get the rect as Dave suggested, but then add three or four pixels on each side (to expand the rect around the outline) and then _InvalRect on that. Another thing which might work is the _DrawOneCtl command. Redrawing the effected control might do it in one step. Here's a simple test: if an InvalRect on the entire Dialog doesn't work, or if _RefreshDesktop doesn't do it, then Dave and I are wrong and the Dialog Manager has NOT changed the control in memory. Neither of these last two methods (_InvalRect on the Dialog or _RefreshDesktop) is good enough to leave in, but it will show you if the control is really correct in memory or not, just waiting for someone to redraw it correctly. --Matt Type: Response From: Dave Lyons Date: 89-02-18 02:21:40 EST Re: Invalidating controls Yeah, what Matt said. Note that InsetRect makes it very easy to adjust rectangles. Use negative numbers for the 2nd and 3rd parameters to make the rectangle bigger. (There is no "OutsetRect" toolbox call; it isn't needed, because you just need to negate the dx and dy parameters.) Type: Response From: Windrider5 Date: 89-02-18 14:05:02 EST Re: Re: Dialog Manager I have finally got my modeless dialogs working just fine using the Show and Hide Window method. Apparently, the problem was that I was opening all the dialogs first (in reverse order) and then Hiding each one in turn. I guess this caused some confusion (most likely in my own code) that resulted in the wrong dialogs appearing. Interestingly, the small sample program which I posted (modelessdial.c) still has problems with the Show/Hide window method. Coach101 expressed interest in seeing that code so I'm posting that version in a separate message. In any case thanks for the advice about using the Show/Hide method. A couple additional comments/questions re: dialogs. 1. I read a message which suggested that instead of messing around with the modeless dialog, I should make my own windows and controls using the Window and Control mgrs. I really don't buy that argument. This method is ok if you are just using radiobuttons, simplebuttons or checkboxes, but things get pretty tricky if your dialog/window has editlines or icons. The modeless dialog (now that I've got it working) is as flexible as using a window, but handles all the tedious work of making and dealing with controls automatically, which is what the TOOLBOX is all about. The only thing I don't know about yet, is how the Dialog mgr handles custom controls versus using the Control mgr (guess what I'll be asking about in up coming messages). 2. When using longStatText, does anyone know of a good (as opposed to hit & miss) method of passing the number of bytes in the string? 3. Finally, when using the longStatText (using a C style string), I will get a "string too long" error message even when I have far fewer than 32,767 characters. Any advice on this problem? Type: Response From: Windrider5 Date: 89-02-18 14:14:45 EST Re: Re: Dialog Manager /* * This is a small "C" program which has two modeless dialogs, page1 * and page2. The first modeless dialog is created by selecting the Page 1 * item under Modeless in the MENU bar. This dialog has a NEXT PAGE button * which _closes_ page1 and creates the page2 dialog. Both modeless dialogs * have a checkbox item which does nothing but simply allow you to click * on an active item in each dialog. * In order to do some checking I use the SysBeep() call. One beep for events in * page 1 and 2 beeps for events in the page2 modeless dialog. The * SysBeep() calls are in the MDChkOut subroutine which contain the * DialogSelect() call. You might note that I have used two if statements * following the DialogSelect call, instead of using an if and else combination. * This was done so that you can see that after page1 is _closed_ and page2 is * _opened_ the resultPtr (MDPtr) of the DialogSelect call recognizes both * page1 and page2. When you click the checkbox item in page2 you will * hear three beeps. Furthermore if you close the page2 dialog and again * select the PAGE 1 menu item, when you click on the checkbox in page1 you * will hear 3 beeps. * In the program that I am working on I have several modeless dialogs each of * which has several control items. In this program HideWindow and ShowWindow * seems to work fairly well, although there are still some problems apparantly * related to the situation I described above. However, when I tried using * HideWindow/ShowWindow instead of the CloseDialog call with this smaller * program I was unsuccessful. The page2 dialog window would appear but none * of the control items i.e. button or checkbox would be visible. * * Well I hope you can figure out what's going on with the modeless dialogs and * their associated routines particulary DialogSelect. These dialogs are very * useful, if I could get them working properly. */ #include #include #include #include #include #include #include #include #include #include WmTaskRec EventRec; Word Event, UserID, MemID, QFlag; char *DPBase; word tlErrCode; Boolean firstTimepg1 = FALSE; Boolean firstTimepg2 = FALSE; ErrChk() { tlErrCode = _toolErr; if(tlErrCode) SysFailMgr(tlErrCode, nil); } char *GetDP(bytes) word bytes; { char *OldDP = DPBase; DPBase += bytes; return(OldDP); } Word Toolist[] = { 4, 14, 0, /*Window Mgr*/ 16, 0, /*Control Mgr*/ 15, 0, /*Menu Mgr*/ 21, 0, /*Dialog Mgr*/ }; StartUpTools() { Word GetDP(); TLStartUp(); ErrChk(); UserID = MMStartUp(); ErrChk(); MemID = UserID | 256; LoadTools(Toolist); ErrChk(); MTStartUp(); ErrChk(); DPBase = *(NewHandle(0x600L, MemID, 0xC005, nil)); ErrChk(); QDStartUp(GetDP(0x300), 0x0080, 0xA0, UserID); ErrChk(); SetBackColor(0); SetForeColor(3); EMStartUp(GetDP(0x100), 0x14, 0, 0x280, 0, 0xC8, UserID); ErrChk(); WindStartUp(UserID); ErrChk(); CtlStartUp(UserID, GetDP(0x100)); ErrChk(); MenuStartUp(UserID, GetDP(0x100)); ErrChk(); DialogStartUp(UserID); ErrChk(); } ShutDownTools() { DialogShutDown(); MenuShutDown(); CtlShutDown(); WindShutDown(); EMShutDown(); QDShutDown(); MTShutDown(); DisposeAll(MemID); MMShutDown(UserID); TLShutDown(); } PrepDeskTop() { static char *ModelessMenu[] ={ ">> MODELESS \\N3", "-- PAGE1 \\N261", ">" }; static char *FileMenu[] ={ ">> File \\N2", "-- Quit \\N262*Qq", ">" }; RefreshDesktop(nil); InitCursor(); InsertMenu(NewMenu(ModelessMenu[0]), 0); InsertMenu(NewMenu(FileMenu[0]), 0); FixMenuBar(); DrawMenuBar(); } GrafPortPtr page1; Rect page1Rect = {50, 20, 150, 620}; Rect page1okRect = {20, 20, 0, 0,}; Rect page1chkRect = {50, 20, 0, 0}; GrafPortPtr page2; Rect page2Rect = {50, 20, 150, 620}; Rect page2okRect = {20, 20, 0, 0,}; Rect page2chkRect = {50, 20, 0, 0}; DoPage1() { if(!firstTimepg1) { page1 = NewModelessDialog(&page1Rect, NULL, topMost, 0x20, NULL,NULL); NewDItem(page1, 9, &page1okRect, buttonItem, "\pNEXT PAGE", 0,2,NULL); NewDItem(page1, 10, &page1chkRect, checkItem, "\pPage 1 Check", 0,0,NULL); firstTimepg1 = TRUE; } else ShowWindow(page1); } DoPage2() { if(!firstTimepg2) { page2 = NewModelessDialog(&page2Rect, NULL, topMost, 0x20, NULL,NULL); NewDItem(page1, 19, &page2okRect, buttonItem, "\pDONE", 0,2,NULL); 0,2,NULL); NewDItem(page1, 20, &page2chkRect, checkItem, "\pPage 2 Check", 0,0,NULL); firstTimepg2 = TRUE; } else ShowWindow(page2); } DoMenu() { switch(EventRec.wmTaskData) { case 261: /* if(firstTimepg1) ShowWindow(page1); else DoPage1(); */ DoPage1(); break; case 262: QFlag = TRUE; break; } HiliteMenu(FALSE, EventRec.wmTaskData >> 16); } MDChkOut() { GrafPortPtr MDPtr; Word itemHit; if(DialogSelect(&EventRec, &MDPtr, &itemHit)) { if(MDPtr == page1) { SysBeep(); if(itemHit == 9) { HideWindow(page1); DoPage2(); } } if(MDPtr == page2) { SysBeep(); SysBeep(); if(itemHit == 19) { HideWindow(page2); } } } } main() { StartUpTools(); PrepDeskTop(); QFlag = FALSE; EventRec.wmTaskMask = 0x00001fff; while(!QFlag) { Event = TaskMaster(0xffff, &EventRec); switch(Event) { case wInMenuBar: DoMenu(); break; case wInContent: break; } if(IsDialogEvent(&EventRec)) MDChkOut(); } ShutDownTools(); exit(0); } Type: Response From: Coach101 Date: 89-02-18 17:35:54 EST Re: Re: InvalButton - Guess Again RefreshDesktop will cause the button to be redrawn without the _default_ enhancement. Nothing else that I do (from within the program) seems to make that happen. I have tried InvalRect with values that I know (and confirmed with printf statements) encompass the _default_ enhancement. I have tried DrawDialog (it should be faster than RefreshDesktop) but all it does is _flash_ every item in the dialog at me as it (I presume) erases and re-draws them (needless to say the ex-default button keeps its _default_ enhancement). I know of three things that will get the _default_ enhancement _zapped_: 1. Issue a RefreshDesktop() from within the InvalidateDItem function. This can be slower than sin on a busy desk top. 2. Click the Zoom box in the window twice (once gets the desired effect but leaves the window in the opposite zoom state of what the user had in effect, ergo the second one to get things back to status quo). This is not only slow but dangerous since the interaction between _moving_ a window and _zooming_ a window can actually leave you with a _zoom_ box that is really a _toggle_position_ box. 3. Drag some other window over the offending button and then close or drag the other window away. The part of the ex-default button that was obscured is now re-drawn _correctly_. I tried using InvalRect, building a _phony_ update event record, calling DialogSelect with the _phony_ update event and praying. That did not work either. My current guess is that some piece of the toolbox has indicated to the world that there is no _default_ enhancemnet in effect but has failed to erase the _default_ enhancement; so everytime the bloody thing is updated, everyone ignores the area occupied by the _default_ enhancement (because everyone believes it is not there). The methods that work do so (work that is) because the area is erased before being redrawn. Matt, did not quite understand what you were getting at with: "if the button outline is outside the Control Rectangle (and you can prove it will be on the bottom of page 4-14 of the Toolbox Reference) ... " I read the manuals profusely (on occasion the material even penetrates my thick skull and dense brain). But, I never use the manual to __prove__ anything! Proving is reserved for dumps and actually doing things! By the way, I consider the Apple technical documentation to be very good! My only complaint would be that I would like to see more detail in some places; a really minor complaint, most of the time you hit it on the head with the right amount of detail. Type: Response From: Coach101 Date: 89-02-18 17:39:03 EST Re: Re: WindRider's Problem I have downloaded the material and am looking at it now. One question though. What editor and "C" compiler are you using. The file contains _backspace_ characters at positions that suggest you put them in (i.e., not line hits). APW "C" chokes on them (bad token). I got rid of them and am continuing looking for your problem. When I execute your program and select next window out of window-1, thats the end of the story. The second window comes up blank and the only option left is to quit. Is this the "actual" (as in exact replica) of the failing case? Type: Response From: Coach101 Date: 89-02-18 19:18:12 EST Re: Re: A Solution For Windrider You have a _typo_ when you create the DItems for the _page2_ modeless dialog. On your NewDItem calls you pass _page1_ where you should be passing _page2_. Net effect is that you created all the DItems in _page1_'s modeless dialog. After correcting the _typo_ everything seems to run fine (one beep for _page1_ hits, 2 beeps for _page2_ hits). Type: Response From: Coach101 Date: 89-02-18 19:20:59 EST Re: Re:EraseRect _then_ InvalRect What seems to work, though I do not think it is foolproof, is to do an EraseRect of a larger rectangle (encompassing the box outline(s)) and then InvalRect only the rectangle that you get with GetDItemBox. Matt, would you say there was a bug somewhere or ... ? Type: Response From: Dave Lyons Date: 89-02-19 07:41:45 EST Re: longStatText items To avoid having to count the characters in a longStatText item, use a strlen() call in the NewDItem call. Easy, no? Type: Response From: Coach101 Date: 89-02-23 23:22:42 EST Re: Re: InvalDItem - Small Problem I have a small function that I call to do the InvalidateDItem function. This works fine except in one obscure case. If I have done an invalidate on a button, then gone back to having that button as default, and then I use AlertWindow to create a window that only partially obscures the present default button (which has been through InvalidateDItem previously in its life), the part of the button that was not obscured is drawn without the default _enhancement_; the part of the button that was obscured is drawn with the enhancement. In order to prove that I was _covering_ the entire _enhancement_ with the EraseRect call, I changed the EraseRect to a FrameRect and commented out the the InvalRect. This leaves a _framed_ button on the screen for me to inspect with a magnifying glass. With the constants I am presently using, the frame was just above and below the default enhancement (i.e., no pixel gap vertically) and one pixel outside the enhancement on the left and right (i.e., one pixel gap horizontally). This is a minor problem and only of interest from a esthestic viewpoint from I would like to get this _totally_ correct for purposes of personal pride if nothing else. I will post the actual code of my function in the following mail message (hoping to keep it inside Dave's buffer limits). Anyone have any ideas. Type: Response From: Coach101 Date: 89-02-23 23:31:15 EST Re: Re: InvalDItem - Problem Code /* This "C" function will invalidate the area occupied by a specified item within a specified Dialog. Since the area has been invalidated, the item will be redrawn the next time the Dialog's window is updated (generally pretty quickly after the call). */ #define Failure 0 #define Success 1 #include #include #include #include #include #include #include #include unsigned int InvalidateDItem ( Dialog_ , DItem ) GrafPortPtr Dialog_ ; unsigned int DItem ; { /* Declare the external variables necessary for the error reporting package. */ extern EmsgTbl InvalidateDItemErrorText[1] ; extern EmsgTbl InvalidateDItemWhereText[1] ; auto EmsgTblPtr LIB_ER_MODUL_hold ; auto EmsgTblPtr LIB_ER_TXTBL_hold ; auto EmsgTblPtr LIB_ER_WHTBL_hold ; /* Declare our local storage needs. */ auto Rect DItemRect ; auto unsigned int DItemType ; auto GrafPortPtr GrafPort_OnEntry ; auto unsigned int ReturnValue ; /* Install ourselves as the current module and save the previous modules error reporting vectors. */ LIB_ER_MODUL_hold = LIB_ER_MODUL ; LIB_ER_TXTBL_hold = LIB_ER_TXTBL ; LIB_ER_WHTBL_hold = LIB_ER_WHTBL ; LIB_ER_MODUL = (EmsgTblPtr)"\pInvalidateDItem" ; LIB_ER_TXTBL = &InvalidateDItemErrorText[0] ; LIB_ER_WHTBL = &InvalidateDItemWhereText[0] ; /* Set the default return value and save the current GrafPort so that we can restore it upon exit. */ ReturnValue = Failure ; GrafPort_OnEntry = GetPort () ; SetPort ( Dialog_ ) ; /* Get the enclosing rectangle for the Dialog Item that we are going to invalidate. Then go ahead and InvalRect the little ditty. */ GetDItemBox ( Dialog_ , DItem , &DItemRect) ; if (_toolErr) { PostEmsg (SysErr_Caution , _toolErr , 0x0001 ) ; goto ReturnToCaller ; } InvalRect ( &DItemRect ) ; /* If this is a simple button item, then we need to enlarge the rectangle to include the boxes involved and then we EraseRect the area to get rid of any _default_ enhancements that may be in effect. */ DItemType = GetDItemType ( Dialog_ , DItem ) ; if (_toolErr) { PostEmsg ( SysErr_Caution , _toolErr , 0x0002 ) ; goto ReturnToCaller ; } if ( (DItemType&(~itemDisable)) == buttonItem ) { DItemRect.v1 -= 3 ; DItemRect.h1 -= 6 ; DItemRect.v2 += 3 ; DItemRect.h2 += 6 ; EraseRect ( &DItemRect ) ; } /* Return to the caller. */ ReturnValue = Success ; ReturnToCaller: SetPort (GrafPort_OnEntry) ; LIB_ER_MODUL = LIB_ER_MODUL_hold ; LIB_ER_TXTBL = LIB_ER_TXTBL_hold ; LIB_ER_WHTBL = LIB_ER_WHTBL_hold ; return (ReturnValue) ; } Type: Response From: Dave Lyons Date: 89-02-24 20:14:43 EST Re: double button outlines are pains I _think_ I've got a grip on what you're trying to do. If I do, all you need to do is put the InvalRect call _after_ the code that expands the rectangle. In other words, you're invalidating the dialog item, but you're not invalidating the extra-big version that includes the area where the double outline is drawn. By the way, instead of those for += and -= assignment statements, you could expand the rectangle like this: InsetRect(&DItemRect,-6,-3); Getting everything to look just right is a very Good Thing! I wish everybody would take the trouble to do that. I see far too many ugly menus and half-dimmed buttons.... Type: Response From: Dave Lyons Date: 89-02-24 20:18:14 EST Re: changing default button good? BTW, I'm not a human interface guidelines expert, but it seems that generally you want the default button to always be the same to avoid confusing the user. There are probably legit exceptions to that, and certainly it's okay if what the _user_ sees is the same (your program might build its dialogs differently in different cases & have a different item number for what the user sees as the same old thing). Type: Response From: Coach101 Date: 89-02-24 21:17:42 EST Re: Re:Why I Change Default Buttons I have a copy of AHIG (Apple Human Interface Guidelines) and will confess to not having read the entire document. I think of a default button as a short-cut (since it is triggered by a CR as opposed to a mouse click) to the most common user reaction at a given time. One thing I have personally observed in using desktop applications is that I get really angry at applications that cause me to have to continually switch from keyboard to mouse. There is no _reasonable_ alternative to the keyboard for entering a text item and so I have set the default button to be the most common action after a given text entry. My program generates a six-generation pedigree for a user specifed dog/bitch and then outputs the pedigree to the printer (presently using TextTool calls, but I just picked up the Source Code Sampler V-1 at APDA today, so look out for me in the PrintManager folder). My Modeless dialog contains a number of items that control what happens with three _action_ buttons. The action buttons (in the order that they have to be executed) are: VALIDATE -- Make sure the EditLine item points to an animal is in the data file. CALCULATE - Generate a 6 generation pedigree in the LineageTbl. PRINT ----- Take a gues at what this does. Now, initially, VALIDATE is the default button. Once a VALIDATE has been done, the program auto-magically switchs the default button to CALCULATE (makes no sense to validate again). If you do a successful CALCULATE another auto-magic switch is made so that the default button becomes PRINT. Touch the LineEdit item anyplace along the way (thereby invalidating any VALIDATE and/or CALCULATE that has been done) and auto-magically the default button becomes the VALIDATE button again. Since it takes almost zip time to do a VALIDATE (even with a disk file of 1,000+ animals) it is very convenient to stroke in an Akc number (the dogdom equivalent of a social security number) and whack the old CR/ENTER. Almost before you realize it the program has either complained about a missing animal (via AlertWindow with a default button so you do not have to leave the keyboard to do your correction) or has changed the Modeless dialog's window title to be the name of the dog whose Akc number was entered. Since the dog was found (in quick time) and your finger is still on the CR/ENTER, just whack it again and a pedigree will be calculated. This, unfortunately, takes a little time (<30 seconds). A lot of times the next step is actually to have the program display some information about the missing elements of the pedigree, change some of the output options (dogdom specific formatting) or occasionally, whack the CR/ENTER again and get your hardcopy. Anyway, thats the reason I did it with multiple default buttons. Keep the users hands in one place as much as possible. I will give your suggestion a try, but I believe that I tried it before with the end result being a _flashing_ button that ended up with the undesired embellishments. I read your prior item on using InsetRect but left my code as it was since it seemed a hair more self-documenting and though it may (or may not) take more space it has to execute faster. I shall report back after having modified my library routine and seeing what I get. Thanks for the attention..... Type: Response From: Coach101 Date: 89-02-25 02:11:50 EST Re: Re: InvalidateDItem -- Got It... Well, Dave, as I thought I remembered, a simple InvalRect that encompasses the entire button as drawn (i.e., including the _sticky_ enhancements around it) just gives you a fade to white followed by a fully enhanced button. I played some more and the solution that gets rid of the enhancment and keeps it gone even with the AlertWindow is to: 1. Expand the rectangle by the amounts in the previous source code. 2. EraseRect the expanded rectangle. 3. InvalRect the _expanded_ rectangle. Everything else I have tried fails in some manner. If you want to change the source code in the previous message, move the InvalRect call to after the if { } that does the rectangle expansion and EraseRect for button items. This approach seems to work in all cases (that I have had the oppurtunity/misfortune to test/deal-with). Matt, Dave I would sure like to have an understanding of how things are really being done between WindowManager, DialogManager, and ControlManager so that I could figure out how to do things like this without having to resort to shotgun techniques. My experience with _shotgun_ and _EasterEgg_ approaches is that they are not wholly reliable from release to release. The surprising part to me is the need for the EraseRect call. Type: Response From: Dave Lyons Date: 89-02-25 14:01:39 EST Re: invalidating expanded rectangle Good, glad it's working now. Moving the InvalRect _was_ what I suggested, wasn't it? :) I don't think your approach is going to break in the future, although the need to inval and erase the old default button might be removed in the future. (It seems like SetDefButton should take care of it, right?) What it is you want to know about the dialog/window managers? Seems like you already have a pretty good grip on it, if you knew in the first place that InvalRect was something that would help by causing part of the dialog to be redrawn later. InvalRect adds to the Update Region of the dialog's window, and later TaskMaster will call GetNextEvent, which will return an update event for your dialog. TaskMaster returns that to your program, your program calls IsDialogEvent and then DialogSelect. DialogSelect processes the update event by (among other things, probably) calling BeginUpdate, DrawControls, and EndUpdate. Between a BeginUpdate and EndUpdate, only areas that were in the Update region will be drawn (other stuff gets clipped). Type: Response From: Coach101 Date: 89-02-25 14:48:27 EST Re: Re: The Strange Behaviour Is.... Sorry about the misunderstanding Dave, I thought you meant to just use a properly sized InvalRect and throw away the EraseRect. The behaviour that causes me to ask about the relationships between the players in this scenario was that: a) RefreshDeskTop will get the control redrawn correctly _without_ any external (i.e., EraseRect, InvalRect) actions whereas a DrawDialog will redraw the dialog without correcting the default button enhancment situation, and b) the split personality of a button that has had a _full_ EraseRect and a _partial_ InvalRect. It is almost as if someone is caching something and restoring it in certian situations (the AlertWindow case?). And I would expect RefreshDesktop and DrawDialog to have the same effect on a given dialog (i.e., totally redraw it, but redraw it the same way irrespective of which call was made). These aberrations in the behaviour I was expecting mean that my "model" of the inter- play between these toolbox routines is inaccurate. Type: Response From: Dave Lyons Date: 89-02-26 02:54:38 EST Re: RefreshDesktop vs. DrawDialog Well, _I_ knew what I meant. :) The difference between RefreshDesktop and DrawDialog is that RefreshDesktop causes all visible parts of windows to be erased to their background patterns and invalidated. (Well, actually just the parts that are inside the rectangle you pass to RefreshDesktop, if you pass one.) DrawDialog doesn't do any erasing. I guess I don't understand the other case you mentioned, but I don't think any part of the toolbox other than the Menu Manager actually caches and restores any screen images. Type: Response From: Coach101 Date: 89-02-26 11:33:50 EST Re: Re: One Down.... Aha, it finally sinks in. The _erase_ action fits nicely with my deduction that what has happened is that the "data structures" say to not draw the enhancement (SetDefButton must have made that correction) but the enhancement was never erased! So, when you you just redraw the material that is supposed to be there (DrawDialog case) without erasing the enhancement (that the "data structures" say is not there) stays around. If anything surfaces to explain the AlertWindow case to me I will post a message back here; it may have nothing to do with AlertWindow, per se, but with what the state of things (i.e., what were between doing) are when the AlertWindow call is made. Thanks for the attention. Type: Response From: Dave Lyons Date: 89-02-26 14:28:22 EST Re: AlertWindow over a dialog Well, what is it that AlertWindow makes happen, again? When it goes away, whatever part of your dialog was obscured will be erased to your dialog window's background pattern and invalidated, just like RefreshDesktop does. (Actually, I wouldn't be surprised at all if the Window Manager is _calling_ RefreshDesktop with the rectangle for the window that went away!) I wonder what happens for nonrectangular windows, though...I guess I'll have to write one someday.... Type: Response From: Coach101 Date: 89-02-26 18:59:02 EST Re: Re: Alert vs. Dialog Case What happens is that I have a button that _is_ the default button but probably been through the InvalidateDItem wringer one or more times (I am not sure if I ever ran into the following situation when the button had not been through the wringer). Now the AlertWindow obscures the partially obscures the button (left hand 30% not touched, right hand 70% covered). When the AlertWindow comes up everything looks normal (i.e., the part of the button that can be seen has the default button enhancements). When the AlertWindow goes away, the entire area is reworked, and the left hand part (which was not obscured) has lost its default enhancement whereas the right hand part is re-drawn with the enhancement. Hmmm..... Now that I explain it all, the most likely situation would be that I did myself in... Nah, if I had done the EraseRect, I would have also issued the InvalRect... Anyway thats what was happening.... With Erase & Inval set to the _enlarged_ rectangle it all works and visual fidelity is maintained. Type: Response From: CompuWizA Date: 89-04-06 18:39:43 EST Re: Dialog Item Color Table Ptr. What does an item color table look like ? I can't find documentation about this in any Toolbox manual. Does it look like a regular color table ? Apparently not because when I tried to do that I got all sorts of colors that were not in my color table. I'm creating a dialog box with 16 radio buttons and I'm trying to make each one a different color. I'm writing in assembly and using Merlin 16+. ???CompuWizA???? Type: Response From: Dave Lyons Date: 89-04-06 23:38:27 EST Re: dialog item color tables You have to look up the color tabes in the Control Manager chapter. See page 4-16, 4-18, 4-20, 4-22, 4-24 for color tables for standard kinds of controls. Type: Response From: Matt DTS Date: 89-04-07 21:51:36 EST Re: Re: Dialog Manager Even better, see the System Disk 4.0 Release Notes and/or the Toolbox Reference Update. The Control Manager on 3.2 and later was enhanced to provide dithered color controls in 640 mode, giving 16 colors for using color values $0 -$F. --Matt Type: Response From: CompuWizA Date: 89-04-08 16:09:55 EST Re: Got It : Dialog Mgr. Bug Thanks guys. Now I have a bug to report : If you create two dialog radio buttons each with different colors and select the buttons in succesion the first selected will turn the same colors as the second. I think this is because the Control Mgr. routine for this does not change the drawing color to the button that is going to be turned off and _then_ set the color to the other button and turn on the selected button. CompuWizA Type: Response From: Dave Lyons Date: 89-04-09 00:47:31 EST Re: dialog mgr color table bug? CompuWizA, I'd like to see your code & try to verify the possible bug. One thing to check: does your color table remain in memory after it's used? I think it has to, so it shouldn't be a local variable in Pascal or an auto variable in C inside a procedure/function that returns before the dialog is closed. --Dave Type: Response From: Windrider5 Date: 89-04-25 21:10:16 EST Re: Re: Dialog Manager ParamText Could someone explain how the ParamText routine works, particularly with regards to how it can be used to hide or change text (instead of using the HideDItem routine) as stated on bottom of page 6-24 of the ToolBox Reference. ( a description in C would be appreciated). Type: Response From: AFL Dyfet Date: 89-04-29 10:40:34 EST Re: Re: Dialog Manager Subj: Dialog Manager 89-04-29 03:12:40 EDT From: PElseth Msgs: 1 (89-04-29) How can an application know which line edit item is active in a particular _modeless_ dialog window? I need to know in order to vary my character filtering according to the active le item. For example, supposing I had a modeless dialog which asks for a page header (which should allow any non-control characters), and a line number (which should only allow numbers and editing keys) - how can I filter appropriately for each (this is a contrived example)? This question may apply to _modal_ dialogs also. Does the itemHitPtr passed to a modal dialog filter contain the item number of the current le item if a key is pressed? Any suggestions would be welcome. -- Paul Elseth Type: Response From: SteveSand Date: 89-06-27 23:33:34 EST Re: Re: Scroll bars in Dialog I've been working tonight on using a scroll bar within a Dialog Box. I am using TML Pascal. I initialize the scroll bar with: NewDItem(FileDlogPtr,2,rect,13,nil,0,3,nil): I am having two immediate problems --- 1) The 'nil' in the middle of the paramenter list is supposed to be a pointer to a scroll bar control procedure. When I replace this with "@ScrollBar" (a procedure with currently nothing in it), I get a runtime crash. Am I referring to the pointer wrong? 2) I got around the initial problem by putting a GetDItemValue in a loop in my Dialog procedure. This works fine for telling where the the thumb is. I can drag the thumb OK. How do I tell if there has been a click in the Page Up area or in the scroll bar arrows? I have been reading the toolbox references; but, could sure use some suggestions on which direction to proceed. Thanks, Steve Type: Response From: Dave Lyons Date: 89-06-29 22:59:13 EST Re: scroll bar dialog action procs Gee, Steve, I *know* I already answered this question somewhere...must've been on comp.sys.apple. The second part of your question has an easy answer: your scroll bar action procedure is informed when the page areas and arrows are used. The crashes you're getting are becuase you haven't declared your procedure with the appropriate number of bytes of input parameters--they need to be removed from the stack before the procedure returns. Pascal takes care of this for you, but it has to know how many paramters there are. (You'll need them declared right anyway when it comes time to actually use them.) From page 6-15 of Toolbox Reference volume 1, you should declare your procedure like this: function myDialogScrollProc(code: integer; dlg: dialogPtr; itemID: integer): integer; (It doesn't say that explicitly in the book, by the way.) Be sure to turn on long global variables with {$LongGlobals+} in TML Pascal, or whatever is appropriate for your language, unless you will *not* be using any global variables during the procedure (or during anything it calls). The value of the Bank register is not guaranteed when your procedure is called. --Dave Type: Response From: SkipS Date: 89-09-18 22:31:52 EST Re: Re: Dialog Manager How does one go about using more than one font in a dialog? Like in the 'about..' diaglog. I'd like to have a large outline font for a title and the rest of the text as normal fonts. Thanks for any info... Skip Type: Response From: Dave Lyons Date: 89-09-19 20:47:36 EST Re: multiple fonts in About box One way is to use a LongStatText2 item, which can have all the same control codes for controlling styles/etc as LETextBox2 (see Toolbox Reference, Volume 1, Line Edit chapter). A less beautiful approach is to draw stuff directly into your window, which you know is going to stay in front (so you don't have to worry too much about updating it). --Dave Type: Response From: Windrider5 Date: 89-09-23 14:58:28 EST Re: Re: multi fonts in dialog I believe you might be able to use the SetDAFont routine (pg 6-79 in the ToolBox Reference manual. It requires a fontHandle which I'm not quite sure how you obtain. Type: Response From: Damien9 Date: 90-01-12 18:06:53 EST Re: Popups Any ideas on how to put a popup menu in a modal dialog? I'm writing in C and need to use a couple of these... Type: Response From: Damien9 Date: 90-01-12 18:08:31 EST Re: PopUp Menus Does anyone have any ideas on how to put a popup menu in a modal dialog? I'm writing in C and need a couple of these ... Type: Response From: Coach101 Date: 90-01-12 22:50:01 EST Re: Hmmmm.... I have not tried it but, a PopUp menu is an extended control and I will have to check, but does Dialog manager support Extended Controls? Type: Response From: Damien9 Date: 90-01-13 11:08:28 EST Re: PopUps in Dialogs Well, the Toolbox ref Vol 3 doesn't have anything to say about the dialog manager and extended controls, but I have seen it done... I just can't remember where.... Type: Response From: Damien9 Date: 90-01-21 12:55:37 EST Re: Popups Is it possible to use an extended control (i.e., a popup menu) as a userctlItem? If so, what would you use for a defproc? Type: Response From: WRH Date: 90-01-29 20:20:56 EST Re: _Alert Call Hangs--HELP I have a problem with Alert + Modal Dialog boxes and have run out of ideas to solve it. I realize the problem could be in many places but any suggestions on where to look are appreciated. I am using ORCA/M with System 5.0 (not 5.02). I have a reasonably complex desktop program with 5 windows, 13 Alert boxes, 6 modal DBoxes and 1 modeless DBox.(Generally only one or two are open at a time). Everything seems to work fine at this point. Next I added a subroutine I jsr to when there is no event found in the main eventloop. This routine does one of 3 things. 1. Update the info bar of the front window 2. Update several small portions of the front windows contents. 3. Draw a simple Alertbox. Upon completion of 480 loops through this routine another Alert box is drawn and the loop begins again. Well I wrote and coded #1 and #2 and the Alert box at the end of the 480 loops. All were debuged and worked just fine. Then I added the code for #3 and the program hangs on the _Alert call. No alert box is drawn and the computer is off in never, never land. I've triple checked the toolbox call and parameters passed -- I mean its only a simple alert box-- I also tried adjusting the order the routine does numbers 1,2, or 3 in but nothing seems to get it by the Alertbox and its associated hang from #3. If I leave #3 out altogther it draws the Alert box at the end of 480 loops fine. I then tried replacing the #3 alertbox routine with a modal D Box only to have similar problems. What is happening??? other than I am going crazy quite rapidly. ALL ideas appreciated. Many thanks WRH Type: Response From: Coach101 Date: 90-02-17 12:24:58 EST Re: Radio Button help in Dialogs The following message was moved from a different folder.... ----------------------------------------------------------------- Subj: Radio Button help in Dialogs 90-02-17 10:25:11 EST From: HaveGSPLUS Msgs: 1 (90-02-17) I have a problem. I can't figure out how to change a group number so I can place multiple sets of radio buttons in a dialog box. Can someone help? David White [ HaveGSPLUS ] Type: Response From: Coach101 Date: 90-02-17 12:26:11 EST Re: Radio Buttons.... Each group of radio buttons belongs to a family. If memory serves me correctly you need to avoid a family number of zero. You fill in the itemTemplate with an itemID (which MUST be unique with respect to all other itemIDs in the dialog) and a family number. The family number is placed in the itemFlag portion of the ItemTemplate. The DialogManager will take care of keeping only one button "depressed" at a time. Is that the information that you were looking for? Type: Response From: Coach101 Date: 90-02-24 11:51:05 EST Re: Dialog w/TML BASIC The following material was moved from a different folder... ----------------------------------------------------------------- Subj: Dialog w/TML BASIC 90-01-06 15:11:49 EST From: WTSBrian Msgs: 2 (90-01-06) I want to create a dialog w/TML BASIC that has textedit box items that you can while running the program, modify on the keyboard. The computer would then read the info you entered in the textbox and use it in the program. This routine is used in many gs programs and I would like to know how to do it so I can keep with the human interface standard in my program. Any suggestions... ----------------------------------------------------------------- Subj: TML Basic.. 90-01-06 17:18:44 EST From: DougMac Has TML Basic been updated to include the new system disk stuff? Otherwise you might have to set up some 'interface' file stuff first.. Next there is an assembly language example from Chris Hahn (sp?) that does a textedit as a control in a window.. Even has NDA that is an editor. I don't know if it is u/l on America Online though.. ----------------------------------------------------------------- Type: Response From: AFA Gary J Date: 90-09-05 00:31:43 EST Re: Icon Dialog Items (moved messages) Subj: Icon Dialog Items 89-10-07 21:44:17 EDT From: DwayneW Msgs: 8 (89-12-13) Can anyone explain how the Icon dialog item needs to be set up? I can't seem to find any explanation in the Toolbox Reference Guides, and the header information is the same in Lichty and Eyes "Programming the Apple IIgs in Assembly Language" and "Programmer's Introduction to the Apple IIgs." I did see the icon information in Quickdraw, but the section I read seemed completely different than the icons set up in both of the above books. I cannot figure out why there are two zero words in the header, nor what the next two words are for. I'm assuming the third and fourth words are the height and width of the icon in pixels. Can anyone clear this up for me and tell me where I can find the documentation on it in case I forget later? Thanks very much! Dwayne Williams Subj: Re: Icon Dialog Items 89-10-08 20:00:45 EDT From: Dave Lyons Dwayne, I believe Toolbox Reference Volume 3 (APDA draft) says the Dialog Manager doesn't actually support iconItem and picItem items. I recommend you put your icon in your dialog as a userItem--so you'd have a little routine that gets called by the dialog manager to draw your item, and your routine could just call DrawIcon. That way you can store your icon in the QuickDraw Auxiliary format. --Dave Subj: Re: Icon Dialog Items 89-10-09 23:02:18 EDT From: JonahS Am I right in assuming that the new 'extended' controls can't be put in a Dialog box? I tried putting them in the template, but that didn't work (crashed) and I tried adding them later (as TN #38 (?) shows with lists) but then they couldn't be selected. I edned up faking a dialog (by doing a _NewWindow2 call with the alertFrame bit set) and then writing a routine that acts just like _ModalDialog, but it was a pain. Is there a better way to do this? Jonah Subj: "faking" modal dialogs 89-10-23 03:43:32 EDT From: Dave Lyons Doing a modal dialog with NewWindow2 and TaskMaster (with a restricted set of wmTaskMask options enabled) is exactly the approach we recommend these days. --Dave Subj: Re: Icon Dialog Items 89-10-23 23:14:34 EDT From: JonahS :( (_ModalDialog is SOOOOOO much nicer) Jonah ubj: Modal Dialogs 89-11-05 17:37:05 EDT From: ChrisH01 First, this is 'ol Josh Thompson using AO from a friend's house... Anyways, I should be back on Tuesday or Wedsnday, and at that time I'll upload my routine that I'm using to fake modal dialogs with normal windows. I'm using it successfully in my packer right now. Subj: a customized icon 89-11-28 04:11:42 EDT From: DwightW1 I've noticed in many of the llgs games purchased that the creators will use a customized icon for the s16 file in a window opened by clicking their disk icon on the finder desktop. how does one create that customized icon which will appear in that window on the finder desktop.....hmmmmmmm????????????? dwightw1 Subj: customizing icons 89-12-13 01:01:24 EDT From: Dave Lyons Dwight, to create a customized icon you need an Icon Editor, such as IconEd or DIcEd (both Shareware and available for downloading in the AUT forum). DIcEd is by me (stands for Desktop Icon Editor, and you can pronounce it however you want, at least until I include digitized sound in the About box :-) . --Dave Type: Response From: AFA Gary J Date: 90-09-05 02:26:56 EST Re: Dialogs and Fonts (moved messages) Subj: Dialogs and Fonts... 90-05-03 01:07:09 EDT From: Kerry C2 Msgs: 4 (90-07-12) Here is the deal: I have set up a FontID called Font, and set it equal to Chicago 9 point, which is installed in the FONTS directory. I call the FMSetSysFont passing the Font, and it loads the font up nice and fine. It should use the font now instead of the system font, however, in my AlertWindow boxes with buttons, the text always overflows the button by a line, causing it to look not-so-nice. Is they a way around this or am I screwing things up somehow? Kerry Subj: Fonts & Buttons 90-05-05 18:53:00 EDT From: CodeMaster Did you try to redefine the boundries of your text that is placed within the button?Subj: Nope.... 90-05-14 22:23:03 EDT From: Kerry C2 No, I used the NewDItem so set up button, like 'OK' or something. Guess I'll stick to Shaston 8 :) Kerry Subj: SetDAFont? 90-07-12 21:36:53 EDT From: Dave Lyons Kerry, did you try uisng SetDAFont (in the Dialog Mgr) to set the font used by Dialogs and Alerts? It almost sounds like the system is using one font to calculate the sizes of things, and then using another font to actually draw them. --Dv Type: Response From: T McInroy Date: 90-11-10 20:39:41 EST Re: LineEdit Item I can put a lineItem Item into a modal dialog and put text into it, but I can't get text back out, what am I Missing? Type: Response From: Mac Hater Date: 90-11-10 21:10:32 EST Re: GetIText look on page 6-56 of TB ref vol 1. Type: Response From: T McInroy Date: 90-11-11 22:08:03 EST Re: EditLine Thanks, I thought I was missing something obvious.