Delphi am "Ende"?

[bernau]

Zitat von QuickAndDirty:

Ohne BPL kann man Komponenten wohl nicht in die IDE integrieren...deswegen kommen die ständig zum Einsatz!

Habe Fremdkomponenten und eigene Komponenten in der IDE. Dennoch wird daraus eine EXE.


@Alle anderen: OK. Ihr habt recht. Habe nur Kunden mit DSL. Meine Software ist "nur" 15MB groß. Obwohl es mittlerweile 500.000 Zeilen Quellcode umfasst. Liegt aber auch vieleicht daran, daß ich nur wenige Fremdkomponenten verwende. Wenn möglich schreibe ich Komponenten selber. Ist zwar erst mal mehr Auffwand. Doch dafür bin flexibel in der evtl. benötigten Erweiterung.

[QuickAndDirty]

Zitat von bernau:

Zitat von QuickAndDirty:

Ohne BPL kann man Komponenten wohl nicht in die IDE integrieren...deswegen kommen die ständig zum Einsatz!

Habe Fremdkomponenten und eigene Komponenten in der IDE. Dennoch wird daraus eine EXE.

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

[bernau]

Zitat von QuickAndDirty:

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

Verstehe jetzt nicht worauf du hinaus willst. Meine Aussage ist doch nur, daß das Programm beim Enduser als eine EXE landet. In der IDE verwende ich die Packages, in der die Komponenten sind. Was hat das nun mit den BPLs beim Kunden zu tun?

[QuickAndDirty]

Zitat von bernau:

Zitat von QuickAndDirty:

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

Verstehe jetzt nicht worauf du hinaus willst. Meine Aussage ist doch nur, daß das Programm beim Enduser als eine EXE landet. In der IDE verwende ich die Packages, in der die Komponenten sind. Was hat das nun mit den BPLs beim Kunden zu tun?

Oh. Ich habe das so wahrgenommen das hier BPLs und die bloße Existenz des Konzepts im allgemeinen schon als murks an gesehen werden. Und dem wollte ich nur entgegen halten das ich das recht praktisch finde um z.B. Komponenten auszuliefern....
Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

[bernau]

Zitat von QuickAndDirty:

Oh. Ich habe das so wahrgenommen das hier BPLs und die bloße Existenz des Konzepts im allgemeinen schon als murks an gesehen werden. Und dem wollte ich nur entgegen halten das ich das recht praktisch finde um z.B. Komponenten auszuliefern....
Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

Na dann sind wir ja einer Meinung

[Stevie]

Zitat von QuickAndDirty:

Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

Genau, Windows besteht ja auch aus einer großen Datei... oh halt, es sind viele kleine Bibliotheken. Bei nem kleinen Tool gebe ich dir Recht, da isses irgendwie über, statt einer Exe Duzende von Dateien auszuliefern (die in der Summe wahrscheinlich sogar größer wären als eine exe). Aber bei einen großen komplexen Anwendung mit hunderten von Modulen, wo Austauschbarkeit einzelner Teile gewünscht ist, sind bpls/dlls unumgänglich.
Warum kann man auch in .Net wohl mit Assemblies arbeiten? Weil man alles in eine Exe packen will? Wohl kaum, gell?

Stichwort Migration: Viele stellen sich das so einfach vor, klar mal ebend nen Delphi Programm auf C# migrieren... wenn's sonst nix is Warum läuft wohl noch so viele Software auf Cobol und Co? Weil's ma ebend auf C# und Co migriert werden kann?

[Question_mark]

Hallo,

Zitat von vagtler:

Wäre übrigens schön, wenn sich auch Matthias noch mal an diesem Thread beteiligen würde.

Muss er nicht unbedingt, aber die eher abrupte Enthaltsamkeit von Matthias zu diesem Thema spricht doch ganze Bände ... Da sind wohl irgendwie die Argumente ausgegangen

Oder Mättes läuft jetzt mit einem Maulkorb von Embarcadingsbumms herum.

Um dann mal wieder zum Thema zurück zu kommen :

Delphi ist noch nicht am Ende, obwohl Emba aufgrund falschem und inkonsequentem Marketing fleissig am eigenen Untergang bastelt. Ich weiss nicht warum, vielleicht müssen auch erst die Leichen, die CodeGear hinterlassen hat, aus dem Keller geräumt werden.
Eigentlich werden doch hier im Forum alle Wünsche der Delphi-User an das Produkt klar und deutlich vorgetragen, warum wird das vom Produktmanagement völlig ignoriert ?

Und warum werden Aussagen aus Anno 2007/2008 von Emba zum 64-Bit Compiler heute verleugnet ?
Wobei ich gerade überlege, ob diese Aussage von CodeGear oder von Emba stammt ? Also vielleicht doch eine Leiche aus dem CodeGear Keller.

Ich persönlich hoffe, das es in Zukunft auch noch ein Delphi 2020 geben wird, aber das wird nur von Emba abhängen. Zum Beispiel fehlt eine Version Delphi Turbo Professional XE (analog zum ehemaligen Pendant zum Delphi 2006), da habe ich die Lizenzen wie warme Brötchen gekauft.

In diesem Sinne, schauen wir dann mal gebannt auf die die nächsten Entscheidungen der Marketingabteilung, der ich in Zukunft ein besseres Händchen bei Ihren Entscheidungen wünsche ...

Gruß

Question_mark

[Assarbad]

Zitat von Question_mark:

Und warum werden Aussagen aus Anno 2007/2008 von Emba zum 64-Bit Compiler heute verleugnet ?
Wobei ich gerade überlege, ob diese Aussage von CodeGear oder von Emba stammt ? Also vielleicht doch eine Leiche aus dem CodeGear Keller.

Siehe Link zum Internetarchiv oben. Stammt noch von Codegear.

[Phoenix]

Ich will hier nichts schön reden, kann das aber schon verstehen, wenn man mal folgendes Bedenkt:

Zitat von Question_mark:

Eigentlich werden doch hier im Forum alle Wünsche der Delphi-User an das Produkt klar und deutlich vorgetragen, warum wird das vom Produktmanagement völlig ignoriert ?

Weil es a) nicht nur Delphi-User sind.

Beispiel: Es gibt mehr C++ Builder installationen als Delphi-Installationen. Nur die C++ Community kommt im Web so gut wie gar nicht vor. Die pflegen einen direkteren Kontakt und deswegen bekommen wir die und deren Wünsche nicht mit. Das heisst ein größerer Anteil an den Entwicklungen der IDE wird schonmal von einer für uns unsichtbaren, aber wohl etwas größeren Quelle fremdbestimmt.

Und weil b) die weltweite Delphi-Community eben (leider ) nicht nur aus der Delphi-PRAXiS besteht.

Delphi wird viel in Russland eingesetzt, Brasilien scheint auch ganz kräftig zu sein, mal von Japan ganz abgesehen. Und insbesondere bei den größeren Institutionen und Firmen die Delphi (und C++Builder) einsetzen (z.B. auch die NASA) bin ich mir 100% sicher dass die ihre Wünsche auch direkt Embc. mitteilen und das nicht über Foren oder Newsgroups tun. Auch die Wünsche gehen an uns vorbei, haben aber großen Einfluss auf das Produkt.


Dazu kommt c), dass in unserer Community hier wahrscheinlich ein größerer Anteil an Usern Delphi eher privat/nicht-Kommerziell verwendet, weil er a) durch die Schule muss, es b) in der Schule mal hatte, cool fand und sein privates Zeug damit macht. Hintenrum kommt aber damit kein Geld rein, was der User wieder ein Update stecken könnte.

Damit ist ein ordentlicher Anteil an der aktiven Userbasis der DP leider auch nicht die Zielgruppe von Embc.

Noch schlimmer: Diejenigen, die hier mit Delphi ihre Brötchen verdienen sind meist sogar nicht die Entscheider in der Firma, die wiederum bestimmen könnten welche Version wie oft gekauft wird. Das macht unsere Position nicht stärker.

Das heisst nicht, dass Embc. nicht auf uns hört. Das heisst nur, dass es da aber auch andere, lauterere Stimmen gibt, die Embc. direkter ansprechen als wir.

Deswegen hört Embc. wahrscheinlich eher auf diese als auf uns. Das hat nichts mit ignorieren zu tun, sondern mit wirtschaftlicher Priorisierung. Mit den anderen verdienen sie mehr als mit uns, und deswegen werden die bevorzugt behandelt.

Ich will hier wie gesagt nichts schön reden, aber ich kann die Position schon nachvollziehen.