Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Andy Bettis <email@hidden>
- Date: Thu, 16 Jun 2005 08:50:38 +0100
Hi Steve,
Having the first window on top is, I'm afraid unacceptable. Either it
remains inactive, in which case it looks like the app is broken, or it
becomes active and the user can spawn another dialog from it, which
means the app really is broken.
Perhaps I was just unlucky to hit this with my first Cocoa app, but it
does seem like UI has slipped from Apple's priorities. Have interface
guidelines become mandatory? As this sort of behaviour works fine under
Carbon it looks like there has been an active decision to remove it, or
at least to support it in a half-assed way.
Oh well, back to the drawing board. Let's hope Metrowerks produce an
IDE that works under Leopard.
Rev. Andy
On 15 Jun 2005, at 15:37, Steven Kramer wrote:
I simply open two modal panels (one runModal is triggered inside the
first). This still allows me to drag the first modal window.
Unfortunately, it also allows the first one to come on top. If that's
acceptable, it should be easy...
Op 15-jun-05 om 15:51 heeft Andy Bettis het volgende geschreven:
After browsing around the documentation and various archives it seems
that Apple really, really don't want people to use non-sheet modal
dialogs and that there are bugs in the OS that mess up the window
ordering of multiple modals even if you do code them correctly.
Assuming this is so (and please someone tell me if it's not) then I'd
like to ask for advice in how to lay out my UI without using modals.
I'm working on a simple accounting package. The main window shows a
list of transactions with subtotal and total lines. If the user
double-clicks on a transaction a modal dialog appears showing the
details and allowing them to be amended or deleted. Validation is
performed and updating carried out if the user clicks on OK (the
default button), the dialog just goes away if cancel is clicked. A
menu item allows new transactions to be input, in which case the same
dialog appears but with blank or default values. When a valid new
transaction is entered the fields are cleared but the dialog remains,
so many transactions can be added without needing to call up the
dialog box again and again.
In theory I could do this with a sheet. However being able to move
the input dialog away from the main window allows the existing
transactions to be viewed, which is very useful and something I doubt
the client would be willing to give up.
There's more. Each transaction is assigned to a category. There is a
menu item that brings up a modal dialog showing a list of the
categories, and by double-clicking on an entry in the list another
modal dialog is displayed allowing the selected category to be
edited. Again, having the dialogs be movable means the user can see
the existing items, and anyway I believe that having sheets upon
sheets is frowned upon by Apple too.
Having non-modal windows makes the updating of data very messy. If,
for example, I had a spreadsheet-lloking table for my transactions
where users could change the data directly when do I perform the
validation? If the user changes an income entry to expenditure it may
be that the associated category does not allow expenditure. If the
category is changed it may impose limits on the amounts that can be
used. Having a modal dialog means that cross-field validation can be
done when all the fields have been amended, allows for a much clearer
audit trail, and makes it very clear what has been comitted to file.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden