Sprachen mischen? C++, ObjectPascal

[HHick123]

Sagt mal, die neueren IDEs können doch auch neben ObjectPascal etwas mit C# und C++ "anfangen", oder?

Kann man eigentlich Sprachen mischen, in dem Sinne, dass man eine Unit in C++ kompiliert und eine andere in ObjectPascal und dann die dcu-Dateien linkt?

Oder stelle ich mir das zu einfach vor?

Viele Grüße,
Helmut

[mkinzler]

Ja, die VCL ist ja auch in Delphi gschrieben und wird in c++ verwendet.

[Bernhard Geyer]

Zitat:

Zitat von HHick123

Sagt mal, die neueren IDEs können doch auch neben ObjectPascal etwas mit C# und C++ "anfangen", oder?

C# ist ab Delphi 2007 schon wieder gestorben.

Zitat:

Zitat von HHick123

Kann man eigentlich Sprachen mischen, in dem Sinne, dass man eine Unit in C++ kompiliert und eine andere in ObjectPascal und dann die dcu-Dateien linkt?

Unter C++- mit VCL können Pascal-Sourcen verwendet werden, unter Delphi jedoch nur Obj-Files von C (so wie die oft verwendete ZLib).

[mkinzler]

[ot]

Zitat:

C# ist ab Delphi 2007 schon wieder gestorben.

Und .Net hält bei RadStudio 2009 erst einmal Winterschlaf
[/ot]

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

[ot]

Zitat:

C# ist ab Delphi 2007 schon wieder gestorben.

Und .Net hält bei RadStudio 2009 erst einmal Winterschlaf
[/ot]

.NET ist bei RAD 2007 auch erst als letztes gekommen.
Aber wer braucht schon .NET in Delphi. Soviel übrigebliebene sinds es nicht mehr die das Probiert haben. :roll:

[Phoenix]

Och Leute... das .NET Thema wurde doch schon ausgiebig an zigtausend anderen Stellen diskutiert. Hier bitte beim Mischen von Sprachen in der nativen Welt bleiben.

[Hobby-Programmierer]

Hallo ...,

Zitat:

Zitat von Bernhard Geyer

Unter C++- mit VCL können Pascal-Sourcen verwendet werden, unter Delphi jedoch nur Obj-Files von C (so wie die oft verwendete ZLib).

lassen sich auch komplette Delphiprojekte bearbeiten?

LG Mario

[mschaefer]

In CBuilder kann man Delphi-Komponenten einbauen und in C++ die Projekte halten.
Delphi-Projekte kann man damit aber meines Wissens nicht bearbeiten.

Grüße // Martin

[HHick123]

Zitat:

Zitat von Bernhard Geyer

unter Delphi jedoch nur Obj-Files von C (so wie die oft verwendete ZLib).

Wie schaut's mit C++ aus? Auf was ich hinaus will: Hieße dass, dass man unter Umständen die OWLNext-Bibiliothek mit ObjectPascal verwenden könnte?

[grenzgaenger]

nein, das kannst du nicht, weil die OWL auf libaries verweisst, welche in delphi nicht mehr vorhanden sind. ansonsten ist das object format {$Link blabla} standardisiert und seit ewigen zeiten unverändert. beim zusammenbauen will aber der linker die referenzen auflösen und da wird es krachen.

[Bernhard Geyer]

Zitat:

Zitat von HHick123

Zitat:

Zitat von Bernhard Geyer

unter Delphi jedoch nur Obj-Files von C (so wie die oft verwendete ZLib).

Wie schaut's mit C++ aus? Auf was ich hinaus will: Hieße dass, dass man unter Umständen die OWLNext-Bibiliothek mit ObjectPascal verwenden könnte?

Wieso willst du dies Bibliothek verwenden? Was bietet sie was du nicht direkt direkt als Delphi-Komponente zur verfügung hast?

[HHick123]

Es geht noch immer um dieses Projekt:
http://www.delphipraxis.net/internal...018&highlight=

Ich hab' eine Abschätzung gemacht, wie lange es dauern würde von OWL auf VCL umzusteigen.
Wobei ich mir wirklich intensive Gedanken gemacht hab', wie man das teilautomatisiert machen könnte.

Aber trotzdem befürchte ich ganz stark, dass es den Kunden zu viel sein wird, und ich den Job nicht bekommen werde... Und verhungern muss... Buhuuu... :( Na gut, ganz so schlimm wird's nicht werden.

Über den Weg, von OWL auf OWLNext umzusteigen bin ich mir noch nicht so ganz klar. Bislang hab' ich angenommen, dass ich dann von Pascal auf C++ umsteigen müßte (ca. 100.000 lines of code), und ich glaube nicht, dass die automatischen Converter das hinkriegen, aber wenn Pascal eine Option wäre, dann würd' ich den Weg ev. noch mal durchdenken...

[mkinzler]

Die VCL ist doch eine Weiterentwicklung von ObjectWindows

[mschaefer]

Also mein Weg bei sowas wäre:

1. Funktionalität sondieren: Was macht das Ding eigentlich.
2. Units hersaussuchen die keine Formulare enthalten. Die können eventuell ins neue Projekt.
3. Schauen welche Fenster zusammengefasst werden können. Dosminibildschirme auf Windowsdesktopgröße umstellen.
4. Mit MDI/Multiformularstruktur das Ding neu aufbauen.

Bei Dos-Anwendungen von den Codezeilen auf die Windowsanwendung zu schliessen bringt nichts. Da geht viel für die Verwaltung und Navigation in den Minibildschirmen drauf. Hier läßt sich mit der VCL mit Zusatzkomponenten einfach bessr arbeiten.

So jetzt gehts an meinem Seelenverkäuferprojekt weiter

Grüße // Martin

[HHick123]

Zitat:

Zitat von mschaefer

Bei Dos-Anwendungen von den Codezeilen auf die Windowsanwendung zu schliessen bringt nichts. Da geht viel für die Verwaltung und Navigation in den Minibildschirmen drauf.

Eine Anwendung für 16-bit-Windows ist es halt. Sieht eigentlich recht modern aus. Noch läuft das Zeug ja...

Zitat:

Zitat von mkinzler

Die VCL ist doch eine Weiterentwicklung von ObjectWindows

Ja, mag sein, ich hab' mir auch schon einen weitgehend automatischen Weg überlegt, aber woran es momentan hauptsächlich scheitert, ist der Unterschied,
dass bei der VCL die Steuerelemente alle Member von z.B. TForm1 sind, was den Vorteil hat, dass wir direkt auf die Daten der Steuerelemente (z.B. den Text aus einem Edit)
zugreifen können. Alá Form1.Edit1.Text ...

Wie das bei OWL funktioniert, hab' ich noch nicht so ganz durchschaut, da gibt es anscheinend für das gesamte Fenster z.B. TDialog1 einen Transport-Buffer-Speicherbereich,
der sich aus den Speicherbereichen der einzelnen Steuerelemente zusammensetzt. Dieser Transport-Buffer wird dann als Ganzes an das Fenster gesendet oder vom Fenster empfangen.

Wenn mir das jemand erhellen könnte, wie das bei OWL funktioniert
(vielleicht ist das einfach ein NonVCL-Thema im Umgang mit Dialogen),
wäre ich auch sehr dankbar!

Viele grüße,
Helmut

[grenzgaenger]

Zitat:

Zitat von HHick123

Es geht noch immer um dieses Projekt:
http://www.delphipraxis.net/internal...018&highlight=

Ich hab' eine Abschätzung gemacht, wie lange es dauern würde von OWL auf VCL umzusteigen.
Wobei ich mir wirklich intensive Gedanken gemacht hab', wie man das teilautomatisiert machen könnte.

Aber trotzdem befürchte ich ganz stark, dass es den Kunden zu viel sein wird, und ich den Job nicht bekommen werde... Und verhungern muss... Buhuuu... :( Na gut, ganz so schlimm wird's nicht werden.

Über den Weg, von OWL auf OWLNext umzusteigen bin ich mir noch nicht so ganz klar. Bislang hab' ich angenommen, dass ich dann von Pascal auf C++ umsteigen müßte (ca. 100.000 lines of code), und ich glaube nicht, dass die automatischen Converter das hinkriegen, aber wenn Pascal eine Option wäre, dann würd' ich den Weg ev. noch mal durchdenken...

du willts doch nicht im ernst versuchen, eine veraltete technik ohne datenbankanbindung nach delphi zu portieren?

mein tipp, nimm das DB schema, dass passt auch heut noch, bau darauf deine datenbankanbindung state-of-art und darauf deine paar forms. die zeit wo du damit verbracht hast, dir zu überlegen, wie du das zeugs konvertieren kannst ... in dieser hättest bereits die halbe app portiert.

und keine angst, in 1, 2 jahren muss dein kunde sich entscheiden, das progy sterben zu lassen oder es zu portieren... da läuft dann langsam die 16 bit unterstützung von m$ aus ... :-) .

[HHick123]

Zitat:

du willts doch nicht im ernst versuchen, eine veraltete technik ohne datenbankanbindung nach delphi zu portieren?
mein tipp, nimm das DB schema, dass passt auch heut noch, bau darauf deine datenbankanbindung state-of-art und darauf deine paar forms.

:-D Klingt gut...

Zitat:

die zeit wo du damit verbracht hast, dir zu überlegen, wie du das zeugs konvertieren kannst ... in dieser hättest bereits die halbe app portiert.

Hätt' ich normalerweise auch so gesehen, aber so läuft das diesmal nicht!
Um ein Angebot für den Auftrag legen zu können, brauche ich eine Abschätzung. Und wenn ich da zu billig schätze, bin ich dran. Wenn ich zu teuer schätze wird nichts aus dem Auftrag. Das Projekt hat eine Größe, die man definitiv nicht an einem Nachmittag oder sogar nicht in einem Monat codet (da würden einem schon aus rein mechanischen Gründen die Finger abfallen...) Deswegen meine genauen Vorüberlegungen...

Zitat:

und keine angst, in 1, 2 jahren muss dein kunde sich entscheiden, das progy sterben zu lassen oder es zu portieren... da läuft dann langsam die 16 bit unterstützung von m$ aus ... .

Sehe ich auch so...

Viele Grüße, H