Craig,
We have some extensive modifications of the out-of-the-box Attribute Dialog. I'm unsure of whether what we have will be of help to you, but I'll share a pertinent part of it in the hopes that it is.
From your message, it sounds like you're already aware of how to set up a call back for the OK button processing on the attributes dialog, so I'll skip over that.
Here's the ACL code for our OK button processing relating to what we refer to as a help_id attribute. You'll see from the comments within the code that we've found the OK button processing to be messy and somewhat unpredictable business. But what we have works well enough to allow us to avoid having to code up an modify attributes dialog of our own.
#######################################################################
# FUNCTION: helpID_attribute_OK_cb
#
# Handle OK processing
#
# Parameters: win - A handle to the dialog
# dlgitem - The ID of the element
# event - The event
#######################################################################
function helpID_attribute_OK_cb(win, dlgitem, event) {
###########################################
# Currently, there's a big problem with this callback in that the OK button on the Modify Attributes dialog
# does not signal the ITEM_CHANGED event at all over the course of it being clicked on to exit
# the dialog with an OK selection. Instead it only signals the ITEM_FOCUSED and ITEM_UNFOCUSED events
# in an unreliable sequence depending on which other windows are focused or not before and while one actually
# clicks the OK button to exit the dialog. The unpredictable sequnce makes it impossible to accurately detect
# when the user actually clicks the OK button to exit the dialog.
#
# We do know that the OK button will have several spurious ITEM_FOCUSED events occur for it as part of
# starting the dialog and that it seems to be the dialog item that initially receives focus.
# So, to attempt recognizing when the user clicks OK to exit the dialog, we only react to ITEM_FOCUSED
# events which occur after we've once had the OK button lose focus. Then, we validate any non-blank
# value in the helpID field to ensure it doesn't look like an eid value. There are scenarios where
# our validation could be triggered even though the user didn't actually click the OK button. But,
# since we only complain to them about a bad value it shouldn't really matter if we complain a little
# more than we should.
# Just return until we see an ITEM_UNFOCUSED event go by
if (!$XIS_MODATTR_HELPID_OK_UNFOCUSED_EVENT_OCCURRED[win]) {
if (event != "ITEM_UNFOCUSED") {
return;
}
else {
# Set a global variable for this window to remember an unfocused event occurred.
$XIS_MODATTR_HELPID_OK_UNFOCUSED_EVENT_OCCURRED[win] = 1;
return;
}
}
# Now that we've processed an ITEM_UNFOCUSED event, we'll only verify the helpID field value when the OK
# button regains focus.
if (event != "ITEM_FOCUSED") {
return;
}
# Following routine call, verifies help ID value and if bad, warns user and resets value back to a good value.
helpID_attribute_processing(win)
}
Hope this is of help. Feel free to follow up with any questions you may have.
