Hallo,
bedingt durch die kommende betriebsinterne Umstellung auf C# (schluchz)
soll geprüft werden, ob bestehende D7 Komponenten in ActiveX umgewandelt, und dann in C# eingebunden werden können.

Hat jemand damit bereits Erfahrung gesammelt?

Verträgt sich Delphi7 ActiveX mit C#?.
Wir dachten da an evtl. Problemem mit dem .NET Framework.
Die Komponenten beinhalten auch graphische Ausgaben.

Wären für jeden Tip dankbar.

Gruß

Erich Günthner

Wenn ihr ActiveX verwendet verliert ihr einige Vorteile von .NET.

Wieso wollt ihr denn umstellen? Welche Vorteile verspricht ihr euch denn? Ist es evtl. nicht sinnvoll gleich von 0 zu beginnen und andere über Jahre gewachsene Probleme des Systems zu beheben?

Bernhard Geyer hat folgendes geschrieben:

Wenn ihr ActiveX verwendet verliert ihr einige Vorteile von .NET.

Das ist eine Aussage, mit der ich schon etwas mehr anfangen kann.

Zitat:

Wieso wollt ihr denn umstellen?

Also mal erhlich, was mich nervt sind Antworten, die an der Frage vorbeigehen.
Ich habe nicht gefragt, ob man umstellen soll, sondern "Hat jemand damit bereits Erfahrung gesammelt?"
Bei uns sitzen genügend Leute herum, die wissen, warum wir umstellen (sollen).

Zitat:

Welche Vorteile verspricht ihr euch denn?

Gut, ich laß mich darauf ein.
Wir machen Mess- und Prüfsystem für die Industrie. (Bosch; Siemens; SEW usw);
Ein Großteil unserer Kunden verlangt, das die Software .NET fähig ist.
Mit C# haben wir beide Klientele bedient.
Delphi 2005 und co kommt nicht in Frage weil Buggy und die Zukunft nicht gesichert ist.
C# wird es geben, selbst wenn es Delphi nicht mehr gibt.
So, reicht die Info?

Zitat:

Ist es evtl. nicht sinnvoll gleich von 0 zu beginnen und andere über Jahre gewachsene Probleme des Systems zu beheben?

Nein, Code der im Laufe von über 10 Jahren entstanden ist auf C# zu portieren ist der blanke Wahnsinn.
Das wäre resourecenbindet und kostenspielig.
Aus betriebswirschaftlicher Sicht Selbsmord.
Probleme die vorhanden sind, sind nicht gewachsen, sonder wurden im Lauf der Zeit behoben!


Gruß

Erich

Erichgue hat folgendes geschrieben:

Also mal erhlich, was mich nervt sind Antworten, die an der Frage vorbeigehen. Ich habe nicht gefragt, ob man umstellen soll, sondern "Hat jemand damit bereits Erfahrung gesammelt?" Bei uns sitzen genügend Leute herum, die wissen, warum wir umstellen (sollen).

Ein bisschen freundlicher bitte. Bernhard wollte Dir sicherlich nur helfen und dies ist nun mal ein Diskussionsforum, indem man auch mal etwas mehr bekommt als nur die Antwort auf eine Frage. Die meisten Fragenden schätzen es, auch Input zu bekommen, der über die Frage hinaus geht.

Erichgue hat folgendes geschrieben:

Nein, Code der im Laufe von über 10 Jahren entstanden ist auf C# zu portieren ist der blanke Wahnsinn. Das wäre resourecenbindet und kostenspielig. Aus betriebswirschaftlicher Sicht Selbsmord.

Vielleicht ist Hydra etwas für Euch, es ist darauf zugeschnitten, nur einzelne Teile eines Projektes zu portieren.

Christian S. hat folgendes geschrieben:

Ein bisschen freundlicher bitte. Bernhard wollte Dir sicherlich nur helfen und dies ist nun mal ein Diskussionsforum, indem man auch mal etwas mehr bekommt als nur die Antwort auf eine Frage. Die meisten Fragenden schätzen es, auch Input zu bekommen, der über die Frage hinaus geht.

Sollte ich jemanden zu nahe getreten sein, möchte ich mich hiermit entschuldigen.
Es gibt aber auch Group-Teilenhmer, die meinen eine Entscheidung, die in einer Firma beschlossen wurde, beurteilen zu können.
Wenn die GL sagt es wird umgestellt, dann wird umgestellt. Meine Aufgabe ist es dies zu ermöglichen.
Diskussionen über das wenn und aber habe ich hier schon gehabt.
Sorry @Bernhard!

Zitat:

Vielleicht ist Hydra etwas für Euch, es ist darauf zugeschnitten, nur einzelne Teile eines Projektes zu portieren.

Danke für den Tip, kam auch schon von Bernhard.
Wir wollen keine Teile eines Projektes portieren.
Wir haben Treiber-DLL und dazu die passenden Komponenten für Messdatensysteme in Delphi geschrieben.
Hinzu kommen diverse Komponenten wie Chart, Dateneditor usw.
ActiveX hat sich deswegen gut angehört, weil es in C++ und VB usw auch geht.
Die Messdatensysteme sollen auch mit anderen Programmiersprachen verwendet werden können.

Gruß

Erich

Erichgue hat folgendes geschrieben:

Sollte ich jemanden zu nahe getreten sein, möchte ich mich hiermit entschuldigen.

Angenommen

Erichgue hat folgendes geschrieben:

Es gibt aber auch Group-Teilenhmer, die meinen eine Entscheidung, die in einer Firma beschlossen wurde, beurteilen zu können. Wenn die GL sagt es wird umgestellt, dann wird umgestellt. Meine Aufgabe ist es dies zu ermöglichen. Diskussionen über das wenn und aber habe ich hier schon gehabt. Sorry @Bernhard!

Es geht nur darum den Entscheidungsprozess zu verstehen. Ich war selbst bei einer Firma die schon 2001 (!) die Chance gehabt hat eine System komplett neu zu entwickeln. Nach einigen Tests waren die Entwickler (C/C++/Delphi) größten Teils dafür das in .NET zu erledigen. Nachdem unser neuer Entwicklungsleiter mit sein externen "Spezeln" jedoch beschlossen hat das in C/C++ mit MFC/ATL/Consolenanwendunge und Delphi zu machen habe ich (und nicht nur ich) die Firma gewechelt (weiß gar nicht ob mit der Nicht-.NET-Entscheidung das Projekt letztendlich gegen die Wand gefahren wurde, Entwicklungsleiter wurde auch bald entlassen). Und es gab in schon diverse "Umsteiger" in Foren die nur aufgrund von Marketingaussagen das durchgeführt ohne die Konsequenzen bewußt zu sein.

Erichgue hat folgendes geschrieben:

Wir wollen keine Teile eines Projektes portieren. Wir haben Treiber-DLL und dazu die passenden Komponenten für Messdatensysteme in Delphi geschrieben. Hinzu kommen diverse Komponenten wie Chart, Dateneditor usw. ActiveX hat sich deswegen gut angehört, weil es in C++ und VB usw auch geht. Die Messdatensysteme sollen auch mit anderen Programmiersprachen verwendet werden können.

Haben die DLL's ähnliche oder gleiche Schnittstellen? Falls ja wäre das Fassade oder Adapter-Muster mit einer abstraken Fabrik evtl. was für euch. Von den GUI-Komponenten wird ein C-Kompatible-Schnittstelle erstellt (oder Hydra genommen) und den Nachteilen von ActiveX (DLL-Hölle, Nötige Registrierung, ...) zu umgehen. Der Aufwand ist erstmals etwas höher, jedoch kann man damit auch (bei guter Auslegung) Schritt für Schritt die Alt-Komponenten durch reine .NET-Komponenten ersetzen bzw. neue Komponenten aufgrund der Kapslung gleich mit C# erstellen.

Bernhard Geyer hat folgendes geschrieben:

Angenommen

Puh, ging noch mal gut!

Zitat:

Es geht nur darum den Entscheidungsprozess zu verstehen. Ich war selbst bei einer Firma die schon 2001 (!) die Chance gehabt hat eine System komplett neu zu entwickeln. Nach einigen Tests waren die Entwickler (C/C++/Delphi) größten Teils dafür das in .NET zu erledigen. Nachdem unser neuer Entwicklungsleiter mit sein externen "Spezeln" jedoch beschlossen hat das in C/C++ mit MFC/ATL/Consolenanwendunge und Delphi zu machen habe ich (und nicht nur ich) die Firma gewechelt (weiß gar nicht ob mit der Nicht-.NET-Entscheidung das Projekt letztendlich gegen die Wand gefahren wurde, Entwicklungsleiter wurde auch bald entlassen). Und es gab in schon diverse "Umsteiger" in Foren die nur aufgrund von Marketingaussagen das durchgeführt ohne die Konsequenzen bewußt zu sein.

Ganz klar.
Nur wir müssen! Unserer Kunden wollen Software haben, die auf .NET basiert.
Ob das bei unserern Kunden immer reiflich überlegt ist bezweifle ich.
Da kommen neue Abteilungsleiter, frisch von irgendwoher,
und meine das diese oder jene Technologie das allerbeste für die Firma sei.
Nur was willste machen. Als Lieferant mußte mitgehen.

Ich wäre lieber bei Delphi geblieben. (gibts ja auch für .NET)
Alleine wenn man berücksichtig, wieviel Zeit und Resourcen durch die Umstellung auf C# verbraucht werden.
Auf C# hätte man immer noch gekonnt, sollte Delphi .NET nicht geeignet sein.

Zitat:

Haben die DLL's ähnliche oder gleiche Schnittstellen?

Ja, haben sie.

Zitat:

Falls ja wäre das Fassade oder Adapter-Muster mit einer abstraken Fabrik evtl. was für euch. Von den GUI-Komponenten wird ein C-Kompatible-Schnittstelle erstellt (oder Hydra genommen) und den Nachteilen von ActiveX (DLL-Hölle, Nötige Registrierung, ...) zu umgehen. Der Aufwand ist erstmals etwas höher, jedoch kann man damit auch (bei guter Auslegung) Schritt für Schritt die Alt-Komponenten durch reine .NET-Komponenten ersetzen bzw. neue Komponenten aufgrund der Kapslung gleich mit C# erstellen.

Das hört sich gut an.
Werde dein posting mal an unserern "Softwarebeauftragten" weiterleiten, wenns recht ist?
Also du meinst, das ActiveX nicht das beste ist?
Daraus schließe ich auch, das ActiveX in C# nicht geht?

Danke schon mal für die Infos

Gruß

Erich

COM-Komponenten(aka ActiveX) kann man natürlich in allen DOTNET Sprachen benutzen genauso wie man als COM-Komponenten veröffentlichte DOTNET Assemblies in nativen Umgebungen aufrufen kann. Ihr müßt nur darauf achten welche Datentypen über die COM-Schnittstellen ausgetauscht werden.

Die Frage ist weiterhin warum die Kunden NET verlangen (bei selben Features wie eine native Anwendung).
Wenn es Ihnen insbesondere um die enger geschnürte Security in NET geht ( ich hoffe es geht in deinem Fall mal nicht nur um den Hype) dann würdet ihr diese natürlich teilweise ausgehebeln wenn ihr nativen Code einstreut.

Ralf Jansen hat folgendes geschrieben:

COM-Komponenten(aka ActiveX) kann man natürlich in allen DOTNET Sprachen benutzen genauso wie man als COM-Komponenten veröffentlichte DOTNET Assemblies in nativen Umgebungen aufrufen kann. Ihr müßt nur darauf achten welche Datentypen über die COM-Schnittstellen ausgetauscht werden.

Ah, das wars! Danke!

Zitat:

Die Frage ist weiterhin warum die Kunden NET verlangen (bei selben Features wie eine native Anwendung). Wenn es Ihnen insbesondere um die enger geschnürte Security in NET geht ( ich hoffe es geht in deinem Fall mal nicht nur um den Hype) dann würdet ihr diese natürlich teilweise ausgehebeln wenn ihr nativen Code einstreut.

Leider wieß ich es nicht, warum die(!) Kunden .NET wollen.

Ich werde diese Aspekte noch mal mit meiner GL durchgehen.

Melde mich Mo. wieder.

Erstmals vielen Dank!

Gruß

Erich Günthner

Erichgue hat folgendes geschrieben:

Würde mich jemand nehmen, würde ich auch gehen.

Sollte aktuell kein Problem sein. Oder willst du nur bei Delphi bleiben?

Erichgue hat folgendes geschrieben:

Werde dein posting mal an unserern "Softwarebeauftragten" weiterleiten, wenns recht ist?

Aber am besten ohne obige Aussage

Erichgue hat folgendes geschrieben:

Also du meinst, das ActiveX nicht das beste ist? Daraus schließe ich auch, das ActiveX in C# nicht geht?

Wurde schon beantwortet.

Erichgue hat folgendes geschrieben:

Also du meinst, das ActiveX nicht das beste ist? Daraus schließe ich auch, das ActiveX in C# nicht geht?

Wurde schon beantwortet.[/quote]

Wenn ich das mal zusammenfasse, wäre es besser man nimmt Delphi .NET und gut is.

Gruß

Erich Günthner

Vorab: Ich habe noch nicht mit Delphi.net gearbeitet, sondern mir nur ein kleines Tutorial durchgelesen.
Ich würde dir von Delphi.net abraten, weil es noch auf .net1.1 demnächst vllt auf .net2.0 aufstetzt-> Ist also veraltet Und die VCL.net ist auch nicht so das Wahre.
Wenn du(ihr) mit .net arbeiten müsst dann würde ich euch C# empfehlen.

Leuchtturm hat folgendes geschrieben:

Ich würde dir von Delphi.net abraten, weil es noch auf .net1.1 demnächst vllt auf .net2.0 aufstetzt-> Ist also veraltet

Delphi war immer veraltet (D1 kurz vor Einführung Win95 am Markt, COM+-Support erst 1-2 Jahre verspätet). Letztendlich muß jede Nicht-MS-IDE immer hinterher sein.

Leuchtturm hat folgendes geschrieben:

Und die VCL.net ist auch nicht so das Wahre.

Aktuell ja. Aber da mit Avalon/WPF eh alle Karten neu gemischt werden (und alle WinForms-Entwickler um nicht veraltet zu sein alles GUI-Technische neu entwickeln müssen) will ich mal abwarten ob evtl. ein überzeugende VCL.WPF folgt.

Leuchtturm hat folgendes geschrieben:

Wenn du(ihr) mit .net arbeiten müsst dann würde ich euch C# empfehlen.

Chrome ist auch eine reine .NET-IDE mit Sprachbasis Pascal. Jedoch sollte man unter .NET auf jedenfall ausreichende C#-Kenntnisse haben.