CStringT::LoadString() causes assert; KB150764 not helpful 
Author Message
 CStringT::LoadString() causes assert; KB150764 not helpful

The KB article mentioned in the subject says that this is the result of
using CStringT::LoadString() in a console application, but I'm not writing a
console application.  I'm writing an MFC dialog-based application, and
LoadString() asserts when called from a generic C++ class I wrote for the
project.  I can't tell why LoadString() works in the CWinApp-derived class
but not in the other, they both seem to use all the same header files.

--
Jeff S.



Mon, 27 Jun 2005 05:31:03 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful
Jeff,


Quote:

>The KB article mentioned in the subject says that this is the result of
>using CStringT::LoadString() in a console application, but I'm not writing
a
>console application.  I'm writing an MFC dialog-based application, and
>LoadString() asserts when called from a generic C++ class I wrote for the
>project.  I can't tell why LoadString() works in the CWinApp-derived class
>but not in the other, they both seem to use all the same header files.

There can be a number of possible causes for this assert. Could you clarify:

a) Which version of Visual C++ are you using, with which service packs
installed?
b) Is your application a single EXE, or is it made using multiple EXEs and
DLLs?
c) Are you using MFC in a DLL or statically linked MFC?
d) Could you tell me the exact information about the assertion - file,
line, text?

Thanks,

Martyn Lovell
Software Architect
Visual C++ Libraries Team
This posting is provided AS IS with no warranties, and confers no rights.



Sun, 03 Jul 2005 02:36:06 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful
Hi Martyn.  I'm afraid I can't give you any more detail because I've long
since worked around the problem.

However, I believe that what I found out was that calling
CString::LoadString() before CWinApp::InitInstance() caused it to assert.
All calls to CString::LoadString() made -after- CWinApp::InitInstance()
worked fine.  Now you know as much as I do.  I'm not sure if this behavior
is normal, but that's what I was experiencing.

--
Jeff S.



Quote:
> Jeff,



> >The KB article mentioned in the subject says that this is the result of
> >using CStringT::LoadString() in a console application, but I'm not
writing
> a
> >console application.  I'm writing an MFC dialog-based application, and
> >LoadString() asserts when called from a generic C++ class I wrote for the
> >project.  I can't tell why LoadString() works in the CWinApp-derived
class
> >but not in the other, they both seem to use all the same header files.

> There can be a number of possible causes for this assert. Could you
clarify:

> a) Which version of Visual C++ are you using, with which service packs
> installed?
> b) Is your application a single EXE, or is it made using multiple EXEs and
> DLLs?
> c) Are you using MFC in a DLL or statically linked MFC?
> d) Could you tell me the exact information about the assertion - file,
> line, text?

> Thanks,

> Martyn Lovell
> Software Architect
> Visual C++ Libraries Team
> This posting is provided AS IS with no warranties, and confers no rights.



Sun, 03 Jul 2005 04:04:14 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful
Jeff,


Quote:

>Hi Martyn.  I'm afraid I can't give you any more detail because I've long
>since worked around the problem.

>However, I believe that what I found out was that calling
>CString::LoadString() before CWinApp::InitInstance() caused it to assert.
>All calls to CString::LoadString() made -after- CWinApp::InitInstance()
>worked fine.  Now you know as much as I do.  I'm not sure if this behavior
>is normal, but that's what I was experiencing.

Sorry for the delayed reply. We had a backlog from the holidays which it's
taken us a while to catch up on.

Calling before InitInstance would have been your problem. An assert in this
scenario is expected. InitInstance initialises the resource handle among
many other things, and so needs to be called before you can load strings.

Martyn Lovell
Software Architect
Visual C++ Libraries Team
This posting is provided AS IS with no warranties, and confers no rights.



Sun, 03 Jul 2005 08:20:43 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful
Ugh!

So that would also mean that you can't do a LoadString in the constructor of
a static object, for example...  Please correct me if I'm wrong.

K. Lilov
Str Library at http://www.utilitycode.com/str



Quote:
> Jeff,



> >Hi Martyn.  I'm afraid I can't give you any more detail because I've long
> >since worked around the problem.

> >However, I believe that what I found out was that calling
> >CString::LoadString() before CWinApp::InitInstance() caused it to assert.
> >All calls to CString::LoadString() made -after- CWinApp::InitInstance()
> >worked fine.  Now you know as much as I do.  I'm not sure if this
behavior
> >is normal, but that's what I was experiencing.

> Sorry for the delayed reply. We had a backlog from the holidays which it's
> taken us a while to catch up on.

> Calling before InitInstance would have been your problem. An assert in
this
> scenario is expected. InitInstance initialises the resource handle among
> many other things, and so needs to be called before you can load strings.

> Martyn Lovell
> Software Architect
> Visual C++ Libraries Team
> This posting is provided AS IS with no warranties, and confers no rights.



Sun, 03 Jul 2005 09:12:07 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful

That's exactly correct, actually, which is why this problem was SO annoying.
My purist CS nature wants all object constructors to actually do
constructing, and when a serious error occurs, I wanted to be able to alert
the user with a message box from within the constructor.  Furthermore, I
wanted the message box to use a string taken from the string table.  No such
luck.

Is there any way to ensure that CWinApp::InitInstance() is called at
the -very- beginning of execution?  I'm still new to Windows programming.

--
Jeff S.


Quote:
> Ugh!

> So that would also mean that you can't do a LoadString in the constructor
of
> a static object, for example...  Please correct me if I'm wrong.

> K. Lilov
> Str Library at http://www.utilitycode.com/str



> > Jeff,



> > >Hi Martyn.  I'm afraid I can't give you any more detail because I've
long
> > >since worked around the problem.

> > >However, I believe that what I found out was that calling
> > >CString::LoadString() before CWinApp::InitInstance() caused it to
assert.
> > >All calls to CString::LoadString() made -after- CWinApp::InitInstance()
> > >worked fine.  Now you know as much as I do.  I'm not sure if this
> behavior
> > >is normal, but that's what I was experiencing.

> > Sorry for the delayed reply. We had a backlog from the holidays which
it's
> > taken us a while to catch up on.

> > Calling before InitInstance would have been your problem. An assert in
> this
> > scenario is expected. InitInstance initialises the resource handle among
> > many other things, and so needs to be called before you can load
strings.

> > Martyn Lovell
> > Software Architect
> > Visual C++ Libraries Team
> > This posting is provided AS IS with no warranties, and confers no
rights.



Mon, 04 Jul 2005 00:13:11 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful

Kamen,



Quote:
>So that would also mean that you can't do a LoadString in the constructor
of
>a static object, for example...  Please correct me if I'm wrong.

That would be correct. You need to wait for InitInstance and do it then.

If your code is in an EXE, you could chose to use the 'raw' OS API provided
you have some way to identify which module to get your resources from.

Note that if your code is in a DLL, it's not even allowed to call the OS
::LoadString API during a static constructor. Static constructors in DLLs
are run during DllMain, which means they can do only a very limited set of
things. Your dll-based static constructors have to be very careful about
what they do. This article has details:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllp...
e/dllmain.asp

Martyn Lovell
Software Architect
Visual C++ Libraries Team
This posting is provided AS IS with no warranties, and confers no rights.



Mon, 04 Jul 2005 02:34:37 GMT  
 CStringT::LoadString() causes assert; KB150764 not helpful

Jeff,


Quote:

>That's exactly correct, actually, which is why this problem was SO
annoying.
>My purist CS nature wants all object constructors to actually do
>constructing, and when a serious error occurs, I wanted to be able to alert
>the user with a message box from within the constructor.  Furthermore, I
>wanted the message box to use a string taken from the string table.  No
such
>luck.

>Is there any way to ensure that CWinApp::InitInstance() is called at
>the -very- beginning of execution?  I'm still new to Windows programming.

Nope. CWinApp::InitInstance relies on many other things to be initialised -
the process's static variables, the C runtimes, the MFC global state. MFC
calls InitInstance at the earliest appropriate moment.

Martyn Lovell
Software Architect
Visual C++ Libraries Team
This posting is provided AS IS with no warranties, and confers no rights.



Mon, 04 Jul 2005 02:37:46 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. LoadString() fails under VC++4.0 but not under VC++ 5.0

2. CString::LoadString does not work

3. CString:LoadString not working in DLL

4. LoadString() fails under VC++ 4.0 but not VC++ 5.0

5. assert() causes compile problem in Visual C++

6. Unload composite control causes Assert in Atlwin.h, Line 2281

7. database exception causes debug assert in CdbDBEngine

8. HELP!!! CRecordset::Close is causing an assert

9. Help: DAO in DLL (static link to MFC) causes Heap assert

10. Apparent corruption caused by the debugger / ASSERT

11. How can my perfect code cause an assert?

12. why free causes an assert!

 

 
Powered by phpBB® Forum Software