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.
Related
ContentPage or ContentPage XAML ,Which is better to use for page design while developing Xamarin Forms application? Is there any advantage for one over another in app performance?
XAML vs code is entirely opinion based.
The general opinion seems to be that XAML as a markup language is much better suited and provides a much cleaner separation of the UI from the app logic.
I personally would never think of doing pages in code, XAML all the way.
Another point in favor of XAML is that if you use events or reference other controls (which, let's face it, every app does) you cannot even nest a bunch of initializers to build out a structured UI, you have to assign controls to named variables to be able to reference them. In XAML, you can add an x:Name at any point and you have a reference to that control from both code and the rest of the XAML markup.
The only thing you can't do in XAML is to dynamically programatically generate the layout or adjust it based on some runtime variables. But even here, it's best to layout the template in XAML, and then in code behind you can use the constructor (or override onappearing, if you want the page to change each time it's navigated to), and fill out the dynamic part from c# code.
Performance wise, there used to be a slight advantage to code pages, as XAML had to be parsed each time during runtime. However, for a while now, Xamarin.Forms has supported compiling the XAML files ahead of time, which means that they are more or less identical.
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.
I was looking at the Firefox Add-ons Manager UI (pictured below) and really liked the expandable list used to show settings or properties for each add-on.
Firefox Add-ons Manager http://uploads.tech-buzz.net/Firefox3Beta3ComingonMonday_859/get_addons.png
I liked it enough to want to include something similar in one of my applications. The problem is, I don't know, exactly what the control is called (it doesn't seem to be "expandable list"), nor do I know if there is an implementation available for use in my own application (so I wouldn't have to reinvent the wheel.)
This isn't the first time that I've seen some cool piece of UI and wanted to incorporate it into something I'm working on, but have had no idea if I would have to design it from scratch. So I generally end up reworking my UI to use standard UI widgets to save time.
This got me thinking, is there some place that has a catalog of a bunch of UI widgets with names and what platforms/languages they are implemented for/in?
UPDATE
Turns out this control is called a Rich List Box, and it seems to only be implemented in XUL.
To answer your question, no, there isn't a universal catalog anywhere, though MSDN is as good a place as any to find definitions of most common UI elements.
The specific widget you ask about is generally called an accordian (wikipedia)
Question ONE:
I'm still pretty new to .net, but have used Visual Studio for a few recent projects. I'm now working a new project and I was wondering if visual studio had anything built in that would allow you to browse all of the details about a control, etc..
Is MSDN the best place to go for this?
For instance if I wanted to see of all the methods, properties, etc.. Is there anything inside VS?
Question TWO:
Can anyone recommend, books, resources, that deal specificially with Visual Studio? What each window does, etc.. I have used it enough to complete a few projects, but I haven't seen much in the way of exactly what everything does and why.
Thanks for any suggestions.
Use reflector (it's free!) to get in-depth information about classes etc. Visual studio also has a built-in Object Browser.
P.S. Reflector allows you to reverse engineer assemblies as well, allowing you to view the actual code of a class / method.
P.P.S. Google is still a developer's best friend. Need information on a control, search for it on the web. (Which will lead you to MSDN a lot of the times, but will also get you examples and loads of blog entries).
Question ONE:
You can use the Object Browser (menu View\Object Browser) to see a hierarchical list of all known assemblies, classes, interfaces, enums, etc...
This only gives the signature of each item and not the code.
If you want to see the code, use .Net reflector.
You can also use the Object Browser in Visual Studio. There is usually an icon for it at the top (by the Toolbox, Solution Explorer, etc. icons) or you can navigate to it (View -> Object Browser). When it opens, you will see all of the libraries currently referenced (system and third party) on the left hand side. It's hierarchical, so you can start drilling down. There is a search box at the top, if you want to look for a particular class, method or library. That looks at all the system libraries, not just the ones referenced in your current project.
For more help with the object browser, look here.
Q1:
In Visual Studio:
Above the editor there are 2 dropdown lists:
Left: Shows Classes
Right: Shows Class Members
or Click View > Class View: to see all the classes in the whole solution
I had a similar rub when I started using VS after I had done a lot of Java coding. I was used to the Java API documentation to research properties and such.
I found the VS equivalent IMO, here:
http://msdn.microsoft.com/en-us/library/ms229335.aspx
You can browse every class method, property, constructor, etc. right there. Their examples are decent.
In response to question 1, what I usually do is highlight the bit of framework code I'm interested in and hit F1 to bring up the documentation. For example:
Button myButton = new Button();
If you highlight the first Button and hit F1, you'll get an overview on Buttons in Windows Forms. If you highlight Button() and hit F1 you'll get the documentation on the Button class constructor.
In response to question 2, I'm not sure a book is the answer. I think reading a book on all the components of Visual Studio might be overkill. I'd say to keep on hacking away at your projects and page-fault information in via MSDN, Google, and StackOverflow as you need it. As with any IDE and framework, the more you use it the better you'll get at navigating and learning the ins and outs.
We have an application that has to be flexible in how it displays it's main form to the user - depending on the user, the form should be slightly different, maybe an extra button here or there, or some other nuance. In order to stop writing code to explicitly remove or add controls etc, I turned to visual inheritance to solve the problem - in what I thought was a neat, clean and logical OO style - turns out that half the time inherited forms have a hard time rendering themeselves in VS for no good reason etc - and I get the feeling that developers and to some extent Microsoft have shunned the practice of Visual Inheritance - can you confirm this, am I missing something here?
Regards.
I thought they had more or less sorted the desktop designer issues in 2005.
Have you tried the usual culprits?
No abstract control types
No constructor arguments in any form
Initialisation moved to Form_Load as opposed to the Ctor
No controls in the same project as the usercontrol/form that they are put inside
Close all documents -> Clean -> Rebuild
Restart VS
I seemed to think that as long as you did all of the above it worked..... mostly.
I am studying towards the (admittedly soon-to-be-obsoleted) MCAD, and part of the WinForms element was Visual Inheritence.
I personally have had no major problems with it, however, there are considerations to take in to account.
For me, the main problem has always initialization.. You need to remember that the designer cannot/does not instantiate forms in the same way it does at run time (similarly, it cannot do this with web dev, which is why care is needed with custom control rendering).
Also, once a form is changed, a complete re-build of the project is required in order to propagate the changes to the form to the child forms that inherit from it.
I personally have seen no evidence to suggest that it has been "shunned". AFAIK, its still good practice to exercise code re-use where possible. Visual inheritance provides that.
May I suggest creating a new question with the actual problems you are having, with sample code? We can then look at it to see if we can get it working and explain why :)
I've seen some problems in VS2005 with this. They were mostly due to problems with construction of the forms-objects in the designer. There were issues with code that tried to access the database from the form-constructors etc.
You can debug issues like this by starting a second instance of visual studio and loading up the first instance in the debugger. If you set breakpoints in your code you can then debug what happens in the designers in the first instance.
Another problem I can remember was generics in form classes
public class MyForm<MyObject> : Form
this won't work
I often stumble upon such problems in Visual Studio. In many cases MSVS forms designer fails to render form correctly. Back in the days I worked with WinForms I had to do all kind of weird tricks to enable some complex scenarios. However I think that using visual inheritance is very beneficial and should not be thrown away regardless of MSVS designer bugs.
I think I've found a way how to avoid this problem.
Don't hook the Form_Load Event in your parent form, this will break the designer.
Also don't take the Default empty constructor away from Visual Studio in the Parent Form. If you want to have Dependency Injection, create another constructor.
Like this:
public ProductDetail()
{
InitializeComponent();
}
public ProductDetail(ISupplierController supplierController) : base()
{
InitializeComponent();
this.supplierController = supplierController;
}
You can then still do this from your inherited Form:
public NewProduct(ISupplierController supplierController)
: base(supplierController)
{
InitializeComponent();
}
This worked for me so far, and I had some weird designer issues too.
cheers, Daniel
Read this: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx
AFAIK, there are still issues with Visual Inheritance and objects that rely on collections for the design elements, typically grid controls etc. I believe MS still have removed the possibility of changing f.ex. a GridView in an inherited form/usercontrol etc. But other controls like TextBox, Form, UserControl, Panel etc. should work as expected.
I've so far had no problem with VI using 3rd party grid controls myself, but you have to be careful, in particular, removing items from collections MUST be avoided.