Nish Nishant's technology blog
Nish’s thoughts on cloud architecture and writing scalable services, among other things
If you are on Windows 8.1, and you are attempting to run an ASP.NET Core 3.1 Web Application, you’ll have run into the dreaded ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY error message. Here’s the workaround. Add this to your appsettings.Development.json file.
"Kestrel": {
"EndpointDefaults": {
"Protocols": "Http1"
}
}
This is based on a recent thread on the MSDN forums. Someone had code that looked like this:
public class CustomObject<T>
{
Object _obj;
public Object Value
{
get
{
return _obj;
}
}
public static explicit operator CustomObject<T>(T obj)
{
return new CustomObject<T>() { _obj = obj };
}
}
class App
{
static void Main()
{
var tmp1 = (CustomObject<Object>)true; // from bool
var tmp2 = (CustomObject<Object>)12; // from int
// The following code throws a System.InvalidCastException
// Unable to cast object of type 'System.Object' to
// type 'CustomObject`1[System.Object]'
var tmp3 = (CustomObject<Object>)new Object(); // from object
}
}
The code compiles fine but the third conversion results in an InvalidCastException. And he was quite puzzled by it.
The answer is simple if you think about it, and the exception that’s thrown is a dead giveaway. When you have an object there, the compiler sees that as a downcast (casting from base to a more derived type). The reason is that CusObject<T> is derived from Object (implicitly) and so when the type being converted is Object, it will not call the explicit (or implicit) conversion operator, instead it will generate a castclass IL instruction which will obviously fail.
To make that more clear, forget the “generics” and take this example:
class Base
{
}
class Derived : Base
{
public static explicit operator Derived(Base b)
{
return new Derived();
}
}
That will not compile and you’ll see this:
Error 1 ‘Derived.explicit operator Derived(Base)’: user-defined conversions to or from a base class are not allowed
Of course when you use a generic parameter, the compiler cannot anticipate that you’d try doing this, and so it will let you declare the operator. And when you later have an ambiguous situation where you cast from base to derived, it will simply ignore the explicit operator and instead do a downcast.
In the MSDN thread, Louis.fr pointed out the appropriate section in the language spec that talks about this. For those interested it’s 10.10.3. Quoting below:
However, it is possible to declare operators on generic types that, for particular type arguments, specify conversions that already exist as pre-defined conversions.
In cases where a pre-defined conversion exists between two types, any user-defined conversions between those types are ignored.
There was a recent thread in the MSDN forums where someone was concerned about the behavior of Type.GetElementType. His example was similar to the following:
char [][,][] arr = new char[2][,][]; Console.WriteLine(arr.GetType().GetElementType());
The output he got was:
System.Char[][,]
This puzzled him no end because the element type is clearly char[,][]. He was wondering if this was a bug in GetElementType or even if it was a bug in the C# compiler (incorrectly parsing the array declaration).
Well there is no mystery here. Array types (or rather the runtime type for an array) have a ToString implementation that displays the array using a display format closely resembling the IL syntax for arrays, and not the C# syntax. This is very easily verified with the following code:
Console.WriteLine(typeof(char[][,][,,]));
The output here is:
System.Char[,,][,][]
This is a good idea since the C# array syntax is not universal among CLI languages anyway. Both VB.NET and C++/CLI use array syntax that’s different from this.
This question or a similar variation pops up in the forums once in a while. The core problem is that while null terminated char arrays can be marshaled to a System.String fairly easily, with other unmanaged arrays the marshaller cannot know for sure what size of array to create. The solution is to marshal the argument as an IntPtr and then in the calling code, the user can manually create a managed array and copy the data into it. This assumes that the unmanaged API has a size parameter (which it invariably does) that indicates the length of the unmanaged array. Here’s some example code that shows how this is done:
typedef long (CALLBACK * READDATA)(unsigned char * data, int length);
extern "C" __declspec(dllexport) void __stdcall SomeFunc(READDATA rd)
{
unsigned char data[5] = {'a', 'b', 'c', 'd', 'e'};
rd(data, 5);
}
And here’s the calling code:
delegate int ReadDataDelegate(IntPtr data, int len);
[DllImport("SimpleLib.dll")]
static extern void SomeFunc(ReadDataDelegate d);
private static void CallNativeWithCallback()
{
ReadDataDelegate newCB = new ReadDataDelegate((data, len) =>
{
byte[] array = new byte[len];
Marshal.Copy(data, array, 0, len);
foreach (byte b in array)
{
Console.WriteLine((char)b);
}
Console.WriteLine();
return 0;
});
SomeFunc(newCB);
}
This article discusses an attached behavior that lets you handle the View Window’s Closed and Closing events via commands in the View-Model. It was inspired by Reed Copsey, Jr.’s Blend behavior which is up on the Expression Code Gallery. Reed’s behavior uses a neat technique that lets the View-Model handle the Closing/Closed events of the View in an MVVM friendly manner. Since his code was tied to the Expression DLLs I thought it would be a good idea to write a plain WPF version. While similar in concept to the Blend behavior, I’ve slightly deviated from how the concept is implemented and also in how it’s used. So this is not a direct 1-to-1 replacement though you should be able to get things working pretty much the same without too much effort.
Article Link
The Exif Compare Utility is a WinDiff equivalent for image files that compares the Exif meta-data and displays the differences and similarities. The application is written using WPF and MVVM, and also makes use of my ExifReader library. In the article I briefly explain how to use the application and also discuss some of the interesting code implementation details.
Article Link:
The majority of MFC apps have always had an About… menu entry in the main window’s system menu, and this was primarily because the App Wizard generated code for that by default. I wanted to do something similar in a WPF application I’ve been working on, and I wanted to do it in an MVVM friendly manner. In this recent article published on The Code Project, I explain a neat way of doing it so that you can easily add menu items and attach command handlers to them while retaining the basic MVVM paradigm. The code supports command parameters as well as an UI enabling/disabling mechanism. The basic idea is to make it so that it should be very easy to add system menu-items and then bind commands to them without having to make major changes to code.
I was rather cynical about all the buzz around MVVM, but now that I’ve begun using it I can see why so many people are fascinated by the concept.
Update – Apr 9, 2010
You do not need to do all this – instead you just need to set UpdateSourceTrigger on the Binding to PropertyChanged. I’ve made an updated blog entry on this here : Correction for the instant binding attached behavior for WPF TextBoxes
Original entry follows for posterity
The default behavior for a TextBox is to invoke data binding when the TextBox loses focus. Normally this is fine since people do have to hit an OK button somewhere, but there are times when you’d prefer that databinding occurs as you type into the TextBox. I wrote an attached property for the TextBox which invokes data binding as you type into it, and not when the text box goes out of focus. Here’s how you would use it.
<TextBox Height="23"
nsmvvm:TextInstantBindingBehavior.EnableInstantBinding="True"
Text="{Binding EnteredName}" HorizontalAlignment="Left"
Margin="144,64,0,0" Name="textBoxName"
VerticalAlignment="Top" Width="152" />
Here’s the code for the attached property.
public class TextInstantBindingBehavior
{
public static DependencyProperty EnableInstantBindingProperty =
DependencyProperty.RegisterAttached(
"EnableInstantBinding",
typeof(bool), typeof(TextInstantBindingBehavior),
new FrameworkPropertyMetadata(
new PropertyChangedCallback(EnableInstantBindingChanged)));
public static void SetEnableInstantBinding(TextBox target, bool value)
{
target.SetValue(
TextInstantBindingBehavior.EnableInstantBindingProperty, value);
}
public static bool GetEnableInstantBinding(TextBox target)
{
return (bool)target.GetValue(EnableInstantBindingProperty);
}
private static void EnableInstantBindingChanged(
DependencyObject target, DependencyPropertyChangedEventArgs e)
{
TextBox element = target as TextBox;
if (element != null)
{
if (e.NewValue != null && (bool)e.NewValue)
{
element.TextChanged += Element_TextChanged;
}
else
{
element.TextChanged -= Element_TextChanged;
}
}
}
static void Element_TextChanged(object sender, TextChangedEventArgs e)
{
TextBox textBox = (TextBox)sender;
if (GetEnableInstantBinding(textBox))
{
BindingExpression bindingExpression =
textBox.GetBindingExpression(TextBox.TextProperty);
if (bindingExpression != null)
{
bindingExpression.UpdateSource();
}
}
}
}
I needed an Exif reader class for a C# application I was working on, and though I found quite a few implementations available including a few on The Code Project, none of them fully suited my requirements. So I wrote my own class. The article describes the use and implementation of this class, and also includes a couple of demo projects, one using Windows Forms and the PropertyGrid, and another using WPF and the growingly popular MVVM architecture. The ExifReader project is 100% Style Cop compliant except for the IDE generated AssemblyInfo.cs and the PropertyTagId.cs file which I custom created from multiple sources including some GDI+ header files, as well as trial and error. I didn’t think it would be a great idea to try and apply Style Cop guidelines to either of those files. The class does not directly access Exif metadata from image files, and instead delegates that functionality to the Image class from System.Drawing. The public interface does not expose any System.Drawing types and so this library can be used from WPF without needing to reference System.Drawing.
This class tries to cover as many of the documented and undocumented Exif tags as I could test on, but if any of you encounter images that have Exif tags that are not recognized by my class, I request you to kindly contact me and send me the images. Once I have the images, I can attempt to support those tags too. Right now, if it encounters an undocumented tag it will still extract the tag value, but you won’t see any descriptive tag-name or any custom parsing/formatting that may be required.
All the code, including the demos, have been written and tested on VS 2010 RC and .NET 4.0. While I have not intentionally used any .NET 4.0/C# 4.0 only feature like say the dynamic keyword, I may have inadvertently written code that may not compile in .NET 3.5. But I don’t expect any of those to be hard to fix or change for most programmers, but if you run into trouble and can’t figure out what to do, please ping me via the article forum and I’ll help fix it. I suspect the most common compatibility issues would be with regard to IEnumerable<T> cast requirements in .NET 3.5, since it became a variant interface only in .NET 4.0.
Recently I was working on an MVVM demo for an article where I wanted live filtering based on the contents of a text box. The problem with this is that the TextBox does not have a Command property, and thus I’d need to use code-behind to proxy its text changed event to the ViewModel. And I did not want to do that. This was purely whimsical behavior on my part since MVVM does not mandate this at all, though a lot of people do recommend it. Apparently, you can get around this by referencing an Expression Blend DLL, which has support for interaction triggers that you can forward to a command object, thereby avoiding any code-behind. I didn’t want to reference an Expression Blend DLL, not for a simple demo app anyway and so I was forced to work around it by adding an attached behavior to the TextBox that could take a command object. This was a bit of an over-kill of course, and in a real world app I’d simply do it in code-behind. Most likely something like :
ViewModel viewModel = this.DataContext as ViewModel;
. . .
private void TextChanged(. . .)
{
viewModel.SomeCommand(. . .) ;
}
That’d be in my view’s code-behind, and while some purists may not be too happy, I think it’s definitely simpler than referencing Expression Blend! Here’s what a typical Xaml code snippet using this behavior would be like:
<TextBox x:Name="searchTextBox" Width="165"
HorizontalAlignment="Left" Margin="3,0,0,0"
Text="{Binding SearchText}"
local:TextChangedBehavior.TextChanged="{Binding FilterCommand}" />
Instead of handling the TextChanged event, I handle it via the attached behavior and route it to the FilterCommand command object in the ViewModel. Here’s the code for the attached behavior:
internal class TextChangedBehavior
{
public static DependencyProperty TextChangedCommandProperty
= DependencyProperty.RegisterAttached(
"TextChanged",
typeof(ICommand),
typeof(TextChangedBehavior),
new FrameworkPropertyMetadata(
null,
new PropertyChangedCallback(
TextChangedBehavior.TextChangedChanged)));
public static void SetTextChanged(TextBox target, ICommand value)
{
target.SetValue(TextChangedBehavior.TextChangedCommandProperty,
value);
}
public static ICommand GetTextChanged(TextBox target)
{
return (ICommand)target.GetValue(TextChangedCommandProperty);
}
private static void TextChangedChanged(
DependencyObject target, DependencyPropertyChangedEventArgs e)
{
TextBox element = target as TextBox;
if (element != null)
{
if (e.NewValue != null)
{
element.TextChanged += Element_TextChanged;
}
else
{
element.TextChanged -= Element_TextChanged;
}
}
}
static void Element_TextChanged(object sender, TextChangedEventArgs e)
{
TextBox textBox = (TextBox)sender;
BindingExpression bindingExpression = textBox.GetBindingExpression(
TextBox.TextProperty);
if (bindingExpression != null)
{
bindingExpression.UpdateSource();
}
ICommand command = GetTextChanged(textBox);
if (command.CanExecute(null))
{
command.Execute(null);
}
}
}
Nothing complicated there, just a basic attached behavior implementation.
