I am building a code generation tool using vs 2010 visualisation & modelling sdk. One of the things that I need to generate is a simple data capture ui (windows forms, preferably using devexpress layout control), with capture fields & labels for each property in a class.
I can use t4 text templates to do this, but I am conscious that I will be re-inventing the wheel if I do this - a simpler approach would be to add controls to a form constructed at runtime and allow the appropriate codedomseriaizer to generate the form.designer.cs code for me - is this possible?
To summarise, I would like to build a form at runtime, and retrieve a string of the designer.cs file..
Graham
Could you not simply leave the runtime generation code in use, and design only the other parts of the form using the designer? This way the autogenerated controls will be automatically updated if new properties are added to the class.
Related
I have a C++/winrt project with a complex and dynamic xaml interface created in C++ code. Now I am moving to the latest VS 15.9.0 Preview 3, which has platform support for C++/Winrt and also allows use of the xaml designer in such a project. But I don't want to use the designer and have turned it off in Tools/Options/Xaml. The result is that none of my programmatic xaml elements appears. The project seems to expect me to enter these elements in a xaml code page, rather than using C++, e.g. Grid(), StackPanel(), view.RowDefinitions.Append(), view.SetRow() etc. The GeneratedFiles folder is now full of items that were not present in the previous project, yet can't be removed. Is it still possible to use the C++ interface for xaml, and what must be done to enable it if so? Thanks.
Ryan is correct: C++/winrt does support programmatic creation of xaml, and it works great. With the help of a couple of c++/winrt guys at MS I think I also know why my code was not doing anything. In the former version of my app I had declared MainPage as a C++ class, not a struct, and had assigned the starting Grid for the xaml by getting the current Window and setting currentWindow.Content(theGrid). But in the new template app MainPage is a struct, which might matter, and while setting window.Content that way no longer works, this does: this->Content(theGrid). Leaving aside some irrelevant issues about declarations in the BlankApp, this I think is the answer. Programmatic xaml works if you set that initial content as above.
Unfortunately, this is not the intended way to use this UI system. XAML-based UI systems are descendants of WPF, which relies on the Model-View-ViewModel (MVVM) pattern.
This pattern intends three types of classes to make up your application: Views, which are primarily written in XAML, and only deal with displaying data they are given; ViewModels, which are the wrapper and translator to give the views data, and to give the models commands; and lastly, Models, which are your backend business-logic classes.
Your instinct to not trust the designer is reasonable - it generates messy and unidiomatic XAML code. But it is an excellent way to preview the way your XAML code looks.
To get back to your specific situation, there are real problems in the library's API that will be serious roadblocks to programmatically define a UI in C++. Instead, you will want to use XAML to declare the UI. Adding and removing grid column definitions is not something that is well-supported, but using StackPanels and DockPanels is the normal way to do this.
If you have more specific questions, feel free to open a new question here, but do bear in mind that you may want to search first under the tags mvvm and wpf in addition to xaml, c++-winrt, and winrt.
If you have more questions that are rather broad and may be too broad for the main site here, feel free to join the WPF channel on chat, but bear in mind that most of us don't have experience in WinRT specifically.
I'm using a VB6 application as a reference and have come across imgMain. I'm assuming its an image control, however, I cannot find the object on any of the forms. It's used to load the image. I'm just not sure what's going on with this. I'm assuming its an IMAGE CONTROL, but I cannot find this on any of the forms? it's mentioned a lot of times in teh application as it lets you view incoming faxes and stuff.
Without having a look on source code i assume It might be custom user control that was created for some reasons probably to extend basic picturebox control.
One thing i can advise you is to further inspect code and dig to code of this custom control. If code for this control is not available then see what methods and properties instances of that particular control uses and compare them with regular picturebox.
Often, when I'm looking for information of how to set certain properties of controls (I'm using Visual Studio primarily, but this question does apply to any IDE), the examples I find normally involve programatically setting said properties.
Here's an example, using the DataGridView.DefaultCellStyle property on MSDN:
http://msdn.microsoft.com/en-us/library/system.windows.forms.datagridview.defaultcellstyle(v=vs.110).aspx
So my question is: is it better for a programmer to modify these properties by code, or is it better to use the IDE itself to change them via the properties pane? I realize that doing it the latter way will result in auto-generated code anyway, but it will be "somewhere else" in relation to the main bulk of user-generated code.
It depends on your requirements. If the app you are developing is planned to be dynamic, then it is a good idea to do it the way it is described in the reference you provided. For example, you may create a class containing the method which will set the basic settings of the gridview, so on every page you may just call this method and pass to it the gridview as a parameter instead of repeating setting the grid properties on every page.
Is it possible to configure a Ribbon (e.g. adding a tab etc.) in Office 2010 programatically via VBA? I.e. by writing VBScript code in a macro.
Br. Morten
You can manipulate a Ribbon tab and its controls using VBA, but you cannot create one. Not with the Object Model anyway. The best you could do - somehow - is to get some kind of OPC dll (like an ActiveX component) that handles opening/relationships/closing of OPC documents (like .docx documents) and old school MSXML for creating a ribbon definition and adding it to the package.
Have a look at this blog post for Excel
http://www.xtremevbtalk.com/showthread.php?t=265636
and this one for Word
http://www.wordarticles.com/Shorts/RibbonVBA/RibbonVBADemo.htm
If your UI is static, i.e. you don't need to programatically change the behavior of, or add/remove UI elements on the fly, you can define a customUI within a macro-enabled template. You can use your VBA functions as call-backs for the UI elements defined in the XML.
Have a look at this guide. In a nutshell, you define a customUI\customUI14.xml file within the .dotm archive. This XML describes your custom ribbon elements using this schema.
This definitely works for Word templates (.dotm files). I think a similar approach works for any OOXML format.
In my current job we are not allowed to use databinding. I’m currently using a code generator (ORM) to generate the data layer objects. In the past I usually generated a data source (from the object) and do a drag and drop to automatically add the controls (with the correct databinding to the WinForm).
Is there is a way to do something similar (programmatically) using Visual Studio?
I tried to use the a copy and paste approach (by analyzing the data of the control, in the clipboard, generated by VS), but unfortunately the format used by VS to serialize the control to the clipboard is binary (I was hoping that the format was XML because I can easy modify that). Other approaches I tried was generating the designer code using a code generator. Unfortunately this only works if I want to create a new form but it is, from a practical point, unworkable if you want to add new controls to an existing form.
Controls are just objects. Any properties you can set in the designer can be set in code as well. And event handlers are just delegates. You can build the entire GUI without using the designer at all -- just write the code. I've done this several times with dynamically-generated GUI elements.
Spend some time reading through the code that the Visual Studio designer generates, and you'll quickly see how to do the same things by hand.