I had to do this Export functionality that saves data in a file from the database after filtering by date. My first idea was "let's just export everything and only use an OpenFileDialog", but then the date filtering request came. I thought that changing the OpenFileDialog to add two date
time pickers would be an easy job, but, alas, it is close to impossible.

Good research came out of this, though:
FileDialogExtender - Customize a dialog by issuing API Messages to already open windows
Customize Your Open File Dialog - Customize a dialog by changing the registry
Advanced MessageBoxing with the C# MessageBoxIndirect Wrapper - a friendly C# wrapper class for the MessageBoxIndirect API that allows you to add a help button, custom icon, locale-aware buttons, and different modalities to a message box.
Control.WndProc Method - MSDN WndProc method

You use the InvokeMember function.

Quick example:
typeof(DataGrid).InvokeMember("RowAutoResize",BindingFlags.InvokeMethod|BindingFlags.NonPublic|BindingFlags.Instance,null,wDataGrid1,new object[] {1});

This is equivalent to wDataGrid1.RowAutoResize(1), which would not normally work because the method is private.

The syntax for InvokeMember is:
public object InvokeMember(
string name, // name of the method
BindingFlags invokeAttr, // Binding flags, see below
Binder binder, // Use null for the default binder. A Binder object that defines a set of properties and enables binding, which can involve selection of an overloaded method, coercion of argument types, and invocation of a member through reflection
object target, // object that owns the method you want to run
object[] args // argument array
);

Why does it work? Because access-modifier based security has no impact on Reflection
Ok, some of you might ask themselves How do I protect my code in libraries and other things I publish? Add this in front of the namespace declaration:

[assembly:ReflectionPermissionAttribute(SecurityAction.RequestRefuse,
Unrestricted=true)]

By setting the ReflectionPermission to RequestRefuse at assembly level, you could prevent all the accesses to private members and if someone tries to access it, it throws 'System.NullReferenceException'. In the above example, at fInfo.SetValue it throws NullReferenceException, because it is able to create fInfo object.


I think this is a greatly useful feature, especially when working with
Microsoft objects that have a lot of nifty procedures all marked with
private or internal or both :)

Trying to build a reusable object that is independent of the Windows or Web interface I've stumbled upon the issue of multiple threads trying to access and modify the same form. The ugly "Controls created on one thread cannot be parented to a control on a different thread." error occured and, no matter what I tried, it seemed it will never work. But finally I found out the solution.

First the issue:
doing something on the interface was starting a separate process that ran an external program. The interface has a progress bar that was updated during this. At the end of the process, an event was fired, and to that event I added a method that was supposed to clear the progress bar and put another UserControl on the form. The the error occured.

The problem was that the event was fired by the separate process that ran the external program. Trying to change something in the form that was created on another thread resulted in error.
The solution is that inside the method called by the event any references to methods that change the interface must be done through BeginInvoke:

private delegate void MethodDelegate(int i)

private void TestMethod(int i) {
// change interface here
}

private void OnEvent(object sender, EventArgs e) {
<interface_form_object>.BeginInvoke(new MethodDelegate(TestMethod),new
object[] {i});
// this replaces using TestMethod(i) which generates an error
}

Update on this:
Use the BackgroundWorker class in NET 2.0.

Using Visual Studio .NET 2003 to Redistribute the .NET Framework

It is as easy as downloading the Bootstrapper .MSI file and running it. Next
time you compile a Setup project it will include the dotnetfx.exe file and
the code required to install it on demand.

Another great tool is found here: RyanVM's MSFN Files Page
It is a switchless .NET installer. Just run it (as a custom action, for
example) and it will insure that you have .NET framework installed, no
questions asked.

One of the major marketing statements regarding ASP.NET was its capability to display content differently depending on browser. What actually happends, though, is that Internet Explorer is considered a HTML 4.0 compatible browser, while others are not. If you ever looked at a normal page with a few textboxes and a button on Firefox or Netscape, then you know what I mean.

Example:rendering for FireFox:

<table width="30%" border="2">
<tr>
<td align="Right">
<span >
Hi there...
</span>
</td>
</tr>
</table>


rendering for IE:

<table width="30%" border="2">
<tbody><tr>
<td style="FONT-SIZE: large; COLOR: red" align="right">
Hi there...
</td>
</tr>
</tbody></table>


In this case, if you want to , let's say, replace the innerHTML property of the td, then you lose the color red.Other such changes put the width/height parameters inside the style property or outside it.

Apparently, the difference in rendering comes from the HtmlTextWriter class. For "not compatible browsers" an overridden class is used for rendering: Html32TextWriter.

How to fix it.
The recomended fix for this is change the tag in machine.config. That would make your server compatible to each browser as you see fit. The downside of this, of course, is that your ASP.NET application will render differently for each hosting server making it undeployable.

My fix.
Just inherit the Page class and add this:
protected override void Render(HtmlTextWriter writer)
{
writer=new HtmlTextWriter(writer.InnerWriter);
base.Render (writer); // or your own rendering logic
}
and use this page class for all forms.

This will make all controls on the page render for HTML4.0 compatible browsers. In my personal opinion, we will never make sites that are designed to be seen with Internet Explorer 3.2 or Nescape 4 so this will work. Of course, that doesn't make the pages look the same on all browsers. One needs to check out all the details regarding browser compatibilty such as the way the Visual Studio IDE adds or removes DOM incompatible attributes, but it's a major step forwards.

Today I've learned that there is a way to add extra functionality to already defined classes through ExtenderProviders. While in Windows Forms things are relativeley easy, in Asp.NET visual studio 2003 is broken and needs special hacks in order to work.

This is the link for how to use ExtenderProviders in ASP.NET:
Extender provider components in ASP.NET: an IExtenderProvider implementation

Example:
in my latest WebControls library I have a component called NiftyExtender. You drag and drop it on an ASP.NET page and in Visual Studio all Controls have extra filter functions like Glow, Emboss, Engrave, Flip, etc. There is no need for cumbersome inheritance, just add the component to an already made site and it works just fine.

The same applies to Windows Forms, but there it works by default, without the need for a special class and weird hacks. A Windows Forms example is the ToolTip object that I always wondered what it does. Well, you drag and drop it on a form, then all windows form components have a tooltip in the Misc section.

I am thinking of a validator ExtenderProvider that would add the necessary validation functions to all controls in a page or form.

I've started this blog on July 07 2005, in the first days of my working within an Italian programming firm, as a dotNET programmer. It seems a very nice place to work in, with nice people, but I am cautious. So many times I've burned myself by assuming too much or hoping instead of planning. I intend to avoid that pattern from now on.