Debug & Font::GetName()

How can I workaround (WString) Font::GetName() issue in Debug mode?

In Release all works fine...

Following did not solve my issue...

#ifdef _DEBUG
#undef _DEBUG
#include <MicroStationAPI.h>
#define _DEBUG
#else
#include <MicroStationAPI.h>
#endif

  • I do NOT use BMAKE to compile my code
  • Compiler is VS2005 in IDE
  • Release works, Debug does not

Thanks, Dan

  • The problem more generally is that we developers outside Bentley do not have library (.lib) files built for DEBUG.  Whether or not you attempt to fool the compiler, the linker has only one library file to link to — the RELEASE version.

    WString inherits from the C++ standard library std::wstring.  Turning off DEBUG in the MicroStationAPI has no effect: WString is defined (WString.h) in the \mdl\include folder, not the \mdl\MicroStationAPI folder.

     
    Regards, Jon Summers
    LA Solutions

  • I have it solved.

    Used FontMap to get FontNumber and then mdlText_getFontName to get name if debug is in account.

    I hate those issues.

  • Unknown said:
    I hate those issues

    I agree.  I believe that it's something to do with C++ classes that use the standard library collections in some way (WString inherits from std::wstring).

    In debug, C++ adds some wrappers around standard library collections (including std::wstring) to perform, for example, out-of-bounds checking.  Somewhere there are Microsoft macros that turn off that default behaviour.  They are hard to find, but I recall that Keith Bentley posted them here in response to a similar problem.

     
    Regards, Jon Summers
    LA Solutions

  • Do you mean -D_SECURE_SCL_THROWS=1 and  -D_SECURE_SCL=0 ?

    I'll give it a try, thanks for suggestion.

    [EDIT:] It does not work...

    Dan

  • Unknown said:
    Do you mean -D_SECURE_SCL_THROWS=1 and  -D_SECURE_SCL=0 ?

    No.  Although those two are useful, they add bounds-checking to the standard containers.  They don't modify the internal structure of the containers, which is the problem we face when compiling our DEBUG code and linking with Bentley's RELEASE code.  Because our DEBUG std::collections are different, although the link-time signatures are identical, there is a run-time mismatch in memory layout that causes the problem you see.

    There are some macros that turn off the extra stuff added to the std::containers internal layout in DEBUG.  By disabling that feature, our DEBUG code matches Bentley's RELEASE libraries and those crashes are avoided.  I've Googled without success to find the macros that Keith cited but without success, so they are pretty obscure.

     
    Regards, Jon Summers
    LA Solutions

  • One thing that I have learned about the std:: classes is that you need to match the compiler versions or you will experience issues.  

    Rgds,

  • Dan,

    do not define _DEBUG at all (it's not neccesary to create the browser database), compile a multithreaded (non debug) dll (/MD) in your VS project, even for debugging, set 'ingore library' in linker/input to mfc80d.lib,mfcs80d.lib,msvcrtd.lib (maybe some more in your case).

    this works for me (since years - even with edit+go), hope it does for you too. If you need some extra information you might contact me directly, and we can exchange some pics or start a online session.

    Michael



  • Michael Stark said:
    do not define _DEBUG at all (it's not neccesary to create the browser database), compile a multithreaded (non debug) dll (/MD) in your VS project, even for debugging, set 'ingore library' in linker/input to mfc80d.lib,mfcs80d.lib,msvcrtd.lib (maybe some more in your case).

    Thanks Michael. I had to turn off runtime checks due to boost auto_link, but /MD did it.

    Is this safe?

    Dan

  • As far as I can say, after a usage time of nearly 8 years.

    This was still true for VS6 - development when we started using C++/MFC instead of pure C and Ustn window management. Sometimes I wish we hadn't made that decision - but for other reasons, sometimes I only loving the ability to edit+go ;-) .

    The reason for this is, that MicroStation always loads the non-debug version of vcrt+mfc, so when you try to load the debug versions (automatically linked when _DEBUG was set or /MDd) it fails, as you would have duplicated entry points.

    I never encountered memory or threading problems.

    The only time I encountered real problems was in V8i, when the AFX_MANAGE_STATE (to switch resource source) call results in loosing every remembrance for settings that where used to create an elementdescriptor (i.e. needed levels) if you call a primitive command afterwards. This was a little bit annoying, but not a memory problem, seems Microsoft (or Bentley ?) has implemented a little to much (automatic) cleanup in .Net 3.5. as this is V8i only, exactly same source still works in XM. This can be prevented with creating the elementdescriptor after the start of a primitive/modify command, and forced me to create some callbacks, which in turn is not the worst thing (enables a better switch to the MstnTool-classes)

    HTH so far, Michael