standard dialogs captions

[Troels]

 > T> wxMessageBoxCaptionStr = wxStrdup(_("Message")));
 >  This was *never* supported.

Sure was, up until 2.7.0.
Seen working with several compilers (gcc 3.4.5, MSVC6, MSVC2003), using 
both static and dll wx builds. Not sure about other platforms though.

 >The above is not flexible

Sure it's flexible.

 > just a dirty hack which happened to work by chance before.

Only dirtiness here is wx exposing a global/public variable - which is 
not much dirtier than say

     // Gets the global resources object or creates one if none exists.
     static wxXmlResource *Get();
[global function slightly disguised as member function, have very very 
many cousins all over wx/include/wx]

 > directly changing a private variable is not the right way to do it.

A matter of individual taste. Apparently whoever originally created 
wxMessageBoxCaptionStr disagrees with you :)

 > T> ...Translated or not, the default caption "Message" is not likely
 > T> to please many.
 >  I agree with this and I also think we should allow customizing

Thanks. While looking for an ideal solution, rolling these few lines 
back to 2.6 state would sure be appreciated in some quarters :)
(const char wxMessageBoxCaptionStr[]
-> const char* wxMessageBoxCaptionStr etc)

Regards



Vadim Zeitlin wrote:
> On Wed, 01 Nov 2006 10:55:06 +0100 Troels <tk at tk.tk> wrote:
> 
> T> Before 2.7, you could control the message box default caption, like this
> T> wxMessageBoxCaptionStr = wxStrdup(_("Message")));
> T> or
> T> wxMessageBoxCaptionStr = wxStrdup(GetAppName());
> 
>  This was *never* supported.
> 
> T> In 2.7.x, it's hardwired to wx("Message").
> T> 
> T>  >I don't believe these messages were ever
> T>  >supposed to be modifiable from outside the library.
> T> 
> T> Flexible is better...
> 
>  Flexible API is better. The above is not flexible, but just a dirty hack
> which happened to work by chance before.
> 
> T>  > But they should indeed be translated.
> T> 
> T> ...Translated or not, the default caption "Message" is not likely to 
> T> please many.
> 
>  I agree with this and I also think we should allow customizing this but
> directly changing a private variable is not the right way to do it.
> 
>  Regards,
> VZ
>