Re: Re: CvsAlert changes

Jens,

>I'd prefer not to try and guess the default button, but rather
>always have the OK button the default button.

It may be a little bit dangerous. The current logic is assuming a single OK
button for a note type of message and Cancel default button for question and
error messages. The OK will be default for warnings. That choices seem quite
reasonable to me at the moment but I am open for discussion here.

>Instead, we might introduce a subclass of CvsAlert, e.g.
>CvsCriticalQuestion that will take a message as argument and
>make the cancel button the default. That would be just as
>convenient, but would leave some defined behavior in the base class.

I think we don't need to make a new class for that. I have two ideas here:

1. Change our kCvsAlertIconType and for example add two question types to
control the default button. That would make sense as it would indicate the
importance of the message at the calling place. But we have to remember not
to introduce too many of these to avoid confusion.

2. Create an overload or change the signature of CvsAlert::ShowAlert method
and pass the default button there. E.g. overload:

kCvsAlertButtonType ShowAlert(const kCvsAlertButtonType defaultButton)
{
    m_defaultButton = defaultButton;
    return ShowAlert();
}

Somehow I like the overload more that having the default parameter added to
the current method. If we used the default parameter we would probably have
to define the "neutral" alert button type to indicate that we want to keep
the one selected in constructor.

Any of the above allows to override an automatically selected default button
quite easily.

>P.S: I changed the Mac implementation of AskYesNo and
>ConfirmMessage to use CvsAlert and I think this could probably
>become cross-platform (except for a small portion in AskYesNo
>where MacCvs makes sure the log window is visible and frontmost
>so it can be read behind the alert).

Just FYI: I am planning to eliminate the AskYesNo and place the code
directly into the AppGlue where it's called. After all it's just a couple of
lines and doesn't deserve to be a function!

I want to limit the number of functions doing essentially the same thing -
showing the alert message. The next candidate is obviously PromptMessage and
maybe even PromptEditMessage.

>O.k., I've conditionalized the code to set up the button titles
>in MoveToTrash code. (Confirmation dialogs should just never
>ask with "Yes" / "No" on the Mac according to the UI guidelines)

Can you provide some link to those guidelines? (sounds like I better read
that before my next move ;)

In fact if Kalle agrees we could all use the OK/Cancel for moving to trash
question. Even thought the Window OS uses Yes/No for the same I can see how
it can be more intuitive with OK/Cancel.

Best Regards,
Jerzy

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/