Delphi 9 - Eure Erwartungen

[Robert_G]

Zitat von phlux:

Basierend meiner Erfahrungen mit D7 Personal :
Ich hätte gerne wieder ne vernünftige IDE sprich so wie in Delphi5
- Ich möchte zur Debugzeit wieder sehn können, welche Werte die Variablen haben (Maus drüber->Hintfenster->Wert steht drin)
- Die alten Tastenkombos die automatisch die read und write Methoden schreiben wenn man Kompos erstellen will

Das funktioniert in meinem alten D7Pro einwandfrei.

Zum Thema:

• Entweder ich bin zu blöd, oder man kann in D8 nicht allen möglichen Actions (unter .Net heißen sie ja jetzt Commands ) neue Tastenkombinationen zuweisen.
  Das fände ich sehr wichtig. Ich will zum Bleistift per Tastenkombi zwischen Designerlayout, Codinglayout und Debuglayout springen könnnen.
  Außerdem würde ich gerne Macro aufzeichen/abspielen auf die gleichen Tasten legen können, die ich im PL/SQL Developer verwende.
  Eine Macro Library, in der man ein aufgezeichnetes Macro abspeichern und mit einem Tastaturkommando aufrufen kann wäre auch sehr sinnvoll.
• Die IDE soll endlich mit mehreren Monis klarkommen: Bei manchen Layoutdefinitionen springt sie vom linken auf den rechten Moni. Wähle ich das Layout nochmal aus, springt sie entweder noch weiter nach rechts (dann ist sie natürlich wech ), oder wieder nach links. Ich konnte bisher kein klares System hinter dem Bug feststellen, aber er ist tierisch nervig.
• Die Toolpalette darf nicht mehr als 0,5 Sekunden zum aktualisieren brauchen (beim Wechsel zwischen Code -> Design view).
  Generell müssen schon während des Schreibens in der Code-Ansicht, alle nötigen Infos zusammengesucht werden, um einen verzögerungsfreien Wechsel zu ermöglichen.
  Das gilt VOR ALLEM für den ar***langsamen ASP.Net-Designer!
• Der Debugger sollte dringend debugt werden.
  Er funktioniert unter WinForms so schlecht, dass ich lieber den CLR Debugger des SDKs verwende. Unter ASP.Net funktioniert er überhaupt nicht
• Warum, zum Geier, gibt es in D8 keinen Object TreeView mehr?

Das ganze mag nach ziemlich viel aussehen, aber bei anderen IDEs sind die meisten Funktionen NORMAL.

[MaBuSE]

Zitat von merlin17:

ich habe mir bei dem Lesen dieses Threads auch mal Gedanken gemacht:

aha.

Zitat von merlin17:

Zitat:

Win32 + .NET in einer IDE verwendbar

Microsoft es nicht einmal probiert....warum nur
Wie läuft es mit Thirdparty-Komponenten ab? Ich glaube nicht, dass
hier noch sehr viel Gehirnschmalz in die "alte VCL-Welt" investiert wird.

Hmmm, meines Wissens kann man bei VS.NET sehr wohl auch win32 Code erzeugen.
Allerdings nicht mit WinForms.
Aber ist ja auch bei Delphi nicht anders. VCL für Win32 und .NET bzw. WinForms nur für .NET

Zitat von merlin17:

Zitat:

Schneller

-> Sorry, aber was kostet ein EntwicklerRechner heutzutage? Wir brauchen ja
nicht die GHz ohne Ende, ein schönes DualProc-System mit Arbeitsspeicher (1-4 GB)
und einem schnellen Plattensystem?!?! Und war vor vielen Jahrzehnten mal einen
386DX20 mit 4 MB für knapp 5.000,- DM gekauft hat, er lächelt über die aktuellen
Preise (z.B. Dual Xeon IV mit 1,7 GHz und 1 GB RAM sowie Ultra-160 SCSI-System nicht
nichtmal 1.000,- EUR....). Und dieses Teil ist als Entwicklersystem rasent schnell.

Hmmm, ich habe einen Rechner mit 2,6 GHz P4 mit HT (Also für das Betriebssystem 2 Prozesoren)

Die IDE ist sehr langsam!!! (Wechsel zw. Code und Designer, Starten, ...)
Das es schneller geht beweist Microsoft ja mit VS.NET.
Außerdem kann nicht mit Einführung eines neuen Entwicklererkzeugs gleich die ganze IT-Landschaft in einem Unternehmen geändert werden. Unternehmen haben die Rechner meist auch geleast, so dass die Rechner min. 3 Jahre genutzt werden.
Stell Dir vor Du hast nicht einen Programmierer sondern 50 oder 100.
Wenn Du nun die Wahl hast ein relativ teures "Delphi 8/9 Architekt + neue Rechner"-Paket oder ein relativ günstiges "VS.NET ohne neue Rechner"-Paket.
Wenn Borland da nicht was macht, werden viele "Firmenkunden" wechseln, und nur von "Privatleuten" kann Borland nicht leben. (Zumal die Produktpalette von Borland ja mittlerweile Richtung größere Firmen geht (Integrating the Enterprise ))

Zitat von merlin17:

Zitat:

Absturzsicherer

Bei Delphi8 war es ja V1.1 in der .net-Welt (V1.0 war ja die C#Builder-IDE)
Bei einer Kombination von .net und Win32 wird es "wieder ein V1.0"-Welt, oder?

Hmmm, ich verstehe nicht was Du damit sagen willst.
Es ist sehr wohl machbar aus einer .Net Anwendung ein Win32 Projekt zu erstellen.
Das Framework schränkt ja die Programme nicht in Ihrem Tun ein.

Zitat von merlin17:

Zitat:

entwicklung für 64bit systeme ??

-> Hier läuft in den amerika. Newsgroups gerade ein Thread, im .net-Bereich ist es
ja mehr oder weniger erledigt. bei Win32 muss wahrscheinlich der Markt entscheiden.

Der .net Anwendung ist es egal auf welcher Plattform sie läuft.
Das ist ja einer der Vorteile von .net.
Das "vorkomplilierte" Projekt wird ja beim Start vom .net Framework nochmals für die Plattform kompiliert. -> damit läuft es auch optimal auf 64-bit. / theoretisch sogar auf Linux (Mono)

Zitat von merlin17:

Zitat:

Möglichkeit der Platformwahl (.net 1.1 / 1.2 bzw. 2.0)

Da müssen wir wahrscheinlich auf VS.NET 2005 warten wie es MS dort "integriert".
und hier wird Borland immer einen Schritt hinter MS sein, ist aber sicherlich kein
prinzipeller fehler!

VS.NET kann das ja schon jetzt !!!
Im Moment kann man zwischen .NET 1.0 und .NET 1.1 wählen.

Zitat von merlin17:

das .NET CompactFramework.
-> ist eher ein Lizenzrechtliches und nicht so sehr ein technisches Problem,
zumindest kam es auf der BorCon03 in SanJose so herüber.

Ist ja schon angekündigt. Soll in Delphi 9 kommen (Wenn nicht, dann in 10)

Zitat von merlin17:

Und abschließend: Bezahlbar muss so etwas auch sein, im Dezember 03 gab es Delphi8
im Dezember04 soll es Delphi9 geben (hat Dale Fuller in einem Interview gesagt).
Und die richtigen Version (Prof bzw. eher Enterprise oder Architect....) sind nicht
mehr so billig wie in Delphi 1-4 Zeiten.......
Und wo ist der Mehrwert der einzelnen Updates?? Allerdings wenn nicht mehr jede VErsion
gekauft wird, dann kann der Softwarehersteller Borland irgendwann kein neues Projekt anfangen.

Ein wichtiger Punkt ist Support.
Keine vernünftige Firma wird heute noch in D2..D4 programmieren, da

• erstens die "neuen" Betriebssysteme nicht optimal unterstützt werden,
• zweitens keine Garantie auf y2k Kompatibilität seitens Borland ausgesprochen wurde und
• drittens es offiziell keinen Support mehr gibt.

Zitat von merlin17:

Und eine Mischkalkulation wie bei M$ gibt es ja nicht (Betriebssysteme, Office-Systeme, Backoffice-Systeme....
X-Box etc.etc.)
ein kritischer
thomas

Hier stimme ich Dir zu

[neolithos]

Zitat von MaBuSe:

VS.NET kann das ja schon jetzt !!!
Im Moment kann man zwischen .NET 1.0 und .NET 1.1 wählen.

Wo ich ich habe VS 2003 in finde keinerlei Einstellungsmöglichkeit!

[sakura]

Zitat von neolithos:

Zitat von MaBuSe:

VS.NET kann das ja schon jetzt !!!
Im Moment kann man zwischen .NET 1.0 und .NET 1.1 wählen.

Wo ich ich habe VS 2003 in finde keinerlei Einstellungsmöglichkeit!

Ich habe mir sagen lassen, daß man es einstellen kann, allerdings ignoriert VS 2003 die Einstellung

......

[maximov]

Ich wünsch mir

• - Attribute auch für native-code (win32 oder 64)
  - Makros
  - inline funktionen
  ...
  - natürlich 'bugfrei'
  - IDE schneller

[Alexander]

Das mit dem Dualmonitor ist mir auch wichtig. Auch Delphi 7 zickt da gewaltig rum. Das Fenster, in dem die Object-Hierachie zu sehen ist, wandert trotz mehrfachem Speichern der Oberfläche nach dem Kompilieren immer den Platz

[Chewie]

Zitat von w3seek:

Die Forward-deklarationen einfach in header dateien packen, die einfach inkludieren und am ende wird alles einfach zusammengelinkt.

Include-Dateien kann Delphi auch verwenden.

[Christian S.]

Als Sprachfeature fände ich Templates noch ganz nett.

[Robert_G]

Mein täglicher Wunschzettel

Die Sprache von D8 wurde ja (möglichst werbewirksam ) in Delphi.Net umbenannt.
Warum ist sie dann eigentlich so unverträglich mit dem FrameWork?

• Warum muss ich einen nervigen & sinnlosen typ für einen Array anlegen, nur um zur Laufzeit eine Instanz oder einen Rückgabewert davon erzeugen zu können???
  C#
    XYZ = new Object[] {'la', 'le', 'lu'}; Delphi.Net
  
  Delphi-Quellcode:

    type TNervigerSinnloserTyp = array of object;
    ...
     XYZ := TNervigerSinnloserTyp.Create('la', 'le', 'lu');

• Warum kann ich nicht einfach Object für ein System.Object schreiben?
• Warum ist, lokal deklariert, ein string ab & zu etwas anderes als ein System.String?
• Warum funktioniert das in c# aber nicht in delphi.Net? (nicht über den Sinn philosophieren -> ist nur ein Beispiel )
  
  
  Delphi-Quellcode:

    private DataSet fDataSet;
    public  DataSet  DataSet
    {
      get {return fDataSet};
      set {fDataSet = value};
    }

    property DataSet :DataSet read fDataSet write set_DataSet; Ich _MUSS_ System.Data vor den Typ schreiben, obwohl es für den Compiler ABSOLUT eindeutig sein sollte, was ich da vorhabe.
  
• Warum legt er in 90% aller Fälle die privaten Felder falsch an, wenn ich auf class completion ([Strg]+[Shift]+[C]) drücke???
  Man muss sie dann eigenhändig in den private-Teil ziehen!
  Ab & zu würfelt er es auch komplett durch einander.

p.s.: das Arrayproblem gab es auch schon in Delphi32!

Ich wäre schon zufrieden, wenn ich auch nur auf die Hälfte der Fragen ein Antwort bekomme, wie:
"Upps, sorry , das haben wir komplett verschlampt. In D9 wird das behoben."

[MathiasSimmack]

Zitat von Robert_G:

Ich wäre schon zufrieden, wenn ich auch nur auf die Hälfte der Fragen ein Antwort bekomme, wie:
"Upps, sorry , das haben wir komplett verschlampt. In D9 wird das behoben."

Das wäre ein Schuldeingeständnis, für das man evtl. zur Rechenschaft gezogen werden kann.