Version: 1.0

Posted: 2003-01-30

Build Requirements: N/A

Runtime Requirements: Carbon

View Source Code:

Download Sample (“stdFilterHacking.zip”, 12.4K)
Download Sample (“stdFilterHacking.dmg”, 74.9K)



Description

For those of you who have been using the new Standard Dialog Filter in 7.0 and later (TechNote 1147 Pending Updates Perils) you may have encountered some odd behaviour when you bring up another dialog or alert in front of a dialog using the standard filter. If you have dimmed (de-hilited, disabled) the OK or Cancel button and bring up a dialog on top, when you dismiss the top dialog the dialog where the OK button was dimmed will suddenly have the OK button enabled! This is a behaviour of the standard filter. When the standard filter gets an Activate event, it will automatically enable the default and cancel buttons (set with SetDialogDefaultItem and SetDialogCancelItem), it is assuming that the only reason those buttons were disabled was because they were in a deactivated window. The filter has no state-saving routines or caches to remember what the old state of the buttons was, so it just slams them active again. This may not be what you want. If you disable an OK or Cancel button, use the standard filter, and bring another dialog or alert up on top of that dialog, you need to add a little extra code in your own filter to handle that situation. The code is included here, look in the filterIt function included in stdFilterHacking.c.

Document Revision History

Date Notes
2003-01-30Demonstrates problems and workarounds for/with the Standard Dialog Filter.

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.