[SOLVED]Can't suscribe event? Font not found in collection?

[DozyHole]

Hi Jamarr,

I can't thank you enough for the time you have put in helping me, when it comes to dll's vs libs, static vs dynamic I'm just completely lost:)

I think you could be right, I am taking your advice and starting again with the pre-built version, there is a good chance I am mismatching as I downloaded alot of stuff, I am more clued up now on the process and what is needed etc.

The reason I was going to install VC++ again is because somewhere in this whole process I started getting messages about 'line endings' when starting up a project, when I agreed to change them it removed all my default header files from VC++ Diectories:(, I think I put enough of them back again but can't be sure. I am thinking this wont be the reason for my issue as I had the issue first and surly I would get a compile/linking error if something important was missing.

I'm just on a mess right now, you should stay away in case its infectious:)

I will post back when I have tried what you suggest, thanks again.

[Kulik]

Hehe, I will insert spoiler alerts next time

The reason why I wrote it was that even though I gave the advice to check that headers & libs match in the older thread it didn't cross my mind in this thread My mind is obviously flawed.

[DozyHole]

A twist in the tale:)

I tried what Jamarr suggested but same result, unhandled exception in the same place. But, I tried it in release mode and it works:):):).

So even though its not solved I can get on with learning the SDK which is great.

Anyone have any idea why this may be so? Could it be some compiler option that I have changed for debug mode at some point in the past? Its got me baffled and I will need to fix it eventually as I really need debug mode, I can't imagine life without debug:)

Thanks to everyone who has helped so far, hopefully I can help someone here someday.

[Jamarr]

It most certainly could be a compiler option, in which case it may be difficult for us to help you figure it out.

Also, I think Kulik asked this earlier but could you start the application in debug mode, let the exception occur, and at that point copy/paste what is in the callstack window into a [code][/code] tag here. It might shed some additional light on the issue.

[DozyHole]

This is from the call stack window after the exception:

Code: Select all

>   CEGUI-Take2.exe!DarkGDK()  Line 88 + 0x49 bytes   C++
    CEGUI-Take2.exe!_WinMain@16()  + 0x17 bytes   C++
    CEGUI-Take2.exe!__tmainCRTStartup()  Line 263 + 0x1b bytes   C
    kernel32.dll!762c4911()    
    [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]   
    ntdll.dll!7742e1c6()    
    ntdll.dll!7742e199()    

EDIT: OK, I can compile in debug and it works as long as I dont link to the debug CEGUI libs:

Code: Select all

//#pragma comment(lib, "CEGUIBase_d.lib")
//#pragma comment(lib, "CEGUIDirect3D9Renderer_d.lib")

#pragma comment(lib, "CEGUIBase.lib")
#pragma comment(lib, "CEGUIDirect3D9Renderer.lib")

@apam - If you are still around, what libs are you linking to?

[Jamarr]

Are you sure that your "debug configuration" is configured for a debug build?

In particular you might want to verify these options*:
Properties > C/C++ > General > Debug Information Format = Program Database (/Zi)
Properties > C/C++ > Optimization = Disabled (/0d)
Properties > C/C++ > Code Generation > Runtime Library = Multi-threaded Debug (/MDd) **
Properties > C/C++ > Advanced > Disable Specific Warnings = (empty)
Properties > Linker > Input > Ignore Specific Library = (empty)
Properties > Linker > Debugging > Generate Debug Info = Yes (/DEBUG)


* Unless you are absolutely, 100% sure the existing setting is what you want / relevant
** This is one is probably the most likely cause of your problem

If the options above do not fix your issue, you may want to compare the CEGUI Samples Debug configuration to your own, since earlier you said the samples worked for you.

[DozyHole]

Hi Jamarr,

If not having this setting can cause my issue:
Properties > C/C++ > Code Generation > Runtime Library = Multi-threaded Debug (/MDd)
Then its probably that.

I feel bad now for not mentioning before that I am using one of the DarkGDK wizards when I setup my project, so compiler settings are different, people have complained in the past that DarkGDK is compiled with bad settings.

I have to compile with this setting:
Properties > C/C++ > Code Generation > Runtime Library = Multi-threaded (/MT)
Anything else and I get errors, I just tried the setting you suggest.

There are other differences as well, again causing errors if I change them:
Properties > C/C++ > General > Debug Information Format = Program Database for Edit & Continue (/ZI)
Properties > Linker > Input > Ignore Specific Library = libcmtd, msvcrt, atls

I guess we will know for sure if apam gets back to us and tries linking to the debug libs as he too willl probably we using the GDK wizard.

If you are sure that these settings could cause this issue then I am happy to put this down as solved and I will just link to the libs that work for me, unless you think I could have trouble in the future.

I know of people who have compiled DarkGDK from source with different settings and maybe this is why, problem with that is it causes issues when using DarkGDK 3rd party plugins.

[Jamarr]

If not having this setting can cause my issue:
Properties > C/C++ > Code Generation > Runtime Library = Multi-threaded Debug (/MDd)
Then its probably that.

I feel bad now for not mentioning before that I am using one of the DarkGDK wizards when I setup my project, so compiler settings are different, people have complained in the past that DarkGDK is compiled with bad settings.

I have to compile with this setting:
Properties > C/C++ > Code Generation > Runtime Library = Multi-threaded (/MT)
Anything else and I get errors, I just tried the setting you suggest.

If you are sure that these settings could cause this issue then I am happy to put this down as solved and I will just link to the libs that work for me, unless you think I could have trouble in the future.

I am sure this is the issue. The precompiled non-static CEGUI libraries use /MD for release, and /MDd for debug. This options tells the compiler which C-runtime to link: /MT = static (LIBCMT) library, /MD = dynamic (MSVCRT) library. Mixing these is warned against, but in your case mixing /MT and /MD does not (yet) appear to cause issue.

However, in addition you are mixing release and debug versions of the CRT library (/MT vs /MDd) within the same project which is probably the root problem, since the debug version uses different memory management/structure; this exact issue has been mentioned on these forums several times. I'm sure if you search back through the original forum-search I posted you will find several threads on this.

You can probably work around this by sticking with the /MD version as you initially pointed out. Another option would be to recompile CEGUI from source yourself and manually change the Runtime Library option in the debug-configuration to /MT (or /MD) prior to building, which should let you step into CEGUI for debugging. However, you may also need to rebuild all of CEGUI's dependencies like this as well, which is a pita.

[Jamarr]

It is curious because this issues always happens when subscribing to an event, even for other users. The sources I've read all mention allocating/deallocating in different heaps specifically being an issue, but I do not believe CEGUI does any deallocations in the process of subscribing to an event.

http://msdn.microsoft.com/en-us/library ... 60(v=vs.80).aspx
http://stackoverflow.com/questions/5887 ... fest-files

Perhaps the debug-CRT (/MDd) in the CEGUI DLL is attempting to validate a block of memory assuming it was allocated in debug-form, when the actual block of memory was allocated normally (/MD) resulting in an exception. However this is purely hypothetical, and probably a stretch at that.

I did notice that SubscriberSlot uses templates to allocate memory for the functor, which I assume means the memory would be allocated in the current modules CRT heap and not the CRT heap associated with the CEGUI DLL? If this is the case, then I would expect this sort of crash to occur when deallocating / cleaning up the event subscription. However, as it crashes during subscription that theory never gets tested. The second source does say not to use complex objects (like std::string) I presume because they can allocate/deallocate memory implicitly. So there could be something with how CEGUI::String is used during subscription...but I'm just grasping at straws here.

[DozyHole]

Thanks for all your help Jamarr and kulik.

Jamarr, alot of what you are saying goes way over my head, but you seem to know your stuff:) so I will put this one down to compiler settings.

People using CEGUI with Dark GDK will hopefully find this post when they search if they have the same issues and you guys have put plenty of info here to help.

SOLUTION: If you can't suscribe to events and you are using the DarkGDK wizards then try linking to the non-debug libs instead, simples:)