Claus wrote:
The reason I would like to call the WinForms from Delphi is just to prepare
ourselfes for C#.
This way I "believe" (read: I hope) I can avoid coding the same dialog again
when the shift to C# is complete.
Then I can just keep using the same dialog...
I don't think you can do this easily. The pain would exceed the gain.
C# is a lot like Delphi when it comes to Windows Forms, so it's not
terribly difficult to re-do your GUI apps. After all, it still comes
down to the basic Windows controls that haven't changed much over the
last 5 years (or more). The VCL wrappers are a little different that
the C# wrappers, but Intellisense is a big help in VS.
The biggest difference on the GUI side is the databinding control issue
- Delphi makes it terribly easy to wire up visual controls to a live
datasource. This model is entirely different in C# because ADO.NET only
uses a disconnected model. You have to learn how to do databinding all
over again, and it's more complex than you might think. But it's also
more flexible in the long run. If you are a big user of Delphi
TDBGrids, you should spend a few days (or weeks) with the .NET grids
and ADO.NET to ensure that you understand them well before going too
far. I had to do a certain amount of re-work in the early days of my
conversion to C# becuase I didn't have a clear understanding of the
model going into it.
If you have a budget for it, and you have a lot of Delphi GUI apps to
port to C#, it might be a good idea to hire a consultant who's an
expert on Windows Forms. He can save you a lot of trouble and
heartache, and you may only need him for a couple months for training
purposes. With all the buzz about ASP.NET it can be difficult to find
an expert on Windows Forms, and it can be frustrating for you if you
don't have someone who can SHOW you how it's done in .NET.
Once you get your mind around the OOP classes it's actually very
flexible. And in 2.0 you can bind controls to data classes, and that's
pretty cool (something Delphi could never do).
Another option is to refactor your code so there's not much actual
processing in any of the GUI elements. If you move meaty processing to
middle tier COM DLLs, those can be re-used by C# pretty easily, without
a need to re-code them.
Our strategy is to port apps from Delphi to C# if a "significant"
amount of work is needed on a Delphi app. But if the Delphi app only
needs a minor bug fix, we just leave it in Delphi. Almost all new apps
are being done in C# unless it has to interop with Delphi components in
an advanced way.
Eric