Delphi ist unbeliebt...angeblich

[nahpets]

Naja, dann hast Du ja schon ganz vieles, was Du einmalig verändern kannst, um dann später weitere Formulare nur noch davon abzuleiten.

[Redeemer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1384943)

Zitat:

Zitat von Hobbycoder (Beitrag 1384938)

Manche nehmen gerne die BitBtn, wo dann die Icons dann über den Kind von Delphi festgelegt werden.

Seitdem TButton mittlerweile auch Icons kann ist TBitBtn meiner Meinung nach obsolet.

Erzähl das mal den Leuten bei Wine.

Zitat:

Zitat von Der schöne Günther (Beitrag 1384951)

Zitat:

Zitat von greenmile (Beitrag 1384931)

Höre meistens "Sieht man". Sind die typischen Buttons und Styles. So wie früher der TP Button mit dem OK-Häcken davor

Ich erkenne Delphi-Anwendungen (es sind mehr als man denkt) immer daran dass so viele Delphianer immer vergessen Popups mit der Escape-Taste schließbar zu machen. Immer wenn ich das sehe untersuche ich die .exe im Verdacht eine Delphi-Anwendung zu haben, meistens liege ich richtig 8-)

Bis Windows XP und bis vor Delphi 2007 gab es die todsichere Variante, Rechtsklick auf ein Fenster in der Startleiste zu machen. VCL-Anwendungen haben 3 Menüeinträge (Minimieren, Wiederherstellen, Schließen, da es sich bei Delphi-Anwendungen um nicht sichtbare Hauptfenster handelt), alle anderen 6.

[samso]

Ein Gegenargument gegen Delphi ist für mich, dass es die meisten Bibliotheken nicht mit Delphi-Wrappern gibt (von einer Delphi-Implementation wage ich ja schon gar nicht zu träumen). D.h. während man bei C/C++ die Bibliothek einfach benutzt, muss man sich bei Delphi immer zunächst mal hinsetzen und einen Wrapper schreiben. Das hat auf der anderen Seite den Vorteil, dass man sich vor der ersten Benutzung schon intensiv mit der Bibliothek auseinander gesetzt hat. Aber in den meisten Fällen nervt es einfach nur.

[Delphi-Laie]

Zitat:

Zitat von Redeemer (Beitrag 1384996)

Ich erkenne Delphi-Anwendungen (es sind mehr als man denkt) immer daran dass so viele Delphianer immer vergessen Popups mit der Escape-Taste schließbar zu machen. Immer wenn ich das sehe untersuche ich die .exe im Verdacht eine Delphi-Anwendung zu haben, meistens liege ich richtig 8-)

Bis Windows XP und bis vor Delphi 2007 gab es die todsichere Variante, Rechtsklick auf ein Fenster in der Startleiste zu machen. VCL-Anwendungen haben 3 Menüeinträge (Minimieren, Wiederherstellen, Schließen, da es sich bei Delphi-Anwendungen um nicht sichtbare Hauptfenster handelt), alle anderen 6.[/QUOTE]

Das weckte sofort meine Neugier(de). Lazaurs soll mit Delphi entwickelt worden sein, bei dem klappt es, mit Delphi selbst klappt es erst recht. WinRar jedoch, angeblich auch mit Delphi entwickelt, bietet mir hingegen 6 Menüeinträge (ich probierte das soeben an der Version 3.91 portabel).

Mal eine Frage an die Experten: Woran liegt diese unterschiedliche Anzahl an Menüeinträgen, und bekommt das bei Delphi-Programmen auf den Standard 6 erhöht?

[Redeemer]

Warum das so ist, habe ich doch geschrieben: VCL-Anwendungen haben vor 2007 immer ein unsichtbares Hauptformular, genannt Application. Alles, was auf Startleiste zu finden ist, bezieht sich auf das Hauptformular. In VCL-Anwendungen konnte man beispielsweise den Text auf der Startleiste ändern (Application.Title), kann man in keiner anderen Umgebung. Da das Hauptformular nicht sichtbar ist, ergibt es keinen Sinn, es zu maximieren sonst was damit zu machen. Da man eine Anwendung nur als ganzes minimieren kann und man ein Schließen des Hauptformulars abfangen kann, sind diese Einträge trotzdem da.

Heute kann man das unsichtbare Hauptformular ausmachen. Der Befehl lautet:

Delphi-Quellcode:

Application.MainFormOnTaskbar := True;

WinRAR benutzt kein VCL.

[himitsu]

Zitat:

Zitat von Delphi-Laie (Beitrag 1385068)

da es sich bei Delphi-Anwendungen um nicht sichtbare Hauptfenster handelt.

Nein?
Schon lange nicht mehr.

MainFormOnTaskbar ist seit Jahren bei neuen Anwendungen per Standard immer aktiv.


Der Hauptgrund für die Änderung sind die seit Vista neu existierenden Funktionen der Taskleiste, vorallem Aero Peak.
Aber seit Windows 10 ist diese Funktion auch schon wieder standardmäßig deaktiviert. (im Windows)

[Redeemer]

Stand ja auch da: Vor Delphi 2007.

[warschonweg]

Stilistisch wundert es mich ja schon, dass so viele Leute lieber mit JS als mit Delphi arbeiten wollen. Wusste gar nicht, dass so viele Fünfzehnjährige auf StackOverflow abhängen... :D

Moderne Sprachen, die "wie Delphi" sein wollen, scheitern recht oft dabei, eine auch nur ansatzweise so kopfschmerzfreie Syntax zu bieten, haben allerdings (neben gelegentlicher Syntaxkürzung, weiter oben stand etwas Wahres über begin-end-Romane...) den unschlagbaren Vorteil, dass sie nüscht kosten. Es würde mich nicht wundern, wenn FPC vor Delphi LINQ "kann". Und ja, LINQ vermisse tatsächlich auch ich in jeder anderen Sprache. Common Lisp kann so was Ähnliches, aber auch nur über Umwege, und die LINQ-"Portierungen" für C++ u.vglb. sind meist eingeschlafen.

Trotzdem kommt mir kein C# ins Haus. Wahrscheinlich ist das hier in diesem Forum sogar Konsens, aber: Ich nehme am liebsten die Sprache, in der ich die gestellte Aufgabe mit meinen Fähigkeiten am effizientesten lösen kann. Kann ich kein Delphi, dann kann ich kein Delphi. :)

[Delphi-Laie]

Danke, Redeemer!

[bnreimer42]

Wenn man die Wahl hat: Ist man nicht in der Spreche am schnellsten, die man am Besten kennt?

Was ich aber in vielen Diskussionen vermisse, ist die Geschwindigkeit des Übersetzungsprozesses von Delphi. Das geht immer schneller, als bei allen übersetzten C-Varianten und kommt fast an Interpreter ran aber mit dem Vorteilen eines übersetzten Binaries.

Das ist für die Entwicklungs- und vor allem Debugging-Zeiten sehr bedeutsam, es sei denn man schreibt gleich korrekten Code.


Ansonsten ist diese Statistik schon deshalb irrelevant, weil sich die Delphi-Welt meiner Beobachtung nach nur beschränkt auf Stackoverflow rumtreibt. Für Sprachen wie Delphi ist Stackoverflow zu neu! Da gibt es ja u.a. dieses Forum als etabliertere Anlaufstelle! Stackoverflow ist halt auch nur ein Ausschnitt der Welt und damit auch darauf basierende Aussagen.