|
|
i create a com dll using an ATL and attribute and i try to register this file when i call LoadLibrary( DllPath ) i got a null pointer and i don't know why.
some computer print this message box "the application failed to start because MSVCR70D.dll component not found"
can i make a attributed ATL7 com dll independant on any other components
-- modified at 16:13 Sunday 24th September, 2006
|
|
|
|
|
i try to build the project in release configuration and the problem disappear
|
|
|
|
|
When you compile in debug configuration, it links with MSVCR70D.dll instead of MSVCR70.dll
MSVCR70D.dll is the debug configuration dll of vc runtime.
To solve this problem, all you need is the MSVCR70D.dll on the box where you are trying to register your Atl7 COM server.
S o h a i l K a d i w a l a
To Err Is Human; to Debug, Divine
modified 21-Apr-21 21:01pm.
|
|
|
|
|
You can remove that dependency but going to Ptoject/Properties, go to Code generation and selecte "Mulithreaded Debug" instead of "Multithareded Debug DLL"
|
|
|
|
|
I need to learn fast about the creation of ATL Composite Control Projects.
Where could I find abundant information about this??.
Maybe a tutorial in the WEB.
Maybe a book.
I have read a lot about ATL projects but I need something specific about Composite Controls. Something that teach me how should I move inside this kind of projects.
I have some good skills with MFC and I'm learning general ATL stuff.
Thank you very much.
Demian.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Just use the composite control wizard. The composite control is basically a non-modal dialog. I suggest you use WTL for the GUI-stuff, as it makes your life a whole lot easier.
--
This episode performed entirely by sock puppets
|
|
|
|
|
Hi.
I have a WTL 7.5 app created in VS2005 on XP.
In the app I was intending to make use of various STL containers. I began by entering:
using namespace std;
just under my header declarations, BOOM!
I instantly got 11 errors, 5 pairs of:
error C2006: '#using' : expected a filename, found 'namespace'
fatal error C1190: managed targeted code requires a '/clr' option 
and 1:
BSCMAKE: error BK1506 : cannot open file '.\Debug\DispInterface.sbr': No such file or directory.
I've rummaged around my settings and could see nothing that cause this (though obviously, I expect I'm missing something). Anyway, I continued with the app as I could use std:: to use the containers I wanted, only to find when I called push_back on a vector I got a heap corruption (C0000005).
I can only presume these are connected as I understand neither.
Any insights would be greatly appreciated
Thanks
Tom
|
|
|
|
|
Weird - it seems to be parsing using as #using!
How about using the std namespace qualifier directly, e.g.:
std::string str = "Test";
Does this work OK?
FWIW I use the STL with all my WTL/ATL apps with no issues, however, I avoid using namespace .... I prefer to specify the namespace directly.
Should I use using namespace std in my code?[^]
Kicking squealing Gucci little piggy.
|
|
|
|
|
Rob Caldecott wrote: I avoid using namespace
And me - the only namespace I use is boost::lambda, and then only in the smallest scope I can find.
|
|
|
|
|
TClarke wrote: #using
'#using' - sure there's not a rogue '#' in there?
Also - I've used STL and WTL together with *no* problems, so I'd suggest it isn't going to be that...
|
|
|
|
|
Firstly, thanks for the speedy responses 
there's certainly no rogue '#' in there, the file begins as follows:
<br />
<br />
#pragma once<br />
#include "idlobject.h"<br />
#include "IDLMethod.h"<br />
#include "IDLProperty.h"<br />
<br />
#using namespace std;<br />
<br />
class CDispInterface :<br />
public CIDLObject<br />
{<br />
<br />
std::string test = "Test";
Worked fine, but:
std::vector< CIdlMethod* > m_vMethods;<br />
CIdlMethod* pMethod = new CIdlMethod(); <br />
m_vMethods.push_back( pMethod );
fails with a heap corruption 
PS. thanks for the link to that FAQ page.
Tom
|
|
|
|
|
TClarke wrote: #using namespace std;
Ummmm - it should be using namespace std;, not #using namespace std; - that's what I meant by a rogue #. C++ namespaces are used with a plain using. #using pulls in a .NET assembly[^].
|
|
|
|
|
Ah Ha!
Goodness knows where I got that from 
Thanks Stuart
|
|
|
|
|
TClarke wrote: fatal error C1190: managed targeted code requires a '/clr' option
This requires setting property "common language runtime support".
You can do it by setting project properties-->Genearal-->Project Defaults--> common language runtime support-->common language runtime support
TClarke wrote: error C2006: '#using' : expected a filename, found 'namespace'
Not sure about this one, but may be this[^] helps you.
|
|
|
|
|
It's bizare that the comiler is looking for CLR support when I'm not using anything I'm aware has even a whiff of a connection to it.
When I set the /clr property It just ran into the '/MTd' property and compiling ceased. Since I rely heavily on threads in this app that's kind checkmate as far as 'using namespace std;' is concerned.  
thanks to an article I got pointed to by an earlier comment I'm now resolved to using std:: anyway. Now I just have to figure out what's going on with my std::vector
Thanks
Tom
|
|
|
|
|
Let us take a simple function
::MessageBox(0,data.c_str(),"log",0);
where data is a std::sting type.
When i change the build type to unicode ,this will spit out error
error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'
How can i feed in the underlying data of a std::string type(const char *),so that it builds smoothly in both MBCS and UNICODe builds.
|
|
|
|
|
typedef std::basic_string<TCHAR> tstring;
...
tstring str = _T("Hello, World!");
::MessageBox(NULL, str.c_str(), _T("Test"), 0);
The above will work in both MBCS and Unicode builds.
Or see here[^].
FWIW I always use std::wstring and build for Unicode and for Win9x support I link with the MS unicows library.
Last modified: 2hrs 12mins after originally posted --
Kicking squealing Gucci little piggy.
|
|
|
|
|
Rob Caldecott wrote: FWIW I always use std::wstring and build for Unicode and for Win9x support I link with the MS unicows library.
Smart choice, as going from ANSI -> UNICODE is a pain in the ass. I just wish all platforms and libraries used the same Unicode encoding scheme. I recently tried to do Unicode for different platforms. P.I.T.A! Windows uses UCS2/UTF-16 internally, while on Unix you use either UTF-8 (char) or UTF-32 (wchar_t). Dear god in heaven, that amounts to a huge frickin layer of string crap.
--
Mr. Bender's Wardrobe by ROBOTANY 500
|
|
|
|
|
You are mixing two types and the literal string is the problem:
data.c_str() is UNICODE, and "log" is not under a UNICODE build. Change "log" to L"log".
::MessageBox(0, data.c_str(), L"log", 0);
|
|
|
|
|
Better would be to use the TCHAR include (tchar.h) and to have literals with _T()
such as _T("log"). That way, it builds as ANSI string for ANSI/MBCS, and as wide string for UNICODE.
The original point was about parameter#2, which was the std::string's c_str() function, and the first reply sorted out that problem. Literal strings are another...
Given that MS no longer offer support for Win9x, I've taken the decision to produce only UNICODE binaries now. Of course, most of the code I've been writing for years (since W2K was released) has been compilable for both anyway...
Steve S
Developer for hire
|
|
|
|
|
Steve,
 , I failed to see the last line of his post! Likewise, I mostly program with UNICODE and seldomly use "tchar.h".
|
|
|
|
|
George L. Jackson wrote: I failed to see the last line of his post!
I do that a lot these days. I guess in my case, it's an age thing 
Although I target UNICODE, I do tend to use TCHAR.H still, although as I do more and more C#, it will become less relevant.
Steve S
Developer for hire
|
|
|
|
|
If you are old, I am ancient! I got ten years on you. You were six years old when I wrote my first FORTRAN program in high school.
|
|
|
|
|
I have been playing around with subclassing a RichEdit control to get an XP like Syslink common control which works on all versions of Windows. I've been reasonably successful but wanted to remove the dependency on RicheEdit. I searched CP and came across a couple of classes which look suitable:
1) Hyperlink Text View Control[^]
This is WTL based but has not been updated for a while and did not compile straight away. I changed some of the files that were included and got the example project to compile under Visual Studio 2005, but when I run the program it fails with a Debug Assertion error "vector iterator not dereferencable". Does anyone know what's wrong with this class, or have a version compatible with VS 2005 ?
2) XHTMLStatic - An extra-lean custom control to display HTML[^]
This is MFC based and has been updated more recently. It derives from MFC's CStatic, so would there be any problems using it with WTL ?
Does anyone have a WTL compatible version of this class ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
