Sprachen mischen? C++, ObjectPascal

[Bernhard Geyer]

Zitat von HHick123:

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 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 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 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.

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