usercontrol c# / c++

smegghead used Ask the Experts™

I'm developing a new system using .net technology.

The front end application will use a self-authored usercontrol which I'd previously written using C++.

My question is.. is it worth re-writing this control in C# or just leave it as c++ ??

Is there a speed advantage / disadvantage ??

Are there any other issues to be taken into consideration ??
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Depends what kind of control you have written. If there is going to be lot of testing involved in making sure that new controls is working fine, then I would say that leave that control implementation as it is. start porting other parts of the application. Later you can migrate this control over.

But there is one drawback with this. If you are going to use this control in .Net application, then there is going to be overhead involved with Interop. If this control will be widely used in .Net apps, then it may be worth the effort to have .Net implementation.

Basically it all comes down to what kind of control and where it is going to be used.


Isn't C# an overhead in itself though ??

I do like C#, but the programs I've written so far don't seem to compare with the speed of C++.

Where does the overhead with interop actually occurr ?? is it with every property / method call or is it just the initial setting up ??


I've now re-written this control in C#..

It's amazing how much shorter the program is.. It seems to function faily smoothly too.
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.


In the C++ control I used BitBlt throughout the program to draw the window.

There are scrollbars on the control and the whole control has to be re-drawn when the scrollbar is moved.

Before I added the code to draw the borders (which also scroll) it all seemed quite smooth. But now that I have 9 calls to Graphics.DrawImage rather than BitBlt it is running like a slug.

Surely there must be a quicker way of copying a bitmap ???

I will up the points if someone can help with this.


This is a little bit better now, as I found some ways of speeding up the .drawimage process.

The background image I was using was created just using the default resolution, but when I changed it to be of the same resolution/colour depth as the screen, the copying got much faster.

I'd still say that it's way short of the old bitblt method. However, I've read some documentation somewhere that says .drawimage uses the bitblt behind the scenes (which I find hard to believe)


I kinda wanted a bit of an open discussion about this... but it never happened.

Oh well... have the points anyway

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial