In VB6, ActiveX DLL is listed as a project template but in VS 2005+ there is no such thing. Where is my good old ActiveX DLL template? Many thanks in advance.
A couple of concepts; .NET Assemblies are the functional equivalent to ActiveX DLLs in the .NET langauges. .NET Classes and method can be decorated with attribute that have various meaning in different context. A .NET Assembly can be turned into a ActiveX/COM DLL (or OCX) by using various attributes to assign the correct GUIDs.
A basic overview of setting a .NET assembly use COM is here.
Note that do google searches you should include VB6 .NET and COM (not ActiveX). COM generates more hits as it is the underlying technology behind the ActiveX term.
The MSDN article I linked shows a basic COM setup for a .NET Class. The attribute here is the ComClass Attribute.
<ComClass(ComClass1.ClassId, ComClass1.InterfaceId, ComClass1.EventsId)> _
Public Class ComClass1
#Region "COM GUIDs"
' These GUIDs provide the COM identity for this class
' and its COM interfaces. If you change them, existing
' clients will no longer be able to access the class.
Public Const ClassId As String = "6DB79AF2-F661-44AC-8458-62B06BFDD9E4"
Public Const InterfaceId As String = "EDED909C-9271-4670-BA32-109AE917B1D7"
Public Const EventsId As String = "17C731B8-CE61-4B5F-B114-10F3E46153AC"
#End Region
' A creatable COM class must have a Public Sub New()
' without parameters. Otherwise, the class will not be
' registered in the COM registry and cannot be created
' through CreateObject.
Public Sub New()
MyBase.New()
End Sub
End Class
There are other Attributes as well that are especially useful if you trying to subsitute a .NET assembly for an existing COM DLL or OCX. Finally .NET has a lot of different wizards that help you with the tedious details.
Try this: http://msmvps.com/blogs/pauldomag/archive/2006/08/16/107758.aspx
It outlines how to create an activex control and use it in a web page. As far as I know there's really no 'ActiveX' project template since .NET does it differently. However you can make your .Net controls visible to the COM world, which the article above illustrates.
It's not quite clear from you question, but if you want to be able to consume in VB6 (or some other com environment) something created in VS2005, you want to look at the Interop Forms Toolkit. This greatly simplifies interop between VB6 and VS2005. Now if you actually want to distribute those applications, installing what you created becomes a lot more fun (Hints: Don't use the GAC, install the .Net dll in the same directory as your application executable, and learn to use RegAsm.)
If you give a little description what you want to use the ActiveX.dll for (project library or User Control) and what environment you want to use it, more advice can be given.
I don’t know if this is what you are trying to do or not. But if you right click on the Toolbox in Visual Studio, in the popup menu select Choose Item…
When you get the “Choose Toolbox Item” dialog box come up, select the “COM Components” tab and check the COM Component(s) you want to add to the toolbox. I have done this to added the “Windows Media Player” to the toolbox and used it in a C# Winform.
From this dialog you can access any COM, OCX or ActiveX control loaded on you system.
Related
I have run into a problem where I need to use an old API created in VB6 which requires a vba.collection to be used when referencing the API for something.
I can't do this in my .net project as it fails when trying to convert visual.basic.collection to vba.collection.
I have found a workaround but cannot create the vb6 dll as I do not have vb6 and I cannot get hold of a copy.
Below are the steps I need to carry out in VB6, could anyone kindly help me to create this dll so I can complete my project?
Many Thanks!
Create a Visual Basic 6.0 DLL that returns the collection
Create a Visual Basic 6.0 Microsoft ActiveX DLL project. By default, the Class1 class is created.
Rename the project CollectionFactory, and then rename the class clsVBACollection.
Add the following code to the clsVBACollection class.
' This function creates a new object of the VBA collection.
Public Function CreateVBACollection() As Collection
' Define a variable of type Collection.
Dim col As Collection
' Create a Collection object.
Set col = New Collection
' Return the Collection object.
Set CreateVBACollection = col
End Function
On the File menu, click Make CollectionFactory.dll.
I was able to create the dll in the MS article using VB6 and this solved my problem, I hope this hels someone in the future!
Using C++/CLI, How to display a managed control (eg. System::Windows::Forms::Panel^) on a window created in native code?
An external program calls my native method where i can access it's window via
SubclassWindow(hNativeWindow, MyNativeWindowProc);
Then I create control with something similar to:
MyNameSpace::MyControl^ ctrl = osozKomunikator = gcnew MyControl("SomeText", hNativeWindow);
ctrl->Show();
MyControl is derived from System::Windows::Forms::UserControl and has overriden CreateParams to set Parent to hNativeWindow.
As the result the control flashes and dissapears, does not show at all or shows only after I slow down the execution with the debugger.
Please help.
Windows Forms supports being hosted like ActiveX in native windows since .Net 1.1. The host needs to implement some interfaces, though. MFC 8.0 wrapped around the necessary code in CWinFormsDialog and CWinFormsView. Use MFC's support classes if you can. If you can not, install MFC from Visual C++ 2005 or higher and check the source code of MFC's OLE support classes, like COleControlContainer, COleControlSite, etc.
Simple question - I found two ways to add a tool window to Visual Studio (2008): create an addin or create a package.
(Addin: http://www.codeproject.com/KB/dotnet/vstoolwindow.aspx)
(Package: http://msdn.microsoft.com/en-us/library/bb165051.aspx)
What's the "right" way?
You can do either, and I've done both. In some ways, addins are a bit easier, but they suffer from some annoying drawbacks.
Add-in:
+No requirement to install the Visual Studio SDK
+No requirement to use a Package Load Key (PLK) or sign your distributed binaries
+Easier development process when you use the Extensibility API (simplified code in many ways)
+Easier installation process (no wacky registry stuff)
-Doesn't seem to behave as well as VSPackage-based tool panes
-I've run into performance issues which prompted me to use the VS SDK COM interfaces instead of the Extensibility ones, leading to a significant performance bump. In other words, my "add-in" is now based on the VS SDK and is only really an add-in because it loads via an XML file instead of the registry. (Also, from everything I can tell, the Extensibility interfaces are just a large utility wrapper around the SDK.)
VSPackages:
+You can harness the full power of the VS SDK, both its feature set and (potentially, when carefully used) performance advantage
+Seems to behave more reliably than add-ins
-Requires signed binaries, a PLK, and a complicated installation procedure
-Steep learning curve, and many seemingly simple actions are nasty/convoluted. I now have an assembly providing extension methods to perform "obvious (to me)" actions on the COM interfaces. Between that and experience things have improved over time. There are similar options available to the community, which you should seriously consider if you go this route.
I think 280Z28 was perfectly correct prior VS2010. But now VS2010 and VS012:
Do not require officially signed packages (may only those that go to the Gallery have to);
Thanks to VSIX it can very easily install VSPackages that can also be deployed to the Gallery.
Moreover VS2010 supports another kind of extensibility: those are MEF extensions, that are lightweight plugins that trigger only at specific events of the IDE, like text editor events. An example is FixMixedTabs extension.
Just a create a VSPackage empty package (no menus, commands, ...) and copy this in the main class to create a VSPackage that basically loads when there's an active solution and just get a reference to the DTE2. In this way you can just use it as an Add-in.
// This attribute tells the PkgDef creation utility (CreatePkgDef.exe) that this class is
// a package.
[PackageRegistration(UseManagedResourcesOnly = true)]
// This attribute is used to register the informations needed to show the this package
// in the Help/About dialog of Visual Studio.
[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
[Guid(GuidList.guidVSPackage1PkgString)]
// Load this package when a solution is loaded (VSConstants.UICONTEXT_SolutionExists)
[ProvideAutoLoad("{f1536ef8-92ec-443c-9ed7-fdadf150da82}")]
public sealed class VSPackage1Package : Package
{
/// <summary>
/// Default constructor of the package.
/// Inside this method you can place any initialization code that does not require
/// any Visual Studio service because at this point the package object is created but
/// not sited yet inside Visual Studio environment. The place to do all the other
/// initialization is the Initialize method.
/// </summary>
public VSPackage1Package()
{
Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
}
/// <summary>
/// Initialization of the package; this method is called right after the package is sited, so this is the place
/// where you can put all the initilaization code that rely on services provided by VisualStudio.
/// </summary>
protected override void Initialize()
{
Trace.WriteLine (string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
base.Initialize();
IVsExtensibility extensibility =
GetService(typeof(EnvDTE.IVsExtensibility)) as
IVsExtensibility;
DTE2 dte = extensibility.GetGlobalsObject(null).DTE as DTE2;
}
}
If you are just creating a simple tool window then I suggest going the Add-in route.
Both Packages and Add-Ins are ways of extending Visual Studio. Generally speaking they have the same functionality. Packages are a bit more powerful and allow deeper integration into Visual Studio. But that deeper integration comes with a cost including bigger ramp up times and installation procedures.
Add-ins are designed to be a more light weight extension mechanism. Smaller ramp up time and easier installation.
If all you are doing is tool window with basic interaction of the editor our code model then add-in is the best route.
I was wondering how Visual Studio associates MFC CDialog derived classes with their corresponding dialog resources. I'm not interested in how the connection is made at run time (as asked here), but rather at design time.
When I add a message handler to a dialog, how does it know which class to add the handler to.
Also, is it possible to have several CDialog derived classes associated with the same dialog resource and vice versa?
I have searched the project directory for the IDD_SOMEDIALOG string but have only found it in SomeDialog.h, resource.h and Project.rc in the expected places so I guess it somehow deduces the connection from those files, most likely the enum in SomeDialog.h:
// in class CSomeDialog:
enum { IDD = IDD_SOMEDIALOG };
I'm asking this mostly out of curiosity.
It depends on what version of dev studio.
In VS6 it was all kept in the CLW (Class Wizard File).
In newer versions of dev studio it doesn't use the CLW anymore and I don't know specifically how it knows, but i suspect its a live parsing instead of using a cached CLW.
As for having multiple derived dialogs using the same resource, it can be done manually. You can duplicate the created class files and rename them and remove the enum from header and edit the use of the IDD enum in the source file to be the actual dialog resource id (IDD_SOMEDIALOG).
AFAIK Dev Studio will only 'happily' handle one class to a dialog at a time. In my experience trying to re-use a dialog resource like this just ends up in a bit of battle with MFC & Dev Studio since they were not intended to do this.
To add to Ruddy's answer:
I noticed that some of my dialog classes in which I replaced the enum { IDD } with static const int IDD was not any longer associated with its dialog resource. Reverting to the enum re-associated them. So it seems that visual studio parses the source code to determine the relationships.
As for resource sharing, it would be ambiguous as to which class should receive the event handler code. Class sharing seems to be be impossible since it relies on the IDD which can not be assigned to a IDD_SOMETHING and IDD_SOMETHING_ELSE simultaneously.
I am writing a PropertyPage for Outlook using VB6. This is implemented as a VB6 OCX.
When running in a newer version of Outlook (like 2007) on XP (or newer), my dialog looks weird because it doesn't have XP look and feel. Is there a way to do this?
Preferably without adding a manifest file for Outlook.exe.
I think you're right to avoid using a manifest. Unfortunately the standard well-known hacks to support XP themes from VB6 rely on manifests. This MSDN article on developer solutions for Outlook 2007 warns that providing your own manifest for Outlook 2007 might cause it to hang.
I don't think you can do it in VB6 ... those controls are going to look like what they look like. You can, however, create your property pages with Visual Studio .NET and Visual Basic .NET and get the XP, 2007 and Vista look and feel. It's a bit of a change from what you're doing, but you're really behind the times developing with VB6 anyway. More details on how to do that are here and the office developer center.
Not that I know of using VB6
If you can use .NET instead - one way is WPF. I saw earlier an example on code-project.
Here's the link
Edit: And another tool to assist here
This is what I do in all of my VB6 Apps, only ever tested in a standalone EXE so not sure if it will work as an OCX.
Private Type tagInitCommonControlsEx
lngSize As Long
lngICC As Long
End Type
Private Declare Function InitCommonControlsEx Lib "comctl32.dll" _
(iccex As tagInitCommonControlsEx) As Boolean
Private Const ICC_USEREX_CLASSES = &H200
Public Function InitCommonControlsVB() As Boolean
On Error Resume Next
Dim iccex As tagInitCommonControlsEx
' Ensure CC available:
With iccex
.lngSize = LenB(iccex)
.lngICC = ICC_USEREX_CLASSES
End With
InitCommonControlsEx iccex
InitCommonControlsVB = (Err.Number = 0)
On Error Goto 0
End Function
Public Sub Main()
InitCommonControlsVB
'
' Start your application here:
'
End Sub
Create a file similar to this: http://pastebin.com/f689388b2
Then you add the manifest file to your resource file as type RT_MANIFEST (24)
I can't quite remember if that's all you need to do as I always just use the same pre-made .res file now.
Source: http://www.vbaccelerator.com/home/vb/code/libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp