I just installed Visual Studio 2012 express for Desktop. I can't see any place to create a GUI application with C++ ! Where is this "Windows Form Application" used to exists in Visual C++ 2010 ? Where are these drag and drop controls? I installed this because I got details telling this supports GUI intellisense (Visual C++: Unable to invoke method from another class)
It is an unsubtle hint that they want you to stop creating C++/CLI Winforms applications. The plumbing is still in place however, at least for VS2012 and VS2013. This might not be the case in a future one.
You can turn a CLR console application into a Winforms application with these steps:
Start with File + New + Project, CLR node, CLR Console Application
Project + Add New Item, UI node, Windows Form
Project + Properties, Linker, System, SubSystem = Windows
Project + Properties, Linker, Advanced, Entry Point = main
Change the pre-generated .cpp file to look like this:
#include "stdafx.h"
#include "MyForm.h"
namespace ConsoleApplication45 { // Change this!!
using namespace System;
using namespace System::Windows::Forms;
[STAThread]
int main(array<System::String ^> ^args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyForm());
return 0;
}
}
Note that you'll need to change the namespace name to your project name. Press F5 to test. You can design the form as normal once everything checks out.
NOTE, Visual Studio 2015 has a nasty static initialization order bug in the CRT that can cause the app to crash instantly with an AVE at startup if the project contains any native C++ code. As yet an unfixed bug, the somewhat inevitable hazard of having these project templates removed. A possible workaround is to change the Entry Point (4th bullet).
For a project that targets x86, copy paste this string:
?mainCRTStartupStrArray##$$FYMHP$01AP$AAVString#System###Z
For a project that targets x64, copy paste:
?mainCRTStartupStrArray##$$FYMHP$01EAPE$AAVString#System###Z
Somewhere around VS2017 the designer fails to open a new form with a cryptic error message. Workaround is to build the project first, use Build > Build.
Remove the #include "stdafx.h" and this works well for VS 2022. The form must be hand coded since the Form Designer support was removed starting with VS 2012.
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
I just installed Visual Studio 2012 express for Desktop. I can't see any place to create a GUI application with C++ ! Where is this "Windows Form Application" used to exists in Visual C++ 2010 ? Where are these drag and drop controls? I installed this because I got details telling this supports GUI intellisense (Visual C++: Unable to invoke method from another class)
It is an unsubtle hint that they want you to stop creating C++/CLI Winforms applications. The plumbing is still in place however, at least for VS2012 and VS2013. This might not be the case in a future one.
You can turn a CLR console application into a Winforms application with these steps:
Start with File + New + Project, CLR node, CLR Console Application
Project + Add New Item, UI node, Windows Form
Project + Properties, Linker, System, SubSystem = Windows
Project + Properties, Linker, Advanced, Entry Point = main
Change the pre-generated .cpp file to look like this:
#include "stdafx.h"
#include "MyForm.h"
namespace ConsoleApplication45 { // Change this!!
using namespace System;
using namespace System::Windows::Forms;
[STAThread]
int main(array<System::String ^> ^args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyForm());
return 0;
}
}
Note that you'll need to change the namespace name to your project name. Press F5 to test. You can design the form as normal once everything checks out.
NOTE, Visual Studio 2015 has a nasty static initialization order bug in the CRT that can cause the app to crash instantly with an AVE at startup if the project contains any native C++ code. As yet an unfixed bug, the somewhat inevitable hazard of having these project templates removed. A possible workaround is to change the Entry Point (4th bullet).
For a project that targets x86, copy paste this string:
?mainCRTStartupStrArray##$$FYMHP$01AP$AAVString#System###Z
For a project that targets x64, copy paste:
?mainCRTStartupStrArray##$$FYMHP$01EAPE$AAVString#System###Z
Somewhere around VS2017 the designer fails to open a new form with a cryptic error message. Workaround is to build the project first, use Build > Build.
Remove the #include "stdafx.h" and this works well for VS 2022. The form must be hand coded since the Form Designer support was removed starting with VS 2012.
I must be brain dead. I have tried for six hours now (with Google) and can not solve this very very simple problem.
In Visual Studio 2010, I created a project. (right-click on solution, Add new project...).
Inside the new project, I created a new folder of name Helpers. To the folder I added a class for a converter.
Inside the project, I added a new XAML window (in WPF). The Target Framework is .Net Framework 4.0
Everything has been built (multiple times) without compilation errors. The platform target build for the project is X86.
The problem: Intellisense does not see the namespace for the class under the Helpers folder and so the Visual Designer fails. The namespace in the Helpers folder is:
Chaos.UI.Helpers
and trying to reference this namespace in the XAML like:
xmlns:converters="clr-namespace:Chaos.UI.Helpers"
ofcourse results in the dreaded:
Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'Chaos.UI.Helpers' that is not included in the assembly.
These are clean files in the same project. The only added code is in the converter class contained in the Chaos.UI.Helpers namespace.
How do I fix this? (I need the designer to work).
Anybody, Plz help
Try use assembly
xmlns:converters="clr-namespace:Chaos.UI.Helpers;assembly=Chaos.UI"
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!
I am compiling a Winforms app for use with Mono and using the .Net stuff built into Visual Studio 2008 for a Winforms app. Everything works fine, but I'd like to run without the terminal window opening.
Do I need to use gmcs to get this line to work:
-target:winexe
as seen here? Or can I do it with the built-in commands that Visual Studio uses for .Net?
In VS, make sure the project type is set to "Windows Application" and not "Console Application" on the project properties page.
If that doesn't fix it, try using monow.exe instead of mono.exe to run the application.