Developer Forum

This could be a difficult one, so please bear with me.

I've an assembly containing Delphi 2006.NET forms.

A C# app, via reflection opens these forms . This works fine - I've a C#
app, opening Delphi 2006.NET forms.

Some of these forms are MDI Child forms. Exceptions are thrown - "Cannot
create form - No MDI Forms are currently active" when the C# app tries
to open one of these.

The C# app does have the property MDI Container = True. I realise it is
the Form that I'm trying to create throwing the exception, rather than
the C# application - the Delphi Form expects the opening form to be of
form style fsMDIForm.

Does anyone know of a way around this? i.e. I want the MDI children
(delphi forms) to be happy about opening in a C# application whose main
form is an MDI Container.

I really, really, really, really need to be able to do this. Hope some
genius is out there....

Thanks

M


*** Sent via Developersdex http://www.yqcomputer.com/ ***

Mucker,

I'm guessing that whatever the Delphi form is, it derives from the Form
class in the System.Windows.Forms namespace. With that assumption in mind,
are you setting the form's MdiParent property to the MDI container form in
your app?


--
- Nicholas Paldino [.NET/C# MVP]
- XXXX@XXXXX.COM

Hi Nicholas

Form
class in the System.Windows.Forms namespace

<< No it doesn't, it's derived from System.ComponentModel.Component.
This is why it's difficult to say the least. In fact it's actually
impossible.

Borland Developer Studio BDS offers two paths into the wonderful world
of .NET - The Delphi VCL.NET route, or via normal WINFORMS.

The benefit of VCL.NET is that you can usually take a Delphi Win32
project and recompile it with the .NET personality and hey, presto you
have a .NET application. The alternative - going the WINFORMS route
means that you have to start from scratch. Not an option for us when our
application consists of several thousand forms and units.

The disadvantage of VCL.NET is that it is not 100% managed code and only
supports VCL.NET components - not .NET components. This is a problem for
us since our main application makes heavy use of a component for which
there is no VCL.NET version (but there is a .NET one).

The solution is to write the main application in C# and have the delphi
screens stored in .NET assemblies. The C# app (MDI interface) then loads
the screens via reflection. This is when I encountered problems loading
MDI children from external assemblies. This isn't a problem for delphi
Win32 since the forms can be stored in its version of DLLs - BPLS - but
obviously it's a major issue for .NET. Looking at the source code for
the Delphi.NET runtime, it's evident that there is absolutely no way
that the MDI functionality will work when running in an external
application.

The only solution I could think of is, when loading an MDI Child form
from an assembly, to create a C# MDI child form and then use SetParent
to set this form as the parent of the delphi form and then hide all
visual borders/captions etc so that the delphi form fills the client
area. The delphi form is quite happy with this (obviously the delphi
form has to have the MDI child style removed first), but requires a lot
of faffing around taking into account the form is now essentially hosted
in another form - one written in VCL.NET, the other plain .NET. The two
will have to communicate somehow, but this at least is progress and
tomorrow's problem.

Anyway, at least I've learnt something today...


M








*** Sent via Developersdex http://www.yqcomputer.com/ ***