CEGUI (Crazy Eddie's GUI) Forums

Thanks for the nitpicking Timo ;-) I have actually run into such problems and have solved them by scoping the macros with just {}, does this approach (do {} while(0)) have any advantages over scoping? Thanks.. Only the advantage that you can (and you have to) always put a semicolon after it, wherea...

Just some nitpicking about the macros in Kulik's patch... :) - delete[] operator destroys the elements in reverse order, so I think just for consistency CEGUI_DELETE_ARRAY_T should do the same. - Bad things will happen if someone uses CEGUI_DELETE_T or CEGUI_DELETE_ARRAY_T inside an if...else statem...

Sorry but you need to be more specific (or CrazyEddie will get mad!!). Nobody can help you if you just say "doesn't work". If you're getting some compiler or linker errors, post them here. If you have problems when running your application, describe them and post your cegui.log. Also, you ...

The first step is to define all windows in absolute coordinates. In the editor you set the offset value in pixels and set the scale to zero. In program code you use UDim(0, 200) instead of UDim(0.25, 0) etc. The scale coordinate still comes handy in some situations, like if you want to align the win...

Cool, thanks!

Okay, I wanted to compile my project in VC9 with _SECURE_SCL=0, but I found out that it doesn't create compatible code (iterators have different size etc). Thus, all libraries used in a program should use the same setting. And I can do this for everything else except the precompiled dependencies for...

I'm 95% sure this has been fixed in the SVN version and latest snapshots.

Oh Eddie, you should release 0.7.2 already.

edit: ok, I see it's coming soon...

I think that CEGUI should at least have support for unicode filenames on Windows. Yes, users can derive their own classes, but since unicode support is such a key requirement nowadays, this functionality should really be part of the CEGUI library. Function arguments could still use CEGUI::String, bu...

You can change it by calling the setProgress() method. It takes a parameter between 0.0 and 1.0. Or you can use step() to move it one step at a time.

Cool. But as I said you probably want to update CEGUI if you want to use a rendering surface for the FrameWindow. It makes rendering a lot faster.

Have you tried any of the newer versions of CEGUI, either from SVN or one the snapshots? Because this kinda looks to me like the bug with Irrlicht renderer that was fixed some months ago. (Updating the FrameWindow causes the RTT to be redrawn which also clears the main buffer even though it shouldn'...

Hmm, I didn't quite understand. Could it be that you're talking about this issue? When you're resizing a framewindow the render target gets reallocated and moving the mouse quickly may cause slowdowns/stuttering.

Here's something I've been using to fix this issue. It's a horrible solution from performance point of view, but it's better than having background colors bleed through the RTT surface, which imho is unacceptable. What it does is it renders everything twice using different color masks. First the col...

Well that's really weird. If you did build it then it should now use D3dx9d_42.dll. (or whatever version you have)

So, all I can say is, make sure you built the right configuration (debug vs. debug_static), and that your project is actually using the new lib/dll you built.

So it still asks _40.dll after compiling CEGUI with latest DXSDK?