CEGUI (Crazy Eddie's GUI) Forums

Hi,
I've upgraded to OGRE (Shoggoth) and CEGUI (v. 0.6.2) recently and got some probems that I cannot solve.
Always when I click on a menu item the application crashes on the method CEGUI::System::.injectMouseButtonUp(...);.
I've tried a lot of things but nothing helps. Are there any big changes in CEGUI done that cause such a behaviour?
Thanks.

Hi,

Which version of CEGUI did you upgrade from?

Which OS / Platform?

Which compiler are you using? Are you using pre-built binaries?

Is there a handler subscribed to the menu items? Is this C++ or lua or something else?

When you say it crashes, what is the error exactly? Are there any errors - especially at the end - in CEGUI.log? Can you surround your CEGUI code in a try/catch construct and catch any CEGUI::Exceptions and output the error?

If it's not a CEGUI::Exception, but maybe a segfault / access violation, can we see a backtrace / callstack and any other relevant debugging information?

CE.

Hi, thank you for the reply

I'm using CEGUI under windows, msvc and I have upgraded from version 0.6.1 (pre-build binaries). The menu is created via CEGUI editor.

Unfortunately, try/catch construct throws no exceptions at all. And the logfile too doesn't point to any errors.

Here the method that invokes the error-prone function:

ConvertButton just converts the OIS mouse buttons to CEGUI Mouse buttons.

If I run the application in debugger, this error emerges (I translated it from German):

unhandled exception at 0x0237b4a6 in XXX.exe: 0xC0000005: access violation reading at position 0x000005fc.

The strange thing about this issue is that I can run the application succesfully with the older 0.6.1 CEGUIBase.dll althought I built the app with the new 0.6.2 CEGUIBase.lib

Thanks for the extra info, I don't have any insight right at the moment, so I'll try to run some tests tomorrow and see if anything comes up.

Although it seems you should not be affected, did you upgrade to the reissued 0.6.2b and try that?

Also, no chance of seeing a callstack from the point it dies, then?

CE.

I got around to testing this a little today, but was unable to reproduce any issue. Here's what I did:

Download Ogre source & dependencies
Build Ogre.
Download CEGUI SDK
Overwrite CEGUI headers, libs and DLLs in the Ogre tree with those from the CEGUI SDK.
Rebuild Ogre renderer module (and the samples that use it - for testing purposes)

All was ok. I'm also able to interchange 0.6.1 and 0.6.2 DLLs successfully without any issues (not including the lua module, that does require a rebuild of the client app).

CE.

Hi, thanks for your help
I appreciate it

Unfortunately it could not solve my problem with the menu construct
I've dealt now some more time with the issue and found something that could help. For some time past I went throught this tutorial and found out that my application crashes in the debug configuration. Now, with the new 0.6.2 CEGUI release it crashes even in debug configuration when I click on one of the menu items.

Quote from the tutorial:

The demo subscribes to the MenuItem::EventMouseEnters event for two features. The first is to display a message when the mouse hovers over a menuitem. The text displayed is stored within the Tooltip property within the Layout Editor. The second is to automatically open a submenu. This code is within the onMouseEntersMenuItem() function.

The code to automatically close a menu (when the mouse leaves) is within the onMouseLeavesMenuItem() and onMouseLeavesPopupMenuItem() functions, called in response to a MenuItem::EventMouseLeaves event.

As mentioned, the code shown in the tutorial lets the menubar open its menu item entries automatically.
Without these both event functions (from the tutorial): - onMouseEntersMenuItem and onMouseLeavesMenuItem - the aplication runs well.

Conclusion: it has something to do with the both functions ::openPopupMenu and ::closePopupMenu that were changed in the newest release in some way and that manipulate this method CEGUI::System::getSingleton().injectMouseButtonUp to make the application crash.
I think the best bet would be to dispense with the automatically opened-menu-items although, this functionality is very comfortable

cu

Hi,

Thanks for the new info, this is actually really helpful as it gives me more of an idea as to what you're trying to do, amongst other things.

With regards to changes to the menu components between 0.6.1 and 0.6.2, there were none.

I suggest the issue is most likely that you have some uninitialised data somewhere in your code. When using the new CEGUI DLLs the overall memory layout has probably changed slightly within the app, so what was once a lucky 'safe' value, is now no longer safe and so you're seeing the crash.

You mentioned previous issues in debug mode (presumably this is why you couldn't generate any decent debugging information for us to look at?), which reinforces the above suggestion; differences in debug / release configurations are usually highly indicative of issues relating to uninitialised data (because VC++ does different things under debug than it does under release - the idea being to force a crash in debug mode so you can fix it, not so you can ignore it and use release mode instead!).

I'm not sure if this comes across as being a harsh response. That's not the intention, the intention is to help you find the cause of the issue

CE.

Hello,

I can approve the problem that Progger described. I get exactly the same error when using some of the code from the MenuAndPopup tutorial.

When clicking on a MenuItem, it seems that the OnMouseLeavesMenuItem() event is processed first (which closes the popup menu) and returns fine. After that a segfault occures. My OnMenuItemClicked() call-back method is never called.

I have a backtrace here, using gdb on linux.


So I experimented a little with my code and found out, that if I change

to

in OnMouseLeavesMenuItem(), the segfault does not occure. However, the popup menu won't open the next time I hover the mouse over it or click it. I first have to open another popup menu from the menu bar first. To my understanding, this seems valid behavior, because the parent is not notified about it. But this is not a fine solution to the problem...

I didn't take a look into the CEGUI code, but maybe the internal mouse clicked event handling doesn't check if the menu was already closed?!

Greetings,
mijikenda

Hi, and welcome

Thanks very much for posting your experience with this issue, and - most importantly for me - the backtrace; this is the essential piece of missing data from the earlier report

I'll add a ticket in order that this can now get looked into more thoroughly and fixed.

CE.

I just compiled CEGUI from scratch to get the line numbers in the backtrace:



Unfortunately, I won't have the time to dig into other people's code deeply in the next weeks. So it's up to you (or someone else) to fix it...

Thanks again for the extra info.

mijikenda wrote:So it's up to you (or someone else) to fix it...

No problemo, it should get done this coming weekend.

CE.