I have created an ATL Project with all default options using VC++ 2008.
I have added Simple ATL object (interface IDemo) and some interface moethos inside the simple object.
I want to use MFC classes (e.g. CDatabase, CRecordset and lots more) inside my ATL project.
How can I achieve this?
Thanks.
Nearly the only reasonable answer is "don't do that". ATL has OLE DB consumer templates of its own. If you want data access from an ATL project, those are the ones to use. If you're going to use MFC, make it an MFC project and be done with it.
One of the major arguments aginst MFC is that it's difficult (borders in impossible in some cases) to separate individual pieces of it out from the rest and use them in isolation.
Related
I am working on a silverlight project and I am using MEF to download xap file of other silverlight project and use its pages and functions in my main Project.
I can do the same thing using referencing dll of that project into my main project.
So I want to know what is the difference between using MEF to reusing components and Simply Adding Reference to the DLL of another project in current project? I mean that we also add reference to the project we import in our current project. Then how it is different from conventional form of component use?
Thanks,
First, we need to separate MEF and PRISM (since you used it in your tags).
MEF is primarily used to provide inversion of control (IoC). It makes it easy to manage dependencies your viewmodels and other classes to separate concerns and improve testability (amongst other benefits).
PRISM however is primarily designed for the following scenario: You don't know, what view goes into a specific container at compile time, and want ViewA for CustomerA, ViewB for CustomerB and so on. PRISM helps you to losely couple your regions and views in a way, so that the application can decide at runtime, what view will be displayed. Another scenario, is that administrators get one view, other users another etc. PRISM also has other features (like the event aggregator), but I'd say the former is the most important one.
Now, I'd say MEF is never a bad thing to use for a bigger project. But I'd only use PRISM, if you really need the functionality it provides, since it can be very limiting. If you don't, simply add the references as you explained and let MEF know about those assemblies with the AssemblyCatalog.
So for MEF, I'd suggest you learn about Depdendency Injection and IoC. I found this blogpost by Martin Fowler quite good. As for PRISM, get familiar with what it does, and decide if you really need it.
Hope this helps.
Let me complement Lue's answer on the difference between MEF and referencing dlls a bit:
The two things are orthogonal activities, meaning that if you reference a dll directly you might still want to use MEF to detect the types in it - and vice versa you might grab a specific type in a dll you dynamically loaded directly (without MEF).
MEF basically finds types in dlls according to certain criteria and has a bit of convenience stuff in it to automatically populate properties and collections with such types. It can be used to make a system more decoupled and thus more maintainable. For example, a video editing software may look for all types implementing a certain interface in all known dlls to use as filters. Whether you include the filters directly as a dll or let the user download them on demand: In both cases your application becomes slightly cleaner by using MEF, since there is no hard-coded list of filters anywhere. Still, in the presence of dynamic library loading MEF is especially useful.
Visual C++. I have to implement some drawing and printing functionality that will be incorporated into (other developers') COM dll. Firstly I thought of doing everything using pure GDI and nothing more, but it seems that printing and print previewing is hell of a job to be done in GDI compared to the MFC implementation. So I decided to focus on MFC. Quick side question here: Is my choice right? I mean, are any easy ways of implementing printing (and print-preview) without MFC?
Now that I need MFC (assuming if you also agree with this), I have two questions about how to do it:
1) I believe the COM dll is the ATL project (it's not my code, some other developers independently develop it). Can I enable MFC support in that dll? What are the risks/limitations/drawbacks of having MFC runtime in the COM server? And if you advice doing this, how can I do it?
2) As much as I want to affect the third-party COM server's code as little as possible, I thought it might be the better approach to implement my code as a separate MFC-based DLL, and load and use that DLL from COM server. Do you advice doing this? What are the risks/limitations/drawbacks in this situation?
Shortly, I want to use MFC's drawing and especially printing capabilities in my code, which itself should be integrated in another developers' COM dll (which itself is utilized in a large corporate application). I'm no expert in COM technology so I'm a little bit confused. What are my best options?
You can use MFC in your own dll internally, and expose functionality to your users with non MFC intruded function: for example if you need to pass a point from/to ypur caller, use the GDI standard POINT structure, then convert it to a CPoint to use internally. In this case you don't need to enamble use of MFC in the ATL project ( that is possible anyway ) but of course you need to distribute or link with the MFC dll. If you want mantain the caller com dll as clean as possible, you can definitely create your own ATL+MFC dll and expose your functions via com interfaces too, but keep in mynd to avoid put MFC related objects in the interface.
Printing and print preview is a hell of a job unless you're using MFC Document/View Architecture. Will your COM expose such advanced UI?
If your COM must be independent of .NET then MFC is the way to go, otherwise I would use .NET. If you choose MFC, make sure you link to it statically. Otherwise you will most likely end up with runtime errors on machines where the necessary MFC version is missing.
Except for this, I wouldn't worry about compatibility since the idea of COM is to let the underlying magic do the marshaling of integers, strings and other objects.
I want to create an ActiveX DLL from Visual Basic 6 from which I would like to call some public functions. I will call this DLL only from VB6. However, it seems that only classes get exported. Is there any workaround?
I know there is a way to create DLLs from VB6 with standard WINAPI functions. This is not what I want, because I would have to type thousands of Declare instructions, and I would lose the dynamic linking so I don't need to recompile applications when changing the DLL.
I will state my problem just in case anyone has a better idea. I've got a bunch of relatively big projects, each with its own code, and then I have a lot of "Generic" code which is used in several projects. It's an annoyance to add every file to each new project, and having to recompile all of them for each minor change. So I thought of creating a DLL, so I would just "Add reference" when I begin a new project, and don't have to worry anymore about recompiling (at least for minor changes) but I raged when discovered that only classes got exported.
I wouldn't mind to reorganize the code in classes, but it's an overwhelming task: there are some 10 years of 3-4 people code, so it's not something I can do overnight.
Yes, it's easy.
Put all the utility routines in special classes in the DLL.
Set the Instancing property of those classes as GlobalMultiUse.
Build the DLL.
In your client project (with a reference to the DLL) you will now be able to call the functions and subroutines as if they were in a module in that project. You won't need to create any objects.
You can read more in the VB6 manual.
I have some MFC code (custom CWnd controls and some classes to expose) that I need to make into an activex / COM object with interfaces. Is it easier to make an ATL project with MFC support and make my ActiveX that way or make an MFC ActiveX control?
When doing an activeX control, is doing dual interfaces (like that explained in ACDual from microsoft) good/bad/makes no difference?
MFC is an easier route if you're a newbie in COM stuff: The wizards are better and more helpful. But it's far less flexible than ATL, which is probably not an issue if you simply have a couple of simpole interfaces to implement.
Also, IIRC MFC doesn't support dual interfaces. Dual interfaces are interesting in 2 cases:
- Performance is an issue. Such as a call to a short method executed millions of times.
- The object users are programmed in C++. Calling a native interface is way easier in C++ than calling an automation interface.
In conclusion, dual interfaces are cool but they are really interesting only if you can have them for free. Which means you use a framework which supports them. If you plan on much COM-based work, it's interesting to investigate in ATL and deeper COM knowledge. If you just have to provide a couple of simple MFC-based objects, just stick to MFC.
It's a bit of pain to use MFC for COM - there is too much code to write, macros to copy -
however you have to know what you're doing if you are mixing MFC and ATL because they are deceptively similar yet different, especially if you create windows with ATL.
The main thing is, if you use MFC from an ATL, you will need to start every one of your ATL method with AFX_MANAGE_STATE(AfxGetStaticModuleState( )), otherwise you will get random problems. This is done for you automatically when you implement COM with MFC, which is why there are these ugly METHOD_MANAGE_STATE macros in every method.
Beyond this, it just works. MFC objects inside a ATL objects is what I do..
I've always used straight ATL with no MFC for development of COM components. MFC is useful as an application framework, which I generally didn't need for lightweight (non-UI) COM components. ATL provides lots of support for strings, collections, and various utility classes without the need to bring in all of MFC with the logistical complexities that arise from doing that (like setting context on every public API call, etc). It also includes some basic UI support via CWindow and its friends if you're building a UI component.
I am very new to VB.net. I have written these objects in VB6 before. I'm just lost in VB.net, but (kicking and screaming) I have to learn how to do this. I've been googling for hours with only minor steps forward. Can anyone post a link that explains start to finish how to do this?
I have managed to write the class object, What I can not tell is how to register it and where the name1 and name2 in the CreateObject("Name1.Name2") come from.
Regsrv32 will not work. It says "Entry Point not found" and will not register it. Also, I can not drop it into the Assemblies directory. I read something about a regasm command one uses, but I can't seem to make this work either.
Thanks in advance for any assistance.
I am going to assume you are not trying to write a COM DLL but rather a complete project that call various sub assemblies like a VB6 EXE call a ActiveX DLL. If you can be more specific about what you are trying to do it would help me better.
Several points about VB.NET versus VB6.
1) For .NET only projects there is no registration. If a EXE or DLL references another .NET DLL the only requirement is that the DLLs be present in the parent's directory.
2) You can do a COM style registration for .NET apps only by registering the .NET assembly in the GAC. However there are several requirements for doing this. Do a search on the .NET GAC and it will give you the scoop on how to do this.
3) You can setup the .NET assembly to use COM in which case it will operate by the rules of COM including registration with regsvr.
You will find for .NET only project that #2, or #3 only come in rare instances. #1 will apply for 90% of your DLL assemblies. Of This is dependent on your project.
A common use for CreateObject is allow for plug-ins or installable libraries. .NET handles this through the Reflection API. With the reflection API you can look in a directory, go through each .NET DLL and see what them and create objects from what you find. Search for .NET Reflection to read up on this.
If your project is .NET only then I recommend that you create a Assembly that is reference by both the master assembly and the individual sub assembly that define the interfaces of the objects you are creating. This when you use the reflection API and determine the Object type you can assign it to a variable of that interface and code it noramlly with intellisense and other aids.
if you have old COM ActiveX Controls or DLLs .NET will generate a wrapper class that exposes the ActiveX Objects to .NET. I would spend some time learning how .NET does this. What I do create a dummy project and have .NET reference the ActiveX stuff I need. I then find the wrapper projects and DLL it made and move them into a central area. That why when I work on subsquent projects using the same ActiveX stuff I know where all the wrappers are.
You have to go to your class library properties and select the option "Register for COM interop". This will make your assembly available to COM.
You want to create what's called a COM Callable Wrapper (aka CCW) for your .NET component. This basically entails setting up some COM interfaces with some GUIDs and either enabling "Register for COM Interop" in the project properties (as mentioned) or using regasm.exe.