the conflict of window name

[beyondlwm]

I'm new in using CEGUI.
I found that, if I have two pages, each page has a button which got the same name ("OKBtn"), there will be a conflict in WindowManager::d_windowRegistry
In fact, I think it's quite common to generate some UI components with the same name, however, it seems I can't do this in CEGUI, even if I call CEGUI::removeChildWindow

by the way, I'm not willing to destroy the old page, because I want the two pages show at the same time.
So, My current solution is adding a prefix like "XXXPage_OkBtn", is it the only way out?

another problem is about CEGUI::String, it is built in utf8, but I can't construct it with a wchar_t* or std::wstring, it means, if I am working in unicode, I have to convert Unicode to Multibyte, then construct a CEGUI::String with it back to utf8? I hope there will be a better way.


Thanks for reading ,any reply will be helpful.

[Kulik]

We have changed this name behaviour in 0.8 where all widgets have relative names that only have to unique in the parent.

As for the CEGUI::String, I think there are some helper functions for this but perhaps they aren't exposed. Anyways I would advise not to work with wchar and wstring, they are 16bit on Windows but 32bit on Linux AFAIK and all in all are just problematic.

[beyondlwm]

Thank you for your reply

However, why not implement a contructor for wstring? becuase it is encouraged to work in unicode environment, So ,it will be very easy to write like CEGUI::String Test("test") under unicode project rather than CEGUI::String Test(UnicodeToMulByte("test")). Is it possible to do some marco stuff to solve wchar_t is different in some other platforms issue?

[Jamarr]

why not implement a contructor for wstring? becuase it is encouraged to work in unicode environment, So ,it will be very easy to write like CEGUI::String Test("test") under unicode project rather than CEGUI::String Test(UnicodeToMulByte("test")).

Because this unnecessarily couples CEGUI::String to std::wstring. Should std::wstring change significantly (I know, unlikely) and/or the method used for conversion (also unlikely) then these changes, unrelated to CEGUI::String, would still require changes within CEGUI::String's implementation. This would decrease cohesion in CEGUI::String since it's responsibilities would be expanded to include conversion-implementations, which is beyond the scope/purpose of this class. This would open a whole can of worms that is best avoided. OOP does not mean throw everything related to an object into the object - that is a failure in understanding OOP.

Now that does not preclude the CEGUI library from providing an external string-storage conversion module, for example providing an external CEGUIStringToWString, etc. And providing these facilities for standard string-storage formats is probably a good idea. However, it is not as if it is difficult for clients to provide these facilities themselves. There are a number of libraries and os-specific methods to aid in performing these conversions.

I have heard that in CEGUI v0.8+ that CEGUI::String will be substitutable for std::string. That being the case, I assume it would be trivial to substitute other std::string compatible interfaces such as std::wstring. That said, I am not sure of the implications of switching the underlying format from multibyte to widechar.

[beyondlwm]

Hi Jamrr,

I've read your reply twice, that's a great viewpoint and I'm quite agree with you on understanding OOP.
In fact, I don't think change the structure of CEGUI::String to apply more function is a good idea, As you said, that's not string's responsibility. As an user, I will care more about if the interface is friendly, So what I mean is, can we do some stuff like windows:

#ifdef UNICODE
#define OutputDebugString OutputDebugStringW
#else
#define OutputDebugString OutputDebugStringA
#endif // !UNICODE

As you can see, for me, I just need to know the function (in fact it's a marco) OutputDebugString, and I don't care about if it is unicode. Since it's two different functions, it will not impact the cohesion.
If some day I can call the CEGUI API in both Unicode and Multibyte mode with SAME SOURCE CODE, that would be a nice thing.

And I also do some hack stuff to force CEGUI::String to build an utf-8 data when it's raw data assigned, although it will decrease the speed, that can help me debug when I need to know the "real value", it seems I need a "Developer-version"

At last, thank you for your help! CEGUI is a greate open source lib, thank all those programmers.