Don't annoy me again!

[Alpha]

Annoying dialogues a great, however I think in most cases, the user expects the dialogue to remember their choice when they dismiss the dialogue (ex. here), not use a default value.
Of course, for some situations (rebuild confirmation, clean project confirmation, ...) this does not make sense (as that could make the rebuild button useless).

I want to allow annoying dialogues to be (optionally) set to remember what the user clicked when they dismissed it.  Any thoughts on this?

[oBFusCATed]

Any thoughts on this?

Go on and show a patch, so we can discuss the implementation.

[Alpha]

Oops, I forgot I was working on this.  Here is a patch.

[oBFusCATed]

1. ADRet is quite confusing, something longer should be used here. Being verbose is no such problem.
2. AD_SAVE_CHOICE should be a constant and it should not be in the header
3. Mixing eol changes with other changes is not good!
4. Converting wxID_????? to string is dangerous, you should define your own constants.
    Probably an enum, which is stable with different versions of wx.
5. Some comments are needed in regard to the formatting of the string. BeforeLast and After
6. What will happen if you use older C::B with newconfig? Probably you should use another config path.

[Alpha]

1. ADRet is quite confusing, something longer should be used here. Being verbose is no such problem.
[...]
5. Some comments are needed in regard to the formatting of the string. BeforeLast and After

Will do.

2. AD_SAVE_CHOICE should be a constant and it should not be in the header

It is in the header so other files can use it:

Code

AnnoyingDialog dlg(_("XYZ question?"), msg, wxART_INFORMATION,
                   AnnoyingDialog::YES_NO, AD_SAVE_CHOICE);

Is static const int the preferred type?

3. Mixing eol changes with other changes is not good!

Oops...
I see, I format.  Bad habit.

4. Converting wxID_????? to string is dangerous, you should define your own constants.
    Probably an enum, which is stable with different versions of wx.

The problem with defining my own enums, is that the parameter for default return type could *technically* be any number (not just the specific ones I registered).  How should I handle an unknown return type?  Currently, I always save the default type when AD_SAVE_CHOICE is not specified.  This is so it will show up in the dismissed dialogues box with the choice it will use.

6. What will happen if you use older C::B with newconfig? Probably you should use another config path.

Don't.  Unless you want to be annoyed, because all the annoying dialogues will pop up again.

[oBFusCATed]

2. What is the purpose of this param then? Doxy comment please.
   Static here is inappropriate, you want external linkage here.
   If I were you, I'd made it enum in the AnnoyingDialog class. So people will have to use something like AnnoyingDialog::SaveChoice
4. Probably add AnnoyingDialogChoice::Unknown
6. People will do this and they will get annoyed, you have to think of a way to handle this (Me included).

[Alpha]

2. What is the purpose of this param then? Doxy comment please.

No documentation available yet; here is the constructor's signature:

Code

        AnnoyingDialog(const wxString& caption, const wxString& message, const wxArtID icon = wxART_INFORMATION,
                       dStyle style = YES_NO, int defaultReturn = wxID_YES, bool separate = true,
                       const wxString& b1 = wxEmptyString, const wxString& b2 = wxEmptyString, const wxString& b3 = wxEmptyString);

   Static here is inappropriate, you want external linkage here.

Hmm... looks like I have some reading to do.  (My C++ knowledge appears to be rather incomplete.)

   If I were you, I'd made it enum in the AnnoyingDialog class. So people will have to use something like AnnoyingDialog::SaveChoice
4. Probably add AnnoyingDialogChoice::Unknown

My preference would be to switch int defaultReturn = wxID_YES to an enum (for example: dReturnType defaultReturn = YES).  However, I had been attempting to leave the API unchanged (so plugins would not need fixing).

6. People will do this and they will get annoyed, you have to think of a way to handle this (Me included).

This can be solved by reading from both the old and a new settings path, but only writing to the new path.

[oBFusCATed]

My preference would be to switch int defaultReturn = wxID_YES to an enum (for example: dReturnType defaultReturn = YES).  However, I had been attempting to leave the API unchanged (so plugins would not need fixing).

I have no problem with this. Probably you have to make sure that passing wxID_YES causes a compile error.
So, incorrect usage can be detected and fixed.

This can be solved by reading from both the old and a new settings path, but only writing to the new path.

This is an option, yes.

[Alpha]

Attached are the changes I am thinking.  (Patch not yet functional, as I have not fixed any uses of AnnoyingDialog; I will probably get to that tomorrow.)

[thomas]

Of course a good alternative would be to remove half of the annoying dialogs altogether

[MortenMacFly]

Of course a good alternative would be to remove half of the annoying dialogs altogether

...stated by the one providing this dialog initially...

[thomas]

Of course a good alternative would be to remove half of the annoying dialogs altogether

...stated by the one providing this dialog initially...

Life isn't fair, alas. I wrote that class to provide a means to hide the many useless dialog boxes that Code::Blocks was full with after seeing them once (the yellow notification windows were made for a similar reason). However, despite the class being named "Annoying" to give anyone using it a discrete hint, this only led to more useless dialog boxes being built in. As in, if someone finds them annoying, they can turn them off...

It is my belief that users are not completely stupid, and more noise is not necessarily better (especially if it's modal dialogs). If you search for something and nothing happens except "bing", it's not necessary to bring up a dialog that says "nothing found, please click OK". If you click the rebuild button, nobody needs to tell you that this will take a long time, you already know (and if you don't know yet, your project probably consists of a single source file, so the statement is not true). If you use several compilers, you should already know enough about the matter so you need not be told "it's a good idea to do a clean rebuild now" when switching.

[MortenMacFly]

(Patch not yet functional, as I have not fixed any uses of AnnoyingDialog; I will probably get to that tomorrow.)

I fixed the use of this all-together so that it compiled. However, unfortunately the annoyingdialog is completely screwed afterwards. Any news on that front? Otherwise I would revert the changes in my local copy.

[Alpha]

I also changed the return type to use the new enumerated values, so a straight compile fix will not work.  I can change it so it returns the wxId's, but that, in my opinion, is less clean.  Most of the necessary changes (for app and core plugins) are done on my computer at home.  I will upload them later today.

[Alpha]

Attached is the conversion of the core (app & plugins).  This is a direct conversion (rtSAVE_CHOICE is not used yet), so all dialogs *should* still act the same.