Login
`
Templates, Tools and Utilities
|
||
Add a comment to an Icetips ArticlePlease add your comments to this article.
Please note that you must provide both a name and a valid email address in order
for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!
Back to article list Search Articles Add Comment Printer friendly Direct link Par2: Delete: Sequence of events 2003-05-25 -- Michael Ware The delete message is getting issued from a call to the file's Relation
manager in the Window's PrimeUpdate method. The actual chain of events is:
1. The Window's Init call's the PrimeUpdate
2. The Window's PrimeUpdate calls the Relation Manager's Delete
3. The Relation Manager's Delete calls the File Manager's Throw
4. The File Manager's Throw calls the ErrorManagers Throw
5. The ErrorManagers Throw calls the ErrorManager's TakeUser
6. The .TakeUser pop's the message with the Yes button hardcoded as the
default.
I skipped a few in here, but this is the general flow.
The easiest option would be to change the window from "Standard Warning" to
auto-delete, and issue your own message in the window's PrimeUpdate before
the parent call, if the user responds "No" set Self.Response to
RequestCanceled and return Level:Fatal.
If you want a more global solution, you can either directly modify the
ABError.clw to default all user level messages to Button:No, or subclass
either the error, file, or relation managers to suit your needs.
Today is November 23, 2024, 2:18 am This article has been viewed 35208 times.
|
|