What to use in UWP, Binding or x:Bind and what is the difference between them?
Because I see a lot of posts where people use Binding and I only Bind with x:Bind in UWP.
At the MSDN Homepage it only says that "the binding objects created by {x:Bind} and {Binding} are largely functionally equivalent." and that x:Bind is faster.
But what is the difference between them?
Because "largely functionally equivalent" does not mean equivalent.
The Link from my Quote: MSDN
So my Question is:
What is the difference in using Binding or x:Bind in UWP?
The following is probably not complete, but some of the major differences are
Old style {Binding }
binds to the DataContext
binds to a Property Name, flexible about the actual source type
New style {x:Bind }
binds to the Framework element (code-behind class)
needs all types fixed at compile time
defaults to the more frugal OneTime mode
And starting with build 14393, {x:Bind } supports:
direct BooleanToVisibility binding, without a ValueConverter
expanded Function binding
casting
dictionary indexers
The newer {x:Bind } is a little faster at runtime but just as important it will give compiler errors for erroneous bindings. With {Binding } you would just see an empty Control in most cases.
For in-depth comparison checkout: {x:Bind} and {Binding} feature comparison
{x:Bind} executes special-purpose code, which it generates at compile-time. {Binding} uses general-purpose runtime object inspection. Consequently, {x:Bind} has great performance and provides compile-time validation of your binding expressions. It supports debugging by enabling you to set breakpoints in the code files that are generated as the partial class for your page.
Because {x:Bind} uses generated code to achieve its benefits, it requires type information at compile time. This means that you cannot bind to properties where you do not know the type ahead of time. Because of this, you cannot use {x:Bind} with the DataContext property which is of type Object, and is also subject to change at run time.
The {x:Bind} markup extension—new for Windows 10—is an alternative to {Binding}. {x:Bind} lacks some of the features of {Binding}, but it runs in less time and less memory than {Binding} and supports better debugging.
Related
F# doesn't support partial classes nor precompilation of XAML files. The workaround: instead of compile-time code behind, load graphical object definitions at runtime. There are various ways to supply XamlReader with the content of a referenced resource file.
open System.Windows
// from Resource
let uri = System.Uri "pack://application:,,,/AssemblyName;component/MainWindow.xaml"
let info = Application.GetResourceStream uri
let wnd = Markup.XamlReader.Load info.Stream :?> Window
// from Embedded resource
let assembly = System.Reflection.Assembly.GetExecutingAssembly()
let stream = assembly.GetManifestResourceStream "MainWindow.xaml"
let wnd = Markup.XamlReader.Load stream :?> Window
Type providers should be able to shift at least part of that effort back to compile-time.
open FsXaml
type MainWindow = XAML<"MainWindow.xaml">
let mainwnd = new MainWindow()
let wnd = mainwnd.Root
The gain in type safety (and discovery) seems to be marginal: one runtime type cast less per resource. Are there other advantages?
The gain in type safety (and discovery) seems to be marginal: one runtime type cast less per resource.
There are other advantages here, even in the code you displayed. Using FsXaml is far more concise in your example, and fully type safe. It will also fail at compile time if there are major issues in your XAML files, where using XAML Loader defers this to runtime.
Are there other advantages?
There are many advantages -
Shorter code
Type safety
Named elements exposed as properties in a type safe manner
(Most important) Creates actual types corresponding to your XAML types
The last point is really the "killer" advantage of FsXaml vs XamlReader - without this, it's nearly impossible to do anything beyond "toy" projects in WPF. You need to have "real types" corresponding to your types if you want to be able to embed XAML.
For example, if you want to use UserControls you develop as data templates, you need that UserControl to be an actual type, not just some XAML as a resource. Using XamlReader, there's no way to reference that from other XAML. You also can't reuse resources, pull data into your Application, or many other things (without resorting to hand-writing a huge amount of plumbing to do it at runtime).
In addition, with FsXaml 2+, you can subclass types and provide full logic within the "code behind", similarly (though differently) from how you work in C#.
This brings Xaml much, much closer to the experience when working in C# - There is still no BAML compilation (the one disadvantage), but otherwise, you get an experience that is effectively on-par with C# when working from F# with WPF.
A type provider checks things at compile time, the Xaml reader works at run time. Thus errors are either detected at compile or at run time. It is pretty obvious that finding errors earlier in the development process is better.
I have a COM component that has get_XXX and put_XXX methods inside it. I used it in a .NET project and a RCW was generated for it. I now see get_XXX and set_XXX methods and NOT the put_XXX one? Is that automatic or defined somewhere in IDL?
These are property accessor methods. A compiler that uses the COM server is expected to generate a call to get_Xxx() when the client program reads the property, put_Xxx() when it writes it. A special one that C# doesn't have at all is putref_Xxx(), used to unambiguously access an object instead of a value.
The normal translation performed by Tlbimp.exe is as a plain C# property. But that doesn't always work, C# is a lot more strict about what a property can look like:
The default property, the one that's annotated as DISPID_VALUE (dispid 0) must take a single argument to be compatible. This maps to the C# indexer property, the one that makes it look like you are indexing an array.
Any other property cannot take an argument, C# does not supported indexed properties other than the indexer.
C# does not have the equivalent of putref_Xxx(), the syntax ambiguity cannot occur in a C# program because of the previous two bullets. And the core reason that the C# team decided to put these restrictions in place, they greatly disliked ambiguity in the language.
So Tlbimp.exe is forced to deal with these restrictions, if the COM property accessors are not compatible then it must fall back to exposing them as plain methods instead of a property. With default names, they'll get the get_ and set_ prefixes. The latter one explains your question, they didn't pick put_ for an otherwise unclear reason.
Notable is that C# version 4 relaxed several of these restrictions, most of all to make interop with Office programs easier. Which was quite painful in earlier C# versions, to put it mildly. It extended the property syntax to lessen the pain, but only for COM interop. Very strongly recommended if you are still stuck on an old version of .NET, now is a good time to consider updating.
The properties themselves have to prefixes (put_ etc.), they have names, getter method, setter method, but no prefixes. Method table generated from type library receives prefixes to distinguish between getters and setters, hence the prefixes. Prefix string exactly depends on preference of the one who generates the names.
See also:
#pragma import attributes - raw_property_prefixes
By default, low-level propget, propput, and propputref methods are exposed by member functions named with prefixes of get_, put_, and putref_ respectively. These prefixes are compatible with the names used in the header files generated by MIDL.
VB in VS2008 under Windows 7 (64):
I need to change the value of a Property of a Component at some unpredictable time in DesignMode, and want the previously unknown new value to be embedded in the executable that results from VS compilation (as opposed to serializing it to some external file).
I have resorted to a text edit to swap the new value into the autogenerated Component initialization code in a prebuild event handler. This works fine, but it is a little hacky for my taste. Is there some way instead to force VS to refresh that text?
By luck, I found something that seems to work to force VS to autogenerate initialization code for the runtime instance of a Component, which is what I was after (I needed to have successful communication between designtime and runtime for Components -- easy for Controls, which use the latest designtime BackgroundImage bitmap at runtime (you need only to hide the Property value in the bitmap, which can be done entirely within the rules by using GetPixel and SetPixel). I considered various hacks, but I hit upon the following, which works and makes sense (though I might be completely FoS about the "why". If you know better, please educate me):
As I understand it, soon after a Component is dropped on a design surface in VS (and before it is rendered in the Component Tray), Visual Studio adds it to a collection of Components belonging to a Container. Adding it to the Container's collection is one step in a sequence of happenings that includes Visual Studio's autoregeneration of the Init procedure that will be used for the Component's root at runtime, and which includes values for the Public Properties of the Component. If you overload the Set Site procedure (the creation of ISite is an early step in that sequence) for your Component, and set a value for one of its Public Properties in the Overload, that value will show up in the autoregen text. This is almost what I wanted, except that it only worked when VS called Set Site, and I needed it to happen any time I chose.
Then I took a flyer, and in the UI that sets the Property value in question (at some unknowable time), I added code to remove the Component from the Container's collection and then re-add it, hoping that this might again set off a sequence of happenings that would lead to VS again autoregenerating the Init code, this time with the new value of the Property. It apparently did. Yay.
By deciding when to re-add a Component to the Container's Components collection, I am now able to force VS to write in the autogenerated Init text any value I assign to a Public Property of that Component, and hence embed the value in the executable when it is compiled.
This technique is vulnerable to changes in the (undocumented) way that Microsoft implements autogeneration, and so is arguably a hack. But even documented features are subject to change. Backward-compatibility is a nice idea, but sometimes it has to give way. And delivery is a requirement. It would be great to know that your code will still be good in any future version of VS, but that, sadly, can't happen, hack or no.
Of course, documented features are in general less subject to change than undocumented ones. But the logic of autogeneration after all the initial Property values are set is pretty compelling. That Microsoft uses the same sequence later on is not so inherently logical, but doing it a different way would cost Microsoft money for no apparent gain. And Microsoft and their ilk (are legally required to) make decisions based on the bottom line. So the status quo seems like a good bet.
I am currently designing the migration of my existing .NET / C# / WinForms project to a platform neutral solution and the most attractive alternative I have seen seems to be wxWidgets especially taking in consideration my familiarity with C++ and with MFC that appears to have a lot in common with it.
After going though the documentation and the sample code I need to clarify the following issue:
Is it a valid assumption that the way to develop a User Control (by C# terminology) in a wx environment is to derive a class from wxPanel , customize it and place it in a wxFrame?
If this is the case what is the wxFrame method to be used to add the wxPanel object to it ?
The only relative method I was able to find was wxWindow::AddChild but the documentation states that is mostly internal to wxWidgets and shouldn't be called by the user code.
To avoid confusion please note that my question is about a User Control and not a Custom Control (which is clearly addressed in the documentation)
I think you have to set the parent window in the constructor of your wxPanel-derived class and pass it to the inherited constructor (cf. wxPanel constructor)
A better solution, though, is to use sizers (see wx Sizers) for layouting.
And yes, imo you're right about wxPanelbeing (roughly) the equivalent of a C# UserControl.
How to use System.Dynamic.DynamicObject in VB.NET 10.0 ?
I can create class that inherits from DynamicObject, but cannot actually use it.
With VB, you have to turn Option Strict OFF on the class file that you want to consume the DynamicObject implementation. Doing this does mean that you lose the type safety that comes with Option Strict On. In addition, Dynamic opens you up to no longer relying on the compiler to check your method names for you.
I'm writing a series on creating a Dynamic CSV Enumerable type in VB at http://www.thinqlinq.com/Post.aspx/Title/LINQ-to-CSV-using-DynamicObject and can assure you that it does work in VB.
Jim Wooley
See this page
Subclasses can override the various
binder methods (GetMember, SetMember,
Call, etc.) to provide custom behavior
that will be invoked at runtime.
If a method is not overridden then the DynamicObject does not
directly support that behavior and the
call site will determine how the
binding should be performed.