nicky@cup.portal.com (nick john pilch) (06/12/89)
I posted a request for help to this newsgroup a few weeks ago. It concerned a problem I was having with the filter proc of a modal dialog. It was getting too many update events, they just wouldn't stop coming. A coleague was having a similiar problem with a dialog he was working on. Through investigation, some trail and error, and help from Mac DTS, we seem to have solved the problem although the solution is still non-obvious. I was drawing the default border for the OK button in the filter proc, whenever an update event would come by. MacDTS told us that we should rather be doing it with a userItem proc. That's when it hit us that if we did ANY drawing in the filter proc itself, our update events got screwed up. Sure enough, when we took all drawing code out of the filter proc and put it into userItem procs, we were cool. But why? Why should drawing during "filter proc time" screw up our update events? That's what we'd like to know. There is another common situation where something like this could happen that might be hard to diagnose. It was pointed out to me by someone who had this happen to him. Imagine this scenario: You have a plain window in your application. You then pop up a modal dialog. Now another dialog comes up on top of that one. It turns out that if your second dialog partially obscures the regular window that is beneath it both dialogs, you will get the update events for that window whether you want them or not. Anyway, I was curious as to whether or not anyone has ever seen the first situation I described and can explain why the dialog manager would get confused by drawing inside a filter proc Nick Pilch Mountain Lake Software nicky@cup.portal.com AppleLink: D1036
tecot@Apple.COM (Ed Tecot) (06/20/89)
In article <19379@cup.portal.com> nicky@cup.portal.com (nick john pilch) writes: >I posted a request for help to this newsgroup a few weeks ago. It concerned a >problem I was having with the filter proc of a modal dialog. It was getting too >many update events, they just wouldn't stop coming. A coleague was having a >similiar problem with a dialog he was working on. Through investigation, some >trail and error, and help from Mac DTS, we seem to have solved the problem >although the solution is still non-obvious. > >I was drawing the default border for >the OK button in the filter proc, whenever an update event would come by. >MacDTS told us that we should rather be doing it with a userItem proc. That's >when it hit us that if we did ANY drawing in the filter proc itself, our update >events got screwed up. Sure enough, when we took all drawing code out of the >filter proc and put it into userItem procs, we were cool. But why? Why should >drawing during "filter proc time" screw up our update events? That's what we'd >like to know. I'd guess that your filter proc was returning TRUE, instructing the dialog manager to not handle the update event. _emt