Hello all,

Please excuse if this is not an STLSoft related issue, but it is one I've been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.

I'm using the create_bstr() function, which worked well in one project that uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.

Now I'm creating a DLL for another application (which happens to be a Palm conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project and it compiles fine, but I get this link error:

MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned int)" (??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof t@@QAE@I@Z)

I've seen this before but haven't been able to track it down.  Any ideas?

Thanks
Shawn Poulson
spoulson2@comcast.net

I originally posed this to c++.stlsoft, but I'm interested in hearing if the c++ group has some ideas.

Thanks in advance.

"Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
> Hello all,
>
> Please excuse if this is not an STLSoft related issue, but it is one I've been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.
>
> I'm using the create_bstr() function, which worked well in one project
that
> uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.
>
> Now I'm creating a DLL for another application (which happens to be a Palm conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project and it compiles fine, but I get this link error:
>
> MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned
int)"
>
(??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof
> t@@QAE@I@Z)
>
> I've seen this before but haven't been able to track it down.  Any ideas?
>
> Thanks
> Shawn Poulson
> spoulson2@comcast.net
>
>
>

Hi Shawn

The problem here is not directly-related to STLSoft, but that's not an issue
(for me, at least).

I presume you're using either Intel or Visual C++, since in their respective compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h - <CrtDbg.h> is the following two lines:

 #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
 #define stlsoft_assert(_x)
_ASSERTE(_x)

( All other compilers use <assert.h> and assert(_x) )

Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the appropriate place within stlsoft.h, and all assertions within the library are then effected in terms of _ASSERTE(), which boils down in debug compilers to a call to _CrtDbgReport().

The only possible explanation I can think of is that your debug mode DLL has chosen (and for possibly good reasons; see http://www.windevnet.com/documents/win0302c/) to prevent linking of the Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all default libraries" check box from within (General page of) the Link tab in the project settings. (That's speaking for Visual Studio 6 - I don't know the VS.NET dialogs off the top of my head.)

So you have two answers:

 (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
 (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.

I'd go with the first one, if I were you.

I had planned to allow users to specify their own _ThrowMyAssert() type assert, but haven't got round to it through lack of demand. If that demand arises I'll do it, in which case you'd be able to do something as simple as

 #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)

or some such. However, I suspect this is not what you're after so, you
should go with (i) or (ii)

Hope that helps.

btw, since you're working with COMSTL, I'd very much appreciate receiving comment on what areas you feel are missing from that project. (From my point of view this project has only just started, and will likely end up being larger than WinSTL.) I have a very long list of things I'll be creating or moving over (from my company's source) into COMSTL for the next big release (1.7.1, planned late July) of STLSoft, so any help with prioritisation would be much appreciated. Although it's not as popular as WinSTL, I've had quite a few emails recently from people using COMSTL, so I want to give it a big boost for the next release.

Matthew


"Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
> Hello all,
>
> Please excuse if this is not an STLSoft related issue, but it is one I've been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.
>
> I'm using the create_bstr() function, which worked well in one project
that
> uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.
>
> Now I'm creating a DLL for another application (which happens to be a Palm conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project and it compiles fine, but I get this link error:
>
> MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned
int)"
>
(??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof
> t@@QAE@I@Z)
>
> I've seen this before but haven't been able to track it down.  Any ideas?
>
> Thanks
> Shawn Poulson
> spoulson2@comcast.net
>
>
>

"Shawn Poulson" <spoulson2@comcast.net> wrote in news:bd0l3u$n2v$1@digitaldaemon.com:

> I originally posed this to c++.stlsoft, but I'm interested in hearing if the c++ group has some ideas.
> 
> Thanks in advance.
> 
> "Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
>> Hello all,
>>
>> Please excuse if this is not an STLSoft related issue, but it is one I've been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.
>>
>> I'm using the create_bstr() function, which worked well in one
>> project
> that
>> uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.


I was just wondering, did you use some framework to do the OLE automation?

I'm asking this because I did something similar but using Borland's C++ Builder and their VARIANT class but I'm having a problem that I'm unable to determine if it's related with my code, Office 97, Windows 95 or all together.

The problem has to do with running out of memory after opening, saving and closing 100 excel sheets. I tought at first that it had to do with my code and I ran Codeguard on it but it didn't detect any memory leak.

So I began thinking about using a different approach like using a different compiler/framework to get it done.


Thx, Gonçalo Farias

Thanks, Matt for the quick response.

I did neglect to mention I am using VS.NET.  My project config is pretty straightforward.  I am not using "Ignore all default libraries" nor am I using "Ignore specific library".  My additional libs are "sync20.lib hslog20.lib palmcmn.lib comctl32.lib", which are all Palm-related libs except for the last which is just for dialog controls.  I'm not using ATL, MFC, or any other framework.  My code is straight DLL C++ code with some Win32 and Palm calls.

I'm not sure what else I could set.  I did try to use some macros available in ATL that make BSTR's (A2WBSTR and CComBSTR class), which worked in my exe test but gave the same CrtDbgReport link error in my DLL project.  It's not clear why the DLL project had this problem since I synchronized all my project settings between exe and DLL.  I don't see any other settings I can change to address the two options.

Now, option (ii) worked.  I'll stick with this for now.  I'm not very adept at assertions so I've really not used them anyway.

I've only used the create_bstr() function so I'm no critic of the library, yet.  However, I would like to see functionality for SAFEARRAY.  It is really nice to see open source projects like this and boost.  If there's anyway I can help, please tell me how.


"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bd0sts$tl4$1@digitaldaemon.com...
> Hi Shawn
>
> The problem here is not directly-related to STLSoft, but that's not an
issue
> (for me, at least).
>
> I presume you're using either Intel or Visual C++, since in their
respective
> compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h - <CrtDbg.h> is the following two lines:
>
>  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
>  #define stlsoft_assert(_x)
> _ASSERTE(_x)
>
> ( All other compilers use <assert.h> and assert(_x) )
>
> Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the appropriate place within stlsoft.h, and all assertions within the library are then effected in terms of _ASSERTE(), which boils down in debug compilers to a call to _CrtDbgReport().
>
> The only possible explanation I can think of is that your debug mode DLL
has
> chosen (and for possibly good reasons; see http://www.windevnet.com/documents/win0302c/) to prevent linking of the Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all default libraries" check box from within (General page of) the Link tab in the project settings. (That's speaking for Visual Studio 6 - I don't know the VS.NET dialogs off the top of my head.)
>
> So you have two answers:
>
>  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
>  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.
>
> I'd go with the first one, if I were you.
>
> I had planned to allow users to specify their own _ThrowMyAssert() type assert, but haven't got round to it through lack of demand. If that demand arises I'll do it, in which case you'd be able to do something as simple
as
>
>  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)
>
> or some such. However, I suspect this is not what you're after so, you
> should go with (i) or (ii)
>
> Hope that helps.
>
> btw, since you're working with COMSTL, I'd very much appreciate receiving comment on what areas you feel are missing from that project. (From my
point
> of view this project has only just started, and will likely end up being larger than WinSTL.) I have a very long list of things I'll be creating or moving over (from my company's source) into COMSTL for the next big
release
> (1.7.1, planned late July) of STLSoft, so any help with prioritisation
would
> be much appreciated. Although it's not as popular as WinSTL, I've had
quite
> a few emails recently from people using COMSTL, so I want to give it a big boost for the next release.
>
> Matthew
>
>
> "Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
> > Hello all,
> >
> > Please excuse if this is not an STLSoft related issue, but it is one
I've
> > been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.
> >
> > I'm using the create_bstr() function, which worked well in one project
> that
> > uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.
> >
> > Now I'm creating a DLL for another application (which happens to be a
Palm
> > conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project
and
> > it compiles fine, but I get this link error:
> >
> > MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned
> int)"
> >
>
(??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof
> > t@@QAE@I@Z)
> >
> > I've seen this before but haven't been able to track it down.  Any
ideas?
> >
> > Thanks
> > Shawn Poulson
> > spoulson2@comcast.net
> >
> >
> >
>
>

LOL!

I've been gradually moving more and more STLSoft stuff back into my company's libraries, and I've now run into this exact problem in one of the base DLLs which does indeed eschew use of the VC++ libraries.

So it looks like I'm going to have to implement the change I spoke of right now, which'll mean it'll be in the next release (1.6.4) which is planned for the end of the month.



"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bd0sts$tl4$1@digitaldaemon.com...
> Hi Shawn
>
> The problem here is not directly-related to STLSoft, but that's not an
issue
> (for me, at least).
>
> I presume you're using either Intel or Visual C++, since in their
respective
> compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h - <CrtDbg.h> is the following two lines:
>
>  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
>  #define stlsoft_assert(_x)
> _ASSERTE(_x)
>
> ( All other compilers use <assert.h> and assert(_x) )
>
> Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the appropriate place within stlsoft.h, and all assertions within the library are then effected in terms of _ASSERTE(), which boils down in debug compilers to a call to _CrtDbgReport().
>
> The only possible explanation I can think of is that your debug mode DLL
has
> chosen (and for possibly good reasons; see http://www.windevnet.com/documents/win0302c/) to prevent linking of the Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all default libraries" check box from within (General page of) the Link tab in the project settings. (That's speaking for Visual Studio 6 - I don't know the VS.NET dialogs off the top of my head.)
>
> So you have two answers:
>
>  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
>  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.
>
> I'd go with the first one, if I were you.
>
> I had planned to allow users to specify their own _ThrowMyAssert() type assert, but haven't got round to it through lack of demand. If that demand arises I'll do it, in which case you'd be able to do something as simple
as
>
>  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)
>
> or some such. However, I suspect this is not what you're after so, you
> should go with (i) or (ii)
>
> Hope that helps.
>
> btw, since you're working with COMSTL, I'd very much appreciate receiving comment on what areas you feel are missing from that project. (From my
point
> of view this project has only just started, and will likely end up being larger than WinSTL.) I have a very long list of things I'll be creating or moving over (from my company's source) into COMSTL for the next big
release
> (1.7.1, planned late July) of STLSoft, so any help with prioritisation
would
> be much appreciated. Although it's not as popular as WinSTL, I've had
quite
> a few emails recently from people using COMSTL, so I want to give it a big boost for the next release.
>
> Matthew
>
>
> "Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
> > Hello all,
> >
> > Please excuse if this is not an STLSoft related issue, but it is one
I've
> > been trying to figure out and it happens when I use the COMSTL library. I've only just begin to use COMSTL.
> >
> > I'm using the create_bstr() function, which worked well in one project
> that
> > uses OLE Automation to create an Excel sheet and fill in some cells with string data.  This works.
> >
> > Now I'm creating a DLL for another application (which happens to be a
Palm
> > conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project
and
> > it compiles fine, but I get this link error:
> >
> > MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned
> int)"
> >
>
(??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof
> > t@@QAE@I@Z)
> >
> > I've seen this before but haven't been able to track it down.  Any
ideas?
> >
> > Thanks
> > Shawn Poulson
> > spoulson2@comcast.net
> >
> >
> >
>
>

"Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd5mnv$29vj$1@digitaldaemon.com...
> Thanks, Matt for the quick response.

Happy to serve/share. :)

> I did neglect to mention I am using VS.NET.  My project config is pretty straightforward.  I am not using "Ignore all default libraries" nor am I using "Ignore specific library".  My additional libs are "sync20.lib hslog20.lib palmcmn.lib comctl32.lib", which are all Palm-related libs except for the last which is just for dialog controls.  I'm not using ATL, MFC, or any other framework.  My code is straight DLL C++ code with some Win32 and Palm calls.

It's a bit hard to diagnose your problem any further without getting my paws on the project ...
>
> I'm not sure what else I could set.  I did try to use some macros
available
> in ATL that make BSTR's (A2WBSTR and CComBSTR class), which worked in my
exe
> test but gave the same CrtDbgReport link error in my DLL project.  It's
not
> clear why the DLL project had this problem since I synchronized all my project settings between exe and DLL.  I don't see any other settings I
can
> change to address the two options.
>
> Now, option (ii) worked.  I'll stick with this for now.  I'm not very
adept
> at assertions so I've really not used them anyway.

... but it looks like you're sort of happy for the moment.

>
> I've only used the create_bstr() function so I'm no critic of the library, yet.  However, I would like to see functionality for SAFEARRAY.

I'll have a look at that for 1.7.1 (which I plan for July). I am thinking at least of sequence-iteration over SAFEARRAY contents, and may even get so far as converting an SA wrapper which has been lurking around in the company code for some years.

>  It is
really nice to see open source projects like this and boost.  If there's
> anyway I can help, please tell me how.

Just keep giving feedback, and, I guess, sharing the message.

One thing I'm keen to focus on is making the help really good. At the moment one might, kindly, call it antiseptic. I'm very keen to enhance this to give examples wherever necessary, so if you can feed back _specific_ criticisms I will do my best to address them asap.

Cheers

Matthew

>
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bd0sts$tl4$1@digitaldaemon.com...
> > Hi Shawn
> >
> > The problem here is not directly-related to STLSoft, but that's not an
> issue
> > (for me, at least).
> >
> > I presume you're using either Intel or Visual C++, since in their
> respective
> > compiler-specific headers - stlsoft_cccap_intel.h &
stlsoft_cccap_msvc.h -
> > <CrtDbg.h> is the following two lines:
> >
> >  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
> >  #define stlsoft_assert(_x)
> > _ASSERTE(_x)
> >
> > ( All other compilers use <assert.h> and assert(_x) )
> >
> > Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the appropriate place within stlsoft.h, and all assertions within the
library
> > are then effected in terms of _ASSERTE(), which boils down in debug
> > compilers to a call to _CrtDbgReport().
> >
> > The only possible explanation I can think of is that your debug mode DLL
> has
> > chosen (and for possibly good reasons; see http://www.windevnet.com/documents/win0302c/) to prevent linking of the Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all default libraries" check box from within (General page of) the Link tab
in
> > the project settings. (That's speaking for Visual Studio 6 - I don't
know
> > the VS.NET dialogs off the top of my head.)
> >
> > So you have two answers:
> >
> >  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s),
or
> >  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft
assertions.
> >
> > I'd go with the first one, if I were you.
> >
> > I had planned to allow users to specify their own _ThrowMyAssert() type assert, but haven't got round to it through lack of demand. If that
demand
> > arises I'll do it, in which case you'd be able to do something as simple
> as
> >
> >  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)
> >
> > or some such. However, I suspect this is not what you're after so, you
> > should go with (i) or (ii)
> >
> > Hope that helps.
> >
> > btw, since you're working with COMSTL, I'd very much appreciate
receiving
> > comment on what areas you feel are missing from that project. (From my
> point
> > of view this project has only just started, and will likely end up being larger than WinSTL.) I have a very long list of things I'll be creating
or
> > moving over (from my company's source) into COMSTL for the next big
> release
> > (1.7.1, planned late July) of STLSoft, so any help with prioritisation
> would
> > be much appreciated. Although it's not as popular as WinSTL, I've had
> quite
> > a few emails recently from people using COMSTL, so I want to give it a
big
> > boost for the next release.
> >
> > Matthew
> >
> >
> > "Shawn Poulson" <spoulson2@comcast.net> wrote in message news:bd0k13$m96$1@digitaldaemon.com...
> > > Hello all,
> > >
> > > Please excuse if this is not an STLSoft related issue, but it is one
> I've
> > > been trying to figure out and it happens when I use the COMSTL
library.
> > > I've only just begin to use COMSTL.
> > >
> > > I'm using the create_bstr() function, which worked well in one project
> > that
> > > uses OLE Automation to create an Excel sheet and fill in some cells
with
> > > string data.  This works.
> > >
> > > Now I'm creating a DLL for another application (which happens to be a
> Palm
> > > conduit) that does similar work to create an Excel sheet using OLE Automation.  I use the same basic code as used in the previous project
> and
> > > it compiles fine, but I get this link error:
> > >
> > > MMCdPcMgr.obj : error LNK2019: unresolved external symbol
__CrtDbgReport
> > > referenced in function "public: __thiscall
stlsoft::auto_buffer<unsigned
> > > short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>::auto_buffer<unsigned short,class stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned
> > int)"
> > >
> >
>
(??0?$auto_buffer@GV?$task_allocator@G@comstl_project@stlsoft@@$0CAA@@stlsof
> > > t@@QAE@I@Z)
> > >
> > > I've seen this before but haven't been able to track it down.  Any
> ideas?
> > >
> > > Thanks
> > > Shawn Poulson
> > > spoulson2@comcast.net
> > >
> > >
> > >
> >
> >
>
>