I'm developing my own WinForms designer. It must be able to load existing custom form types. One of the issues I hit is forms without a default ctor: My code currently instantiates the form before it can load it into the designer, which requires a default ctor.
OTOH, VS2008 is able to load such forms. I believe it doesn't actually instantiate my form (as noted in this question): Even default ctors are not executed. And it doesn't truly execute InitializeComponent(). I just added a messagebox in that function and it doesn't show.
It looks like it dynamically mimic the custom form type and executes only parts of the code in InitializeComponent which it thinks is relevant.
Does anyone know where I can find more information regarding how the VS designer works.
TIA.
Note: I found this related question without satisfying answers
EDIT: Additional info: Steve points me to CodeDom, which is very insteresting. My problem though is that the types I need to load into my designer are already compiled instead of being available as source code. I can't find any way to apply CodeDom deserialization to compiled code.
Found this here:
When you open a new Windows
Application project in VS, you see an
empty form called Form1 in design
view. Now, you haven't built the
project yet, so how is the designer
able to create an instance of Form1
and show it? Well, the designer is not
really instantiating Form1 at all. It
is creating an instance of the base
class of Form1, i.e.,
System.Windows.Forms.Form. With a
basic knowledge of object oriented
programming, you will find that this
intuitively makes sense. When you are
designing Form1, you start with the
base class, Form, and customize it.
This is exactly what the designer
helps you to do.
Now let's say you added a bunch of
controls to the Form and closed the
designer. When you reopen the
designer, the controls are still
there. However, the base class Form
doesn't have these controls on it, so
if the designer isn't running the
constructor of Form1, how did it show
the controls? The designer does this
by deserializing the code in
InitializeComponent. Each language
that the designer supports has a
CodeDomProvider that is responsible
for providing a parser that parses the
code in InitializeComponent and
creates a CodeDom representation of
it. The designer then invokes a set of
CodeDomSerializers to deserialize this
into actual Controls (or more broadly,
Components) that it can add to the
design time Form. Now, I have glossed
over a lot of details in that
description, but the point here is
that Form1's constructor and
InitializeComponent are never really
invoked. Instead, the designer parses
the statements in InitializeComponent
to figure out what controls to
instantiate and add to the form.
The above is how Windows Forms designer in Visual Studio loads a form. If what you are looking for is a way to create an instance of a form that has no default constructor and still have access to the contained components/controls, I'm not aware of a solution. The only method I'm aware of that allows you to bypass the lack of a default constructor is FormatterServices.GetUninitializedObject, but beware ...
Because the new instance of the object
is initialized to zero and no
constructors are run, the object might
not represent a state that is regarded
as valid by that object.
I too have an app that requires instantiating compiled forms but have always used Activator.CreateInstance and required other developers to include, at the very least, a private default constructor if they want their form accessible in my app. Since we own the entire codebase and everyone is aware of the requirement, this isn't a problem and works out well for us.
As an addition to Steve's answer, if you add a new Windows Form to a project, but make it abstract, you can still open it in the designer. However, if you add another form, and have it derive from the first (abstract) form, you get an error when attempting to open the form in the designer.
Related
I am wanting to rewrite one of my Revit Add ins so that it utilizes WPF with MVVM because I like the look and functionality of WPF better than Windows Forms.
I have used the Revit Template Wizzard from Jeremy Tammik for the Form based add in, but adding a WPF user control seems not to work (a run time error that the xaml resource cannot be found).
I found a WPF MVVM revit add in example (AddMaterials, here is the github link, which will add materials from an Excel spreadsheet) but it does not follow what I am expecting to see at the top level.
Revit Add ins have an app.cs file which tells Revit how to register and access the DLL (ribbon panel buttons etc).
A windows WPF app will have app.xaml as the top level entry point.
The Add Materials project has neither which tells me that it must be
a class library, however the views are not using UserControls
rather they are Windows which I prefer. However Visual Studio does not
let you add a Window for a Class Library type project.
The third issue is easily solved by simply copying windows from a WPF application project into a class library project. But I don't really understand how the class library will instantiate in Revit without following the app.cs code from the template. Is anyone else creating add-ins this way, and if so can you let me in on any tricks or discussions that will help? Has anyone created a WPF Revit addin template for Visual Studio?
When I add a WPF window and try to instantiate it I get an error that it cannot find the xaml resource (System.IO.IOException: Cannot locate resource 'xxxx.xaml'). I have tried to fix this according to advice found when googling for this error, but to no avail. I am thinking it comes from being in a form based project, and that I may have to just start with a new project without the form stuff.
I have now verified that indeed you can start with the Revit AddIn Wizzard and use WPF . . . I started from scratch and copied in a window created in another project and got it to run (after adding the various references, namespaces, etc). So my problem seems to just be with the original project which already had a bunch of form stuff added.
Yes, I'm using WPF to create Revit Addins. It works well. You can easily create your own WPF template from the SDK samples:
Start with one of the Autodesk-provided SDK samples. I used the "DockableDialogs" sample. I know this one works, your mileage may vary with the others. If you're looking for windows rather than docked panes in the UI, another sample (perhaps the AddMaterials sample) is probably simpler.
I used Visual Studio to turn the sample into a template. File - Export Template -> select "DockableDialogs" or other WPF sample project.
Create a new project based on the template you just created. This was the easiest method I could find to get the WPF internal bits wired up correctly.
I'm not specifically familiar with the AddMaterials project, but to clarify your bullet points.
Revit Addins - It's not the file name (app.cs) but rather they must extend IExternalApplication or IExternalCommand. If you are creating a xaml interface (rather than just running a command from a ribbon button) you'll use 'IExternalApplication' as your entry point. Look for something like this in the sample:
public class ThisApplication : IExternalApplication ...
I don't used a top level app.xaml, but instead have page.xaml pages which are called by the Revit app. In my case these are Pages rather than Windows, which extend the IDockablePaneProvider class. These must be registered with the application which can then can be show, hide, etc your Panes. I imagine this is simpler with Windows, but haven't done it myself. For the dockable panes, your xaml.cs should start out something like:
public partial class MainPage : Page, Autodesk.Revit.UI.IDockablePaneProvider ...
Yes, the project is a class library in the sense that it is a collection of classes, at least one of which extends IExternalApplication or IExternalCommand. Remember that you're not creating a standalone application, but adding functionality to an existing Windows application (Revit). Revit will instantiate the ThisApplication class and then call its .OnStartup() method when the Revit application starts. This shouldn't stop you from adding .xaml or .cs files to the project, though. I can do it using VS Community 2015 using Ctrl-Shift-A.
Hopefully this gets you started - I've been able to implement a WPF UI in Revit without any prior WPF experience, and I'm not even a real programmer, so it's definitely possible. Good Luck!
addendum
If you want to add WPF elements to an existing revit addin, you can follow the instructions here: How can I connect xaml and xaml.cs files
Ultimately I found it easier to migrate my addin code into a template made from a working sample, you may want to try this approach as well.
VS 2010, Windows 7: Windows Forms - I have a number of forms that contain user controls that reference domain model objects. Some of the controls reference single objects and some reference collections of domain model objects. When I open the project or individual forms, the IDE will check out the forms and add dummy domain model objects. In some cases, this has no serious side effects and in others this result in the app crashing. Why is this happening and how do I prevent this from happening in the future? I would like to get to the point where the designer doesn't add anything extraneous - I can crash the system on my thank you very much. Thanks.
The designer will create a default instance for each public property contained in child user-controls in the current control it is displaying. This can be changed using the DesignerSerializationVisibilityAttribute setting the visibility to DesignerSerializationVisibility.Hidden.
This tells the designer to leave those properties alone.
You will likely have to go through the designer file itself and remove the old allocations and assignments for the properties you marked.
I have had a look at Another Question, however the error I am getting is more specific.
This sample data uses a view model, which does not have a default parameterless constructor, it does have a public parameterised one though.
I believe that design time data uses reflection and should be able to deal with this (as it doesn't actually instantiate the class). Hence it confuses me as to why I get the following error at design time:
The type "AccessDeniedViewModel" does not include any accessible constructors.
The line in my XAML, which includes the design time data is d:DataContext="{d:DesignData /SampleData/AccessDeniedViewModelSampleData.xaml}". I used Blend's 'Create Sample Data from Class...' to generate this data file.
When I open this view in Visual Studio 2010 however, it is fully able to display it along with the design time data.
I do not really want to place parameterless constructors merely for use at design time, any way to get this design data working in Blend would be very much appreciated.
EDIT: I should also mention, the binding support is still there, when I add bindings to the view, the available properties are listed, like it is resolving to the correct type, just unable to instantiate it.
You will need to supply a default constructor. Here is why: Why XML-Serializable class need a parameterless constructor
The only other option I can think of is writing logic in your view's constructor which loads the xaml at design-time so you are able to call the parameterized versions of the constructors.
At best, I am a UI novice, but I am a pretty good OO developer (if I don't say so myself). I am confused as to how to work with the designer. I am developing a Windows Forms application. I have a control (TabPage) that I derived from System.Windows.Forms.TabPage that I want to place on a System.Windows.Forms.TabControl control.
public class MyTabPage : TabPage
{ ... }
I am not sure how to get the designer to use my control.
A fellow developer looked at this for me as suggested that I add more information.
I've prototyped a WinForms application. The application has a TabControl, with three tab pages on it. Each TabPage has a SplitterControl with a DataGridView control in each half of the splitter. The two DataGridView controls form a master-detail view of some data we need to edit. I've added a bunch of event handlers to each DataGridView control and each time the handler code is placed in the form. The form is getting pretty crowded and would like to use OO techniques to clean things up.
I would like to redo the prototype now and because each TabPage is behaviorally identical, I would like to use OO to abstract away some of the complexity. This is where my lack of experience with the designer comes in. There must be a way to use the designer for something more complex than my origonal prototype.
You aren't really changing the behavior of the TabPage, it's just a container after all :). The TabPage and TabControl are rather tightly coupled, and they probably should be. Your "control" is what should be placed on the TabPage. So define your user control as a panel with a splitter and two datagridviews and then just drop your user control on each TabPage in your app. The Tab Control/Page tandem will still work automatically and your custom code will be in the appropriate control.
Unfortunately, there's no real practical solution to your problem. You'd have to create a custom TabControl as well and give it its own designer so that it will create instances of your derived class instead of the default TabPage class.
Sadly, the TabControlDesigner class in System.Design.dll is internal and can't be derived from. You'd have to write a complete replacement for it. That's difficult, it is a pretty advanced designer. You could have a look-see with Reflector to find out what it takes.
UserControl
Simply create a user control that contains your control. Then it will be available in the ToolBox window of Visual Studio.
For more details, Understanding the User Control Designer...
A User Control is similar to any other
class, but with the added ability to
be placed in the Toolbox and displayed
on a form.
The tutorial differs a bit from Visual Studio 2010 but I'm sure you will get through it.
TabPage Control
As for the TabPage control, you can't use it stand-alone in the designer. It must be part of a TabControl.
The TabControl is built to contain TabPage controls. If you use the designer to add/remove any TabPage, in the back-end it does "new TabPage", it can't determine that it needs to create a new instance of your derived class of TabPage.
Other Suggestion
A TabPage is just a container, I can't figure out why you need to override the TabPage control. I know you have added some information to your question but you may have to revisit it again so we can better understand.
Since the TabPage is a container, you should create a UserControl which contains your SplitContainer and DataGridViews. Therefore you would be able to reuse that UserControl on each TabPage.
The designer is just a complement to UI programming, it is not mandatory. You can add a UserControl to a TabPage without using the designer.
I may be off the track here, if so please provide more details. A visual prototype of what you need may help.
It's been a while, but I thought I would answer this question.
I was able to get the OO implementation I wanted by splitting the control up. The control is implemented pretty much the same as the prototype. I then created a control binder class hirearchy with derived classes to contain the specific behavior(s) I needed. The control has a reference to the binder base class and calls binder functionality as needed. The derived binders override properties and methods as necessary. Pretty much a textbook OO solution.
Where I was stumbling was in thinking that I needed to have a control hirearchy.
Thanks everyone for your help. I was under some pressure when I asked this question. It's amazing how much I've learned in the months since.
I've done .Net development for awhile but I'm new to the WPF technology. What is the supposed purpose of App.xaml? Also, what type of xaml code do you usually put in it? It seems like for simple applications it could be ignored and left untouched. Is this true?
App.xaml is the declarative portion of your code (usually generated by Visual Studio) extending System.Windows.Application. For example, Expression Blend can use App.xaml to share a Resource Dictionary or a design-time data set with your entire application. And, because we are using Microsoft products, whatever Expression Blend can do auto-magically, we can do by hand in Visual Studio.
Now the tangent: To me, to ask about the purpose of App.xaml is to ask about the purpose for System.Windows.Application. Feel free to accuse me of changing the original question (let the digital brutality ensue).
You can’t just open a System.Windows.Controls.Window in any Assembly you like… Chris Sells is likely telling me this in his book. I began to understand the purpose of System.Windows.Application while using MEF and MVVM Light to display WPF windows in DLLs (not EXEs). I got errors like this:
The type 'System.Windows.Markup.IComponentConnector' is defined in an assembly that is not referenced.
or
The type 'System.Windows.Markup.IQueryAmbient' is defined in an assembly that is not referenced.
The above error is simply saying that I’m trying to open a WPF Window inside of a DLL and not an EXE. Then, there’s this error:
The component 'Songhay.Wpf.WordWalkingStick.Views.ClientView' does not have a resource identified by the URI '/Songhay.Wpf.WordWalkingStick;component/views/clientview.xaml'.
This boils down to the absence of a facility that associates WPF Window XAML with the WPF “code” (an instance). This facility is associated with WPF EXEs and not WPF DLLs. Visual Studio auto-generates a WPF EXE class called App.g.cs (in your \obj\Debug folder) with this call in it: System.Windows.Application.LoadComponent(this, resourceLocater) where resourceLocater is a badly named variable containing a System.Uri pointing to the XAML like ClientView.xaml mentioned above.
I’m sure Chris Sells has a whole chapter written on how WPF depends on System.Windows.Application for its very life. It is my loss (quite literally of time) for not having read about it.
I have shown myself a little something with this unit test:
[STAThread]
[TestMethod]
public void ShouldOpenWindow()
{
Application app = new Application();
app.Run(new Window());
}
Failing to wrap a new Window in the System.Windows.Application.Run() method will throw an error from the land of COM talking about, “Why did you pull the rug from underneath me?”
For simple applications, it is true, it can be ignored. The major purpose for App.xaml is for holding resources (style, pens, brushes, etc.) that would would like to be available through out all of the windows in your application.
It is true. App.Xaml is some sort of central starting point. You CAN use it, or you CAN start your first window (it is defined in the app.xaml) manually. There are some lifetime events there centralls (like application start).
Storing resources that are used across the whole application.
Application is the root of the logical tree.
It is like Global.asax if you are coming from an ASP.NET background. You can also use it to share resources throughout your application. Comes in pretty handy for resource sharing.
App.xaml is a major part of wpf application.
It contains major four attributes
1.X:Class->used to connect you xaml and code-behind file(xaml.cs).
2.xmlns->To resolve wpf elements like canvas,stack panel(default one).
3.xmlns:x->To resolve XAML language definition.
4. StartupUri->To give start window when application is launching.
++++++++
App.xaml is the declarative starting point of your application. Visual
Studio will automatically create it for you when you start a new WPF
application, including a Code-behind file called App.xaml.cs. They
work much like for a Window, where the two files are partial classes,
working together to allow you to work in both markup (XAML) and
Code-behind.
App.xaml.cs extends the Application class, which is a central class in
a WPF Windows application. .NET will go to this class for starting
instructions and then start the desired Window or Page from there.
This is also the place to subscribe to important application events,
like application start, unhandled exceptions and so on.
One of the most commonly used features of the App.xaml file is to
define global resources that may be used and accessed from all over an
application, for instance global styles.
+++++++++
Source : http://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Here is an updated answer in case people are still looking.
There is this excellent article on WPF, and the link specifically puts you at the App.Xaml point to begin teaching you the things you can do with it.
WPF is easy for the first very simple app or two. However, due to the increased flexibility of the framework, you need these types of tutorials to help you understand what can be done from where (in the various application files).
https://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Good luck.