If you create a parameterised constructor for a class you must also provide a default parameterless one.
public KeyStroke(int numlines, CRichEditCtrl* myrichptr)
// the one you will mainly use
// the compiler will not infer this because you have created the one above
// if you do not provide any constructors then the compiler will automatically
// create the parameterless one.
This is a problem. While you're declaring the CProgedit constructor on the left-hand side, the part on the right-hand side is actually a call, so you wouldn't put the data types of the aguments. In other words, try the following:
I wrote a number of rich edit classes after finishing I realized they would all have common functionality
1) processing KeyStrokes
2) cursor select
3) Finding data
I decided to encompass all of this in a class called KeyStroke which would expand functioality on a EditCtrl object
so I declared KeyStroke mykey1; etc; 2 3 ...
The constructor of KeyStroke takes a RicheditObject it was my understanding that when "new" build a class/object the First thing it does is allocate storage for the class/object and then
call member classes which is why I thought this was doable
I created an xll excel add-in with Visual C++ 2013 and Excel 2007/2010/2013 XLL SDK package. In the application I have to load a third party dll which depends on MSVCR90.dll for release version and MSVCR90D.dll for debug version. But I don't know how to load the MSVCR90D.dll in the project. What I tried is to create an additional manifest file or use a pragma comment instead in the code like
It works in win32 console application but not in xll application.
Also I wonder why in the xll application all the release version of msvcr dll including MSVCR90.dll, MSVCR100.dll and MSVCR120.dll are automatically loaded if they are installed in windows system. Since I am working in vc++ 2013, msvcr120d.dll is loaded as well.
Can anyone tell me how msvcr90d.dll can be loaded as well?
visual c++ 2008/2010/2013 redistributable packages are installed.
There is no need to load these DLLs in your project. They must be only present on your system so that they can be found and loaded by the 3rd party DLL when your application is executed. The only problem might be getting the debug version (MSVCR90D) because it is not publicly available (not allowed to be distributed).
If you have it, just copy it to your project's Debug folder where it can be found when executing the debug executable.
There might be also problems when using different runtime library versions from a single application, but I have no experiences with that. The best solution would be to ask the supplier of the 3rd party DLL if he can provide a version build with VS 2013 or a version that has the runtime statically linked.