CEGUI (Crazy Eddie's GUI) Forums

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.

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.

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?

beyondlwm wrote: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.

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.