Träume, Wünsche und Wahnvorstellungen...

[RWarnecke]

Ich wünschte die würden endlich den Cross-Compiler rausbringen, damit ich Programme für Linux entwickeln kann. Das bräuchte ich ganz dringend, da ich gerade mehrere Linux-Server aufsetzen muss und zur Zeit alles versuche mit Bash-Skripten zu lösen.

[Phoenix]

Nimm doch Prism. Das Kompilat läuft einwandfrei unter Linux, und gegen Ende des Jahres sollte da die IDE auch laufen.

[rainerg]

Ich habe seit ein paar Wochen XE Starter (vorher D6 Pro und davor alle Versionen ab D1 mitgemacht) und bin sehr begeistert von der neuen Version und eigentlich erstmal wunschlos glücklich - auch wenn Starter wohl recht weit eingeschränkt ist.

Aber z. B. endlich - nach 17 Jahren - wieder einklappbare Procs/Funcs (wann ist das denn dazu gekommen?). das gefiel mir sehr!

[Neutral General]

Zitat:

Zitat von rainerg (Beitrag 1101479)

Aber z. B. endlich - nach 17 Jahren - wieder einklappbare Procs/Funcs (wann ist das denn dazu gekommen?). das gefiel mir sehr!

Ich glaube irgendwann bei Delphi 2005/2006 oder so müsste das dazugekommen sein... :gruebel:

PS: Delphi 2005 gabs doch oder? Das benutzt aber niemand, kann das sein?
(Es sei denn Delphi 2005 existiert nicht.. das würds erklären.. :mrgreen:)

[mleyen]

Zitat:

Zitat von Neutral General (Beitrag 1101480)

PS: Delphi 2005 gabs doch oder?

Ja, gabs.

Zitat:

Zitat von Neutral General (Beitrag 1101480)

Das benutzt aber niemand, kann das sein?

Afaik war es unbenutzbar. :mrgreen:

[himitsu]

Delphi 8 (quasi ein D7 nur für .Net) und die D2005 sind, laut Aussagen Vieler/Einiger wohl das Schlimmste, was es je gab.
In 2006 isses zumindestens schon drin ... 2005 wäre aber auch gut möglich, da damit die neue IDE eingeführt wurde.

PS:

Delphi-Quellcode:

{$REGION 'zusammenklappbar'}
...
{$ENDREGION}

[RWarnecke]

Zitat:

Zitat von Phoenix (Beitrag 1101477)

Nimm doch Prism. Das Kompilat läuft einwandfrei unter Linux, und gegen Ende des Jahres sollte da die IDE auch laufen.

Ja, das liebe Prism. Irgendwie komme ich damit nicht zurecht. Deshalb lieber die gewohnte IDE und die gewohnten Kompo's.

[mschaefer]

Phoenix, bei RemObjects, sucht derzeit auch eher ASP.NET u. C#-Entwickler. und PRISM ist nun mal ideal um Delphi-Entwickler sanft ins ".NET" zu bringen. In dem Fall kann ich Euch jedenfalls bestätigen, dass Embracadero hier mitliest. Sowas definiert Verhältnisse zwischen Vertragspartnern.


Nachtrag:

Wenn PRISM schon bei den Evangelisten nur Nebenjob ist und C# bevorzugt wird, dann ist die Devise pro Sprache ein Framework eine optimale Vorgehensweise zum Lernen. Der C#-Syntax ist als Lernaufwand im Verhältnis zum Framework minimal! An .NET führen wenige Wege vorbei.

Unter obiger Prämisse würde ich mir wünschen, dass Embracadero den neuen Compiler so anlegt, dass sein Backend um andere Prozesssoren erwieterbar ist um Arm und andere zu unterstützen und/oder, dass die IDE mit verschiedenen Compilern angewendet werden kann, ähnlich dem Compiler Plugin von Andreas.

[Neutral General]

Zitat:

Zitat von mschaefer (Beitrag 1101493)

In dem Fall kann ich Euch jedenfalls bestätigen, dass Embracadero hier mitliest. Sowas definiert Verhältnisse zwischen Vertragspartnern.

Woher weißt du dass da jemand mitliest? :shock:

[MEissing]

Zitat:

Zitat von Neutral General (Beitrag 1101495)

Woher weißt du dass da jemand mitliest? :shock:

Also ich lese hier mit.

(Verschwinde aus dem Thread aber wieder in den invisible-mode.)

[Phoenix]

Zitat:

Zitat von mschaefer (Beitrag 1101493)

In dem Fall kann ich Euch jedenfalls bestätigen, dass Embracadero hier mitliest. Sowas definiert Verhältnisse zwischen Vertragspartnern.

[Offtopic]
Nur mal so zur Info: Das eine hat mit dem anderen so rein gar nichts zu tun.

Mein Hang und meine Vorliebe zu .NET hat weder mit dem einem noch mit dem anderen Job zu tun, sondern ist meine eigene, private Überzeugung davon, dass .NET für viele Anwendungsfälle (u.a. echtes Cross-Platform und Serverbasierte Entwicklung) einfach um längen besser geeignet ist als irgendwelche nativen Geschichten.

Die ASP.NET C#'ler sucht mein regulärer Arbeitgeber, für den ich in Vollzeit im R&D Team ein Content Management System entwickele und pflege. Auch hier wird ASP.NET mit C# eingesetzt und wir sind im Bereich Webbasierte Finanzapplikationen für Banken der Weltmarktführer.

Für RemObjects arbeite ich aus reinem Spass an der Freude in meiner Freizeit (meistens Samstags) und der Evangelism-Job dort beinhaltet primär die Vorbereitung und das halten von Konferenzvorträgen, sowie mich mit Prism und Cooper zu beschäftigen und Bugs zu finden bevor es jemand anderes tut ;-)

Rein privat ziehe ich C# übrigens Prism vor, aber ich kann vollkommen nachvollziehen dass sich ein Delphianer der sich eh schon in einen riesen-Batzen wie das .NET Framework einarbeiten kann / will / darf / muss sich nicht noch mit einer vollkommen anderen Syntax beschäftigen möchte, und soo schlecht ist Pascal ja nun auch nicht ;-)
Prism bietet darüber hinaus halt auch noch den Vorteil dass man als Delphianer seine alte Logik, sofern man sauber programmiert hat, auch noch auf sämtliche anderen Plattformen mitnehmen kann und nicht neu schreiben muss. Und genau an der Stelle bin ich auch privat davon überzeugt dass Prism für Delphianer die einfachste Möglichkeit ist, auf anderen Plattformen wie dem Mac, Linux oder auch auf den Mobilen Plattformen Fuss zu fassen. Nicht mehr, aber auch nicht weniger.[/Offtopic]

[shmia]

Ich versuche meine Idee nochmal, aber diesmal eine Stufe schwächer.

Die VCL müsste als Repository (z.B. SVN) verfügbar sein und bestimmte Delphi-Cracks (ich denke da vorallem an die Jedi-Leute) haben Rechte zum Einchecken von neuen Revisions.
Mit der JCL wurde bewiesen, dass diese Leute qualitativ hochwertigen Code produzieren können.
Bei der JVCL müsste man dagegen mit der Machete durchgehen um aus der Masse mehr Klasse zu machen.
Nun, auf jeden Fall wäre es so möglich die Lücken in der VCL (z.B. veraltete Windows API) aufzufüllen und die Kräfte zu bündeln.

Also die VCL wäre dann kein Open-Source, aber geöffnet für Veränderungen aus der Delphi Community.

[mkinzler]

Zitat:

Zitat von Neutral General:
PS: Delphi 2005 gabs doch oder?
Ja, gabs.

War aber eigentlich nichts neues. Bestand aus D8 (.Net) und die neue IDE für den "alten" Compiler von D7Upd3.

[generic]

Neben den 64bit Compiler könnte ich gut einen brauchen, welcher auch für ARM-Prozessoren kompiliert (für Windows 8).

[blackfin]

Ich hätte gerne sowas wie XNA für Delphi :-D (kostenlose Version mit Spiele-Framework)
Das würde auch viele junge Programmier-Anfänger auf die Delphi-Platform holen, die gerne in die Spieleentwicklung einsteigen möchten und dann auch später bei Delphi bleiben, wenn es um seriösere Anwendungsfälle als Spiele geht :-)

Vielleicht etwas weit hergeholt, ich weiss, jedoch sehe ich XNA auch als nichts anderes an, als die erfolgreiche Methode, Leute so früh wie möglich an die Visual Studio Umgebung zu gewöhnen und schlussendlich zu binden :-)

Und ja, es gibt für Delphi genug Möglichkeiten, Spiele zu entwickeln, aber eine "Out-of-the-box"-Lösung eines Spiele-Frameworks fände ich toll und würde sicher auch die Userbase vergössern.

[Phoenix]

Zitat:

Zitat von blackfin (Beitrag 1101529)

Ich hätte gerne sowas wie XNA für Delphi :-D (kostenlose Version mit Spiele-Framework)

Erm.. gibts doch ;-)
Siehe http://blogs.embarcadero.com/pawelgl...08/12/11/38629

[blackfin]

Ja sowas...
Da leb ich wohl hinterm Mond :)
Ich meine aber eigentlich nicht für Prism, sondern fürs W32-Delphi.
Aber schick ist das ja trotzdem, schau ich mir doch gleich mal an :) Danke.

[Elvis]

Zitat:

Zitat von blackfin (Beitrag 1101567)

Ich meine aber eigentlich nicht für Prism, sondern fürs W32-Delphi.

Ich dachte für Anfänger?
Die letzten 2 Male, die ich jmd Delphi gezeigt hatte kamen nur Dinge zurück wie: "Die Syntax! o_O Grausam!", oder "Man ist das alles hakelig und nervig!" In beiden Fällen hatten diejenigen Erfahrung mit Python bzw. Ruby gehabt, und dann kannst du denen mit sowas Umständlichen nicht mehr kommen.

Und eigentlich haben sie Recht. Ich denke EMB hat erkannt, dass man mit Delphi die Jugend nur noch vergraulen kann. Und deshalb gibt es keine Turbos oder ähnliches.
Außerdem gibt es ja keine/kaum exklusive Super-Features, die man rausschneiden könnte, um einen Preisunterschied zu rechtfertigen. Mein D2010 Pro fühlt sich ja billiger und einfacher gestrickt an, als etwas, was ich für lau bei SourceForge saugen kann.

[hanspeter]

Wenn man endlich wüste, wie es mit Delphi/VCL weitergeht, dann könnte man auch planen.
VCL ist allein schon deswegen ein Auslaufmodell, weil sie auf der gleichen API wie Winforms aufsetzt.
Winforms ist ein Auslaufmodell. Es ist also keine weitere Entwicklung zu erwarten.
In der Ausbildung haben wir zwischenzeitlich auf C# und wahlfrei Python umgestellt.
Die Ursache ist einfach, dass sich in fast allen Sprachen { } durchgesetzt hat.
Kommentar der Kids. "Was soll ich mit den umständlichen Gefrickel und ich will etwas, wo ich auch daheim mit basteln kann. 150 Euro? Die spinnen."

Mein Wunsch Kompatibilität zu Assemblys. Ablösung der umständlichen BPL. Eine Schnittstelle zu WPF.


Gruß Peter

[Phoenix]

Zitat:

Zitat von hanspeter (Beitrag 1101696)

Mein Wunsch Kompatibilität zu Assemblys. Ablösung der umständlichen BPL. Eine Schnittstelle zu WPF.

Hydra?

[Elvis]

Zitat:

Zitat von Phoenix (Beitrag 1101699)

Zitat:

Zitat von hanspeter (Beitrag 1101696)

Mein Wunsch Kompatibilität zu Assemblys. Ablösung der umständlichen BPL. Eine Schnittstelle zu WPF.

Hydra?

Basiert Hydra nicht immer noch auf BPLs? Hilft also recht wenig was Kompatibilität angeht.
Man kann immer noch nur "Assemblies" in einen Prozess laden, die mi der gleichen Compiler-Version gegen die gleichen Package-Versionen (read:VCL/RTL) kompiliert wurden.

[Thom]

Unterhalten sich zwei:
- Siehst den Alten da hinten? Kann man mit dem Ding überhaupt noch fahren?
- Hey - guck mal, wie mein Auto aussieht. Geil was?
- Boh eh - aber da mußt du dir mal meins reinziehen. Das ist ja sowas von aufgemotzt. Das springt schon an, wenn ich die Tür aufmache.
- Mit was fährt deins?
- Aral. Das ist cool! Und deins?
- Shell. Das ist doch viel schicker!

Und damit schalte ich mich ebenfalls in den invisible-mode, um in Ruhe darüber nachdenken zu können, ob ich lachen oder eher weinen soll...

[mkinzler]

Oder man verwendet Delphi.Prism, dann werrden automatisch Assemblies verwendet.

[Codewalker]

Für Delphi würde ich mir wünschen

• Vernünftig dokumentierte API um Experten zur schreiben
• Den Mut bei Embarcadero, mehr Vertrauen und Verantwortung in die Community zu legen. Die automatisch erzeugten Einträge in der Hilfe und der Wiki (XX.YY ist ein Member das Klasse XX) hätte man auch einfach weglassen können. Wäre ehrlicher gewesen und suggeriert nicht "da ist was" obwohl da eigentlich nix ist. Die Community und viele Einzelne haben viel, was Delphi verbessern kann (die JCL, Andreas Hausladen, das DEC .... die Liste ist lang und es gibt sicher nicht wenige in der Community, die mitmachen würden).
• Die Sprache von der IDE zu lösen. Die Verbindung hat (im Gegensatz zu Java & Co) zur Folge, dass viele neue Features nur wenig genutzt werden, weil sie halt nicht jedem zur Verfügung stehen und nervige Fehler (z.B. der Enumerator bei den Generics) nicht für alle, sondern nur für extra-zahlende gefixt werden. Warum nicht die IDE für Euros anbieten, den Compiler gibt für OpenSource und Freeware gratis (das lockt wieder neue Leute in die Sprache, was wirklich nötig ist) und wer mit Delphi Geld verdienen will, der holt sich halt eine Compilerlizenz (meinethalben mit Laufzeit 1 Jahr, damit regelmäßig Geld in die Kassen kommt). Firmen werden es sowieso machen und werden es befürworten, nicht immer für neue Sprachfeatures gleich die IDE wechseln zu müssen.

naja und die Traumliste:

• Entschlackung und anschließende Standardisierung der Sprache
• Cross-Compiling für Windows,Linux,Mac (im Smartphone-Markt ist mit einer Delphi-IDE imho nix zu holen)
• mehr Transparenz seitens Embarcadero (z.B. verbindliche Roadmap (ich sag nur 64-Bit), mehr Präsenz in den Communities)

[Der Jan]

VCL-Designer und Delphi-Toolchain als Netbeans-Plugin ...

Bei den Sprachfeatures halte ich mich mal zurück. Bin ja schon über die Generics heile froh :)

Crosscompiling wäre nice.

[Codewalker]

Ist mir doch gerade noch etwas aufgefallen, was fehlt: Der blöde E2195 muss weg, ich will endlich lokale Variablen initialisieren können. Compilermäßig dürfte das wenig Aufwand sein.

Delphi-Quellcode:

procedure TuWas;
var
 i: Integer = 1;
 S: String = 'Test';
begin
{ ... }
end;

Und Zuweisungsoperatoren a la C++ wären auch nett:

Delphi-Quellcode:

 i += 1;

[stahli]

Tools:
- integrierter Ressourcen(Icon-)Editor

Debugging:
- Debuging für einzelne Unit bzw. Package in Projektoptionen deaktivieren
- Bereichsprüfung standardmäßig ein
- Überwachte Ausdrücke: Weg"Optimierung" von Self abschalten
- Haltepunkte händisch und automatisch (Unit+Zeile) sortieren
- Umsortierung überwachter Ausdrücke per Drag&Drop

Compilierung:
- Fehlerinfo bei Compilierungsfehler weglassen und direkt zu Quelltext springen (war bei D2009 noch so, in XE muss erst Fehler bestätigt werden)
- Gleiches gilt für Infofenster nach Compilierung abhängiger Packages (die Nachricht (neu in XE) ist unnötig)

IDE:
- UnitRegister optional MultiLine
- SplitEditor
- Frames als Blackbox markieren (Änderungen innerhalb eines Frames im Formular sowie auf Wunsch Darstellungen der enthaltenen Controls verhindern (nur graue Fläche mit Frame-Namen))

Features:
- zirkuläre Unitreferenzen ermöglichen (wenigstens teilw. z.B. durch Deklarationen wie

Delphi-Quellcode:

MyClass = class in OtherUnit;

(Da die Foreward-Deklaration in einer Unit geht, sollte sich dies auch Unit-übergreifend realisieren lassen.)
- Automatische "Nilung" von freigegebenen Objekten und Referenzen darauf (also ein integriertes Observer-Patterns).
- Data-Bindings (an denen Stevie ja bereits arbeitet)
- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel :wink:)
- try .. except .. finally .. end
- Und VOR ALLEM einen brauchbaren und in Delphi integrierten OR-Mapper (z.B. ala ECO). (Ok, das wäre eine zu starke Konkurenz zu meinen odControls - also ziehe ich den Wunsch lieber zurück :mrgreen:)

[Namenloser]

Zitat:

Zitat von stahli (Beitrag 1101758)

- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel :wink:)

Ich glaube damit stehst du ziemlich allein. Warum sollte man das exakt selbe Feature doppelt implementieren? Bei den restlichen Punkten stimme ich dir aber weitestgehend zu.

[himitsu]

> zirkuläre Unitreferenzen ermöglichen
lieber nicht
Klar, es würde teilweise einiges einfacher machen, aber auch viele Fallstricke eröffnen.
(PS zirkuläre gezieungen geht nicht, die Interface-Abschnitte dieses nicht zulassen)

FinallyExit lieber nicht (PS: hier hassen eh viele die GOTOs :zwinker:), aber bei try..except..finally..end wäre ich dabei

Zitat:

Und Zuweisungsoperatoren a la C++ wären auch nett:

Aber nur, wenn als Erweiterung des

Delphi-Quellcode:

:=

, also nur für Zuweisungen
und blos nicht innerhlab von IFs und Co. :wall:

[himitsu]

> zirkuläre Unitreferenzen ermöglichen
lieber nicht
Klar, es würde teilweise einiges einfacher machen, aber auch viele Fallstricke eröffnen.
(PS zirkuläre gezieungen geht nicht, die Interface-Abschnitte dieses nicht zulassen)

FinallyExit lieber nicht (PS: hier hassen eh viele die GOTOs :zwinker:), aber bei try..except..finally..end wäre ich dabei

Zitat:

Und Zuweisungsoperatoren a la C++ wären auch nett:

Aber nur, wenn als Erweiterung des

Delphi-Quellcode:

:=

, also nur für Zuweisungen
und blos nicht innerhlab von IFs und Co. :wall:

Das wäre dann sogar halbwergs kompatibel zur

Delphi-Quellcode:

:=

-Syntax
[:+-*/]=


Über Record-Operatoren für "Standard"-Typen, könnte man die Multi-Events für OnXYZ leicht nachbauen.

[bernau]

Zitat:

Zitat von stahli (Beitrag 1101758)

- Frames als Blackbox markieren (Änderungen innerhalb eines Frames im Formular sowie auf Wunsch Darstellungen der enthaltenen Controls verhindern (nur graue Fläche mit Frame-Namen))

Au ja. Das zähle ich zu den wichtigsten Dingen. Ich arbeite sehr viel mit Frames. Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

[rollstuhlfahrer]

Zitat:

Zitat von bernau (Beitrag 1101778)

Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

Eine Undo-Funktion für visuelle Komponenten.

Bernhard

[Codewalker]

Sammel das hier eigentlich jemand?

Aber wo wir gerade bei Frames sind: Ich bin auf TJvEmbeddedFormLinks ausgewichen, weil man Frames nicht von etwas anderes als TFrame ableiten kann (also keine gemeinsame Elternklasse). Das geht nur bis zum nächsten Neustart der IDE gut, dann meckert sie über fehlende Properties, weil sie versucht es als TForm zu interpretieren. :wall:

Zitat:

Zitat von himitsu (Beitrag 1101774)

Aber nur, wenn als Erweiterung des

Delphi-Quellcode:

:=

, also nur für Zuweisungen
und blos nicht innerhlab von IFs und Co. :wall:

Das wäre dann sogar halbwergs kompatibel zur

Delphi-Quellcode:

:=

-Syntax
[:+-*/]=

Genau das meinte ich auch nur. Zuweisungen in IFs und Co. sind ja in der Delphi-Sprache bisher sowieso nicht vorgesehen (zum Glück)

Zitat:

Zitat von himitsu (Beitrag 1101774)

Über Record-Operatoren für "Standard"-Typen, könnte man die Multi-Events für OnXYZ leicht nachbauen.

Wenn das so ist, wann legst du los und wie kann man dir helfen? :mrgreen:

[Neutral General]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1101781)

Zitat:

Zitat von bernau (Beitrag 1101778)

Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

Eine Undo-Funktion für visuelle Komponenten.

Bernhard

Ja! Unbedingt!

[nytaiceman]

Zitat:

Zitat von Neutral General (Beitrag 1101784)

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1101781)

Zitat:

Zitat von bernau (Beitrag 1101778)

Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

Eine Undo-Funktion für visuelle Komponenten.

Bernhard

Ja! Unbedingt!

Ja und ja und ja!

Ich als Profi-Anfänger ;-) wünschte mir zusätzlich folgende Dinge:

- Das die Delphi-Lizenz wieder als Datei abgelegt werden kann (Wie bei Delphi 2005)
- Das ich zwei (oder mehrere) Delphi Projekte parallel offen haben kann (Also zwei IDE gleichzeitig zum direkten Vergleich von Projekten)
- "irgendwie aufgeräumter" was .dcu, .bpl usw. (Suchpfade) angeht. Jedesmal wenn ich Jedi, Indy oder was auch immer aktualisiere, habe ich "Leichen" die stören.
- Mehr übersetzte Windows Header API (MSI, WIM etc.)

und:

Zitat:

by Codewalker
Ist mir doch gerade noch etwas aufgefallen, was fehlt: Der blöde E2195 muss weg, ich will endlich lokale Variablen initialisieren können. Compilermäßig dürfte das wenig Aufwand sein.

Zusätzlich zur Zukunftssicherung müssen die Gratisversionen attraktiver werden. Bei uns im Betrieb kennen die Auszubildenden "nur" Microsoft Visual Studio Express, die kommen gar nie auf die Idee, etwas mit Delphi zu machen. So schwinden von Jahr zu Jahr die möglichen Delphi-Interessenten!

[himitsu]

Zitat:

Das die Delphi-Lizenz wieder als Datei abgelegt werden kann

Ist immernoch möglich, nur daß Emba die .slip-Dateien sehr ungern rausgibt.
(vorallem da man diese ganz einfach weitergeben kann und jeder sich dann ohne Serverauthentifizierung beliebig viele Delphis aktivieren kann)

Zitat:

Das ich zwei (oder mehrere) Delphi Projekte parallel offen haben kann (Also zwei IDE gleichzeitig zum direkten Vergleich von Projekten)

die IDE mehrmals öffnen :stupid:
http://www.delphipraxis.net/160418-m...0-la-word.html

[stahli]

Zitat:

Zitat von NamenLozer (Beitrag 1101760)

Zitat:

Zitat von stahli (Beitrag 1101758)

- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel :wink:)

Ich glaube damit stehst du ziemlich allein. Warum sollte man das exakt selbe Feature doppelt implementieren? Bei den restlichen Punkten stimme ich dir aber weitestgehend zu.

Die Antwort findest Du dort.


[etwas OT, aber wenn man gefragt wird...]Wunsch: Julia sollte mich entgegen der Absprache doch anrufen. Traum: Sie sollte vor Oktober wieder kommen. Wahnvorstellung: Nee, sage ich nicht.[/etwas OT, aber wenn man gefragt wird...]

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1101839)

die IDE mehrmals öffnen :stupid:

Geht leider nicht, wenn GExprets installiert ist.

[mleyen]

Also bei mir gehts :gruebel:

[bernau]

Räusper.....

Habe die Fehlermeldung nie richtig gelesen, weil ich immer nur mit einer Instanz von Delphi arbeite(n möchte) und ein zweites Starten von Delphi immer nur ein Fehlklick gewesen war. Hab's noch mal durchgelesen. Und Ja, es ist keine Fehlermeldung, sondern nur ein Hinweis, daß die zuletzt geschlossene Instanz die Änderungen der vorherigen geschlossenen Instanz überschreibt. Ich stelle mich in die Ecke und schäme mich.