I need to put some activeX in my .Net WinForm.
The provider had sent me a .tlb and the com .dll.
Is this enough?
How do I put it on winform?
That should be sufficent. You'll need to register that dll on your machine, add it to the dev studio Toolbox (Right click on the toolbox/Choose Items) and go to the COM tab, if you can't find it in there you can browse to the specific location and select the Type Library to use.
After that you can just drag the new control to your form. A Reference to the library will be added to your project automatically.
see "Adding ActiveX Controls to Windows Forms"
I have a similar problem (similar to the one described in this comment activex in winform ) with Visual Studio 2010 and an MFC application (instead of a Winform).
I have the my.ocx file and I registered it correctly with regsvr32 but I get the "Self-registration for my.ocx failed".
This link http://www.codeproject.com/Questions/262206/ActiveX-Problem-Unspecified-Error gives me some relevant info. I quote it:
Hi I have done some research regarding registering ActiveX control
library in this area and I found that If am developing ActiveX
control for 64 bit Operating Syatem and 64bit Aplication Then in this
case we have to register this activeX control for both 64bit and 32bit
operating system 64bit ActiveX control in System32 folder for 64bit
operating system 32bit ActiveX control in SysWOW64 folder for 64bit
operating system,
For this we have to generate both version of ActiveX control in MFC x64 and Win32 both version
Thankx
I looked in the registry at the key HKEY_CLASSES_ROOT\TypeLib\{myocx_typelib_id}\1.0\0\ and I found the two keys win64 and win32. The win64 was pointing to the right ocx file while the win32 was pointing to the wrong ocx file (In my case the typelib is embedded in the ocx file). I correct the registry and solved the problem of "self-registration for my.ocx failed". In my case I have two different my.ocx files, the first is for win32 and the second is for win64.
Related
we are trying to use an activex control from WPF to save a rewrite right now. Found this article , https://msdn.microsoft.com/en-us/library/ms742735(v=vs.100).aspx that refers to the Windows Forms Control Library Template. now I have Visual Studio 2015 Community Edition and there is no such template. Googled and just found pages with no usable content. was wondering if I could be pointed to where this exist or is there an alternative?
The Windows Forms Control Library Template is a litte bit difficult to find. In my Visual Studio 2015 implementation I have it in the directory Visual C#\Windows\Classic Desktop. If you don't have this template, at least for Windows Forms you can also choose template Class Library and later change it in in such a way that you can use the Testcontainer when debugging your class library.
For how to achieve this see the post of Arnshea (6 upvotes) in this link A project with output type of class library cannot be started directly - with a startup exe. I have used his technique when I accidently used the wrong template when starting my projects.
Regards JRB
How do I get the dialog box titlebars to be thick in my applications like the dialog boxes in Windows 10. I have noticed a behavior where if the minimum Windows version is set to 6.0 or higher in the linker options it will cause the titlebars to be thick.
I have <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> in my application manifest yet if I set the minimum Windows version in the EXE file with the linker to 5.01 (for XP compatibility) the titlebars will be thinner.
The application is written in a mix of C and C++ and uses plain Windows API.
Is there any way to get titlebars in dialog boxes to use the non-backwards-compatible behavior without dropping XP support for my application?
In the end, I am pretty much convinced it is an internal behavior of the window manager, and as such I am now distributing two versions of my application: An XP-compatible version compiled in Visual Studio 2010 and a Vista+ compatible version compiled in Visual Studio 2017, which also requires a SSE2-capable processor to run.
What you can do is set your dialog box as borderless and draw your own title bar and close button. That would guarantee portability amongst all platforms, as drawing would then be entirely specified by your code, rather than allowed to the discretion of the operating system API.
We are using an embedded Visio drawing control in our application as an automated visualization tool to represent system heirarchies. Code-behind uses Visio interop to create and lay out all of the shapes. The "designer" portion, with the embedded Visio document, is accomplished through a custom control that utilized the (ActiveX) Visio Drawing control within a WindowsFormsHost control.
This approach has worked well for several years, up to now. We first implemented in VS2008/Visio 2007, then migrated to VS2010, and then Visio 2010. Once we had moved to VS2010/O2010, we added another build targeted for x64.
To do this, I had to rebuild the ActiveX control. Since VS designer doesn't support the 64-bit version of the Visio Drawing control, you can't just simply create a WindowsFormsHost and drop the Visio Drawing control onto it; the WPF control has to be built differently from the way the 32-bit version is. I can't remember exactly how I did it, but I think it was basically this (possibly based on this):
Create a WPF form in a build environment with 32-bit Visio installed
Drag/drop the Visio Drawing control from the toolbox to the form, inside a WindowsFormsHost. Performing this step causes VS to create (and add a reference to) a new DLL, "Microsoft Visio 15.0 Drawing Control Type Library" of type AxMicrosoft.Office.Interop.VisOcx. This DLL is put into the /obj/Release directory under the project.
Build the project to create the WPF control DLL for the final x86 solution build
For your 32-bit solution, copy & reference both {your control}.dll and AxMicrosoft.Office.Interop.VisOcx.dll.
Save, copy/move & open this control project in a build environment with 64-bit Visio installed
Change the build target to x64
Build the project to create the WPF control DLL for the final x64 solution build
Copy & reference /bin/Release/{custom control}.dll and /obj/Release/AxMicrosoft.Office.Interop.VisOcx.dll.
I can build for the 32-bit version, but this doesn't work with Visio 2013 64-bit. Any clue how to get this done?
I finally got our solution to work using 64-bit.
The magic was that I realized that I didn't actually need the control in the XAML; so what I ended up doing was removing the control from the XAML page, and instantiating it from the constructor of the .xaml.cs code.
So: follow the instructions in this link to build a custom control. I think you have to build using the 64-bit version of MSBuild.exe as noted in the link you provided. This is apparently only required when you are creating the custom control; I was able to build the solution directly from VS (but it also worked correctly when built by MSBuild, so it works in automated builds, as well).
Creating a custom control
Create a new custom control project named VisioAxControl in a build environment with 32-bit Visio installed
In VS Designer, drag/drop the Visio Drawing control from the toolbox to the form, inside a WindowsFormsHost. You may need to add this control to the toolbox (right-click toolbox, "Choose items..."). Performing this step causes VS to create (and add a reference to) a new DLL, "Microsoft Visio 15.0 Drawing Control Type Library" of type AxMicrosoft.Office.Interop.VisOcx. This DLL is put into the /obj/Release directory under the project, but will be copied to /bin when you build if you simply select the reference and set "Copy local" to "true".
Open the code-behind and change the scope of the control to public and refactor:rename it from axDrawingControl1 to AxVisioControl (most importantly, don't forget this.AxVisioControl.Name = "AxVisioControl";)
Build the project to create the WPF control DLL for the final x86/32-bit solution build
For your x86/32-bit solution, copy & reference both VisioAxControl.dll and AxMicrosoft.Office.Interop.VisOcx.dll into a folder somewhere in the solution.
Building the 64-bit control
Save, copy/move, and open the custom control project in a build environment with 64-bit Visio installed
Change the build platform to x64
Open an administrator command prompt, cd to your project directory
Run MSBuild_Path\MSBuild.exe /p:Configuration=Release /p:Platform=x64 your_project_file_name (for me, MSBuild_Path is C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe) to build the custom control project to create the WPF control DLL for use in the final x64 solution build
Including in your 64-bit project
Copy & reference /bin/Release/VisioAxControl.dll and /obj/Release/AxMicrosoft.Office.Interop.VisOcx.dll.
In the XAML of your form, add a <WindowsFormsHost name="MyWindowsFormsHost"></WindowsFormsHost> control.
In the code-behind of the XAML, in the constructor:
using VisioAxControl;
public DesignView()
{
InitializeComponent();
var avc = new VisioAxControl() { Name = "vControl" };
this.MyWindowsFormsHost.Child = avc;
this._avc = avc.AxVisioControl; // for later reference, such as adding shapes
}
Save & Build your project!
Where can I find System.Windows.Controls.dll for Silverlight 3? I need it to be able to use the TreeView control and the AutoCompleteBox control. Toolkit November 2009 is installed but the dll that I need was not included.
The AutoCompleteBox and the TreeView are part of the SDK not the Toolkit. The dlls that contains them are found typically at the following paths respectively:-
C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Windows.Controls.Input.dll
C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Windows.Controls.dll
(Note use "Program Files (x86)" on 64 bit systems)
However you should add them simply by using the "Add Reference" dialog, they have the component names of System.Windows.Controls.Input and System.Windows.Controls.
What is in the Toolkit and what is in the SDK can be a bit confusing. This is typically because things have a habit of migrating from Toolkit to the SDK once it matures. A clever bit of QA that.
If Visual Studio 2010 based on WPF, why I cannot open it with reflector?
In other words, devenv.exe seems to be native assembly, so where is the WPF UI code?
The Visual Studio devenv.exe executable is indeed a native program. However, native programs can load the .NET runtime and thereby host Windows Forms and WPF components. In fact, Visual Studio has always done this. Even before VS2010 adopted WPF for its editor and shell, the various Visual Studio designers were implemented in Windows Forms. If you go into the Common7\IDE and Common7\IDE\PrivateAssemblies directories, you'll find lots of designer DLLs that you can view in Reflector (e.g. Microsoft.VisualStudio.ORDesigner.Dsl.dll is the LINQ to SQL designer).
So the new WPF bits of Visual Studio are just another set of managed assemblies hosted in the native executable. I'm not sure which particular assemblies host the WPF bits -- and to be honest there are probably dozens. But looking at the VS process in the debugger, I'd say Microsoft.VisualStudio.Editor.dll (which lives in the GAC, not in the VS install directory) would be a good place to start.