Localization in .NET using IFormatProvider

I was doing some localization stuff in .NET / Visual C++ Managed code .

I was loading a string from a file and formatting it the current UI format .

For example , a number displayed as 12.34 ( in US English ) shall be displayed as 12,34 when the locale is of Sweden – in fact comma is the default decimal separator for most European countries.

Though the String::Format( ) provides an overloaded method with IFormatProvider, somehow the conversion never happened .

So as a workaround, I parsed the string to a double with the current UI culture format and then converted it to a string .

Maybe this is not the best way, but as it worked for me , I am posting a sample below, so it can be helpful for others.

String^ myString= “12.34″;
double tempD = double::Parse(myString,Thread::CurrentThread->CurrentUICulture->NumberFormat );
Console::WriteLine( myString->Format(“{0}”,tempD);

TableLayout Panel – Problems and Solutions

If you have used TableLayoutPanel ( in .NET 2.0 ) you must have faced with excessive flickers when drawing several table layout panels.

Here I am posting some I had faced along with the solutions .

1) Creating multiple TableLayoutPanel objects

foreach(TableLayoutPanelobj in TableLayoutPanelList)
obj.SuspendLayout() ;

// code for your drawing goes here

foreach(TableLayoutPanelobj in TableLayoutPanelList)
obj.ResumeLayout() ;

ResumeLayout has a default parameter set to true, hence it also calls PerformLayout.

2) The above solution shall still have some flickers , here is the solution to remove that

Create a class which inherits from TableLayoutPanel, like the one below .

class MyTableLayout : public TableLayoutPanel

{

MyTableLayout( )

{

this.DoubleBuffered = true ;

}

}

Use the MyTableLayout object in your classes , there shall be no flicker .

Ovveriding Handle in C#

If one is making a composite control and needs to give the
inner control the user to work with , just ovveride the Handle
property.

// OuterControl.cs

public new IntPtr Handle {

get { return m_InnerControl.Handle; }

}

In C# Handle is derived from NativeWindow .

Ovveriding Handle is not recommended as this is a internal to Windows, so the user should be very confident while performing such operations.

Exposing Hidden Events

I found this small little note while surfing for my requirements … adding it to my blog so everybody can benefit.

I recently ran into a neat little nugget of functionality in C# with events. Normally in C# when we define events we stop at something like this:public event EventHandler MyEvent;
The thing is, you can explicitly implement the add and remove accessors if you throw some curly braces into the mix. Why does this matter? Imagine that you have a MainForm, and a usercontrol named ControlPanel. ControlPanel contains another usercontrol called hiddenControl that exposes an event that you want to handle in MainForm, but all MainForm has access to is ControlPanel…

public event EventHandler MyEvent
{
add{
this.hiddenControl.MyEvent += value;
}

remove{
this.hiddenControl.MyEvent -= value;
}
}

Now you can subscribe to the event in MainForm without making the usercontrol member public in ControlPanel.

Programming … Then and Now – Part 1

I started my career with TurboC on MS-DOS . The project was on real time systems along with graphics .

I had worked on my C graphics in my academics and hence I had a hang of it. However the most interesting part of my project was handing the keyboard and mouse ….. I was giving MS DOS a Windows look . …. in my leisure time I used to work on Window 3.1 .

Using interrupts was the first challenge … Ray Duncan’s “Advanced DOS” helped a lot in this matter. I was working on interrupts and graphics ; when one fine day, my superior told me I had to work on Visual C++ .

Though I was a bit worried about this new stuff “Visual C++” .. remember in my time Internet was a rare thing, and only the privileged one could get access to it at least in my organisation. Internet rates were so high that I could not personally afford a connection at that point of time.

Little did I realize that day, that learning curve would take to me great heights in later days.

Cutting it short, I mainly work on C++, STL, Windows SDK Programming, MFC,COM, ATL and presently on .NET. Looking forward to work on WTL as well.

Just a last word, Windows SDK Programming still rocks !!!!!!!!!!!