XE6: Hauptfenster startet nicht



  • audacia schrieb:

    asc schrieb:

    Wir werden keine Updates mehr machen, wenn nicht eindeutige Verbesserungen in der IDE oder ein Austausch des bcc32 erfolgt ist.

    So halte ich es auch, wobei ich noch "Bugfixes für die VCL" hinzufügen würde. Immerhin, die Ribbon-Komponenten haben in XE5 oder XE6 mal eine Runde Fixes abbekommen...

    Für uns eher nebensächlich, da wir sehr stark auf die DevExpress-Componenten setzen. Und was Bugfixes für die VCL angeht: Sie haben den ein oder anderen Bug-Eintrag ignoriert, so das wir in wenigen Codestellen auch an der VCL gebastelt haben.

    audacia schrieb:

    Aber immerhin, habt ihr die Code-Navigationsfeatures in XE7 gesehen?
    http://docwiki.embarcadero.com/RADStudio/XE7/en/Find_Definitions_and_References_(C%2B%2B)#Find_Menu_Commands
    Das geht doch schon in die richtige Richtung.

    Nach meiner Erfahrung funktionieren die Code bezogenen Features häufig nur unter Delphi sauber. Umstieg auf Delphi wäre für mich aber tatsächlich ein Kündigungsgrund, der Sprache ziehe ich viele Andere vor.



  • ich habe das Problem wieder. Auch ein Neustart des BCB hilft nicht weiter. Ich hab auch den Rechner neugestartet. Jemand eine Idee?
    Ich erhalte beim kompilieren immer wieder die Meldung:

    [ilink32 Fehler] Fatal .\Win32\Debug\Messapp.exe konnte nicht geöffnet werden (wird das Programm noch ausgeführt?)
    

    Ein Neustarten des C++Builders bringt nichts.

    Erstelle ich eine neue leere VCL-Anwendung funktioniert diese.



  • asc schrieb:

    audacia schrieb:

    Aber immerhin, habt ihr die Code-Navigationsfeatures in XE7 gesehen?
    http://docwiki.embarcadero.com/RADStudio/XE7/en/Find_Definitions_and_References_(C%2B%2B)#Find_Menu_Commands
    Das geht doch schon in die richtige Richtung.

    Nach meiner Erfahrung funktionieren die Code bezogenen Features häufig nur unter Delphi sauber.

    Diese Features gibt es (noch) nicht für Delphi. Sie sind Clang-basiert und nur für C++Builder.

    asc schrieb:

    Umstieg auf Delphi wäre für mich aber tatsächlich ein Kündigungsgrund, der Sprache ziehe ich viele Andere vor.

    Ist jetzt arg off-topic, aber das würde mich interessieren. Ich kann ja verstehen, wenn jemand die Syntax nicht mag, aber was könnte sonst gegen Delphi einzuwenden sein? Ist doch auch nichts anderes als C# in etwas altmodisch, mit begin/end und in einigen Dingen sogar etwas schöner (wie z.B. die Deklaration von Enums und Sets)?

    rudpower schrieb:

    ich habe das Problem wieder. Auch ein Neustart des BCB hilft nicht weiter. Ich hab auch den Rechner neugestartet. Jemand eine Idee?

    Sorry, das ist nicht nett, daß wir deinen Thread hijacken. Ich finde die Nebendiskussion interessant und würde sie gerne verfolgen, aber vielleicht nicht hier. Könnte ein Moderator die entsprechenden Postings abspalten (wenn das Forum sowas kann)?

    Dein Problem kenne ich, aber es tritt bei mir nur extrem selten auf. Aber das hier wundert mich:

    rudpower schrieb:

    Im Windows Task-Manager taucht der Prozess Messapp.exe *32 auch in der Liste der Prozesse auf. Mit "Prozess beenden" lässt sich der Prozess leider nicht aus der Liste löschen.
    Ein Neustart des C++Builders hilft auch nicht.

    Das heißt, daß irgendein Prozeß noch ein Handle von deiner Anwendung offen hat. Und wenn du den C++Builder ordentlich neugestartet hast, kann der es eigentlich nicht sein. (Wenn du ihn beendest, sind dann alle bds.exe -Prozesse im Taskmanager verschwunden?)

    Wenn das wirklich so ist, dann würde ich vermuten, daß irgendeine Drittsoftware hier reinpfuscht. Hast du irgendwelche Logitech-Maustreiber installiert? Da gab es mal eine Inkompatibilität mit dem C++Builder-Debugger.

    Zur weiteren Diagnose solltest du jedenfalls mal den Process Explorer (-> sysinternals.com) starten, damit kann man feststellen, wer noch ein Handle von deinem Prozeß offen hat (über "Find|Find Handle or DLL...").



  • audacia schrieb:

    ...
    Ich kann ja verstehen, wenn jemand die Syntax nicht mag, aber was könnte sonst gegen Delphi einzuwenden sein? Ist doch auch nichts anderes als C# in etwas altmodisch, mit begin/end und in einigen Dingen sogar etwas schöner (wie z.B. die Deklaration von Enums und Sets)?
    ...

    Naja, Delphi hat z.B. keine automatische Speicherfreigabe wie C#. Ich persönlich finde das nicht sooo immens wichtig, aber so etwas wie ein auto_ptr oder shared_ptr aus C++ vermisse ich da schon 😉



  • audacia schrieb:

    asc schrieb:

    Umstieg auf Delphi wäre für mich aber tatsächlich ein Kündigungsgrund, der Sprache ziehe ich viele Andere vor.

    Ist jetzt arg off-topic, aber das würde mich interessieren. Ich kann ja verstehen, wenn jemand die Syntax nicht mag, aber was könnte sonst gegen Delphi einzuwenden sein? Ist doch auch nichts anderes als C# in etwas altmodisch...

    Gegenfrage: wenn du zwei Wege vor dir hast, der eine voller Schlamm und Dornen, der andere trocken und gut gepflegt: Wählst du dann wirklich den ersten? Ich habe fest gestellt, das es für die Motivation durchaus entscheidend sein kann, das man wenn man die Auswahl hat die Anzahl der Dinge gering zu halten, an denen man keinen Spaß hat, davon gibt es im Arbeitsleben ohnehin schon genügend.

    Delphi (und einst auch Pascal) habe ich nur ganz zu Beginn etwas abgewinnen können. Ich finde die Sprache unübersichtlich und unleserlich, zudem "bringt" mir die Sprache keine Vorteile für die Zukunft. Ich sehe Delphi jedenfalls nicht als Zukunftsweisend an.



  • ich habe mir den Process Explorer mal runtergeladen und gestartet. Auch dort kann ich den Prozess nicht beenden. In der Process Explorer Search gibt es eine dll. Diese ist im Debug-Ordner. Eine Logitech-Maus oder Tastatur hab ich nicht

    Der Fehler tritt nun laufend auf. Ich kann gar nicht mehr kompilieren, da die exe schon geöffnet ist. Auch ein Neustart des Rechners löst das Problem nicht.

    Ein Handle zeigt der Process Explorer nicht an. Nur halt mehrere Files und die verwendete dll, die sich im Debug Ordner befindet.



  • rudpower schrieb:

    ...

    Vielleicht weit hergeholt: Defekte Datei bzw. Fehler bei den Zugriffsrechten im Verzeichnis (Datei nicht ersetzbar)?



  • rudpower schrieb:

    In der Process Explorer Search gibt es eine dll.

    ?? Wonach hast du denn gesucht?

    rudpower schrieb:

    Ein Handle zeigt der Process Explorer nicht an. Nur halt mehrere Files und die verwendete dll, die sich im Debug Ordner befindet.

    Dann machst du was anderes, als was ich erwartet habe.

    Praktisches Beispiel: der Internet-Explorer benutzt einen Parent-Prozeß und mehrere Child-Prozesse (für die Plugins und für Tab-Gruppierungen). Natürlich hat der Parent-Prozeß Handles von allen Child-Prozessen, weil er sie ja bei Bedarf beenden können muß. Um das mit dem Process Explorer festzustellen, gibst du die PID eines Child-Prozesses in das Suchfenster ein. Im Suchergebnis ist u.a. der Parent-Prozeß, der ein Prozeß-Handle (in der "Type"-Spalte steht "Process") des Child-Prozesses offen hat. Sieht so aus:
    https://www.dropbox.com/s/2izlsmqcjcxu2qg/procexp-find-process.png?dl=0

    Und jetzt öffnest du den C++Builder, startest das Programm einmal im Debugger. Nach deiner Beschreibung bleibt der Prozeß dann bestehen, auch wenn du den C++Builder beendest. Verifiziere beides mit dem Process Explorer (also daß dein Prozeß noch läuft, bds.exe aber nicht mehr). Und dann gibst du mal die PID oder den Namen deines immer noch laufenden Prozesses ins Suchfenster und schaust, ob davon nicht jemand ein Prozeß-Handle offen hat.



  • asc schrieb:

    Gegenfrage: wenn du zwei Wege vor dir hast, der eine voller Schlamm und Dornen, der andere trocken und gut gepflegt: Wählst du dann wirklich den ersten?

    Den, der dorthin führt, wo ich hinwill.

    Eigenartige Frage. Vielleicht haben C# und Delphi ja verschiedene Einsatzgebiete?

    asc schrieb:

    Ich habe fest gestellt, das es für die Motivation durchaus entscheidend sein kann, das man wenn man die Auswahl hat die Anzahl der Dinge gering zu halten, an denen man keinen Spaß hat, davon gibt es im Arbeitsleben ohnehin schon genügend.

    Du mußt dich nicht dafür rechtfertigen, daß du unangenehme Tätigkeiten vermeiden willst. Ich habe nur gefragt, warum es für dich unangenehm ist.

    asc schrieb:

    Ich finde die Sprache unübersichtlich und unleserlich

    Nur syntaktisch jetzt? Also and , or , begin , end statt && , || , { , } ? Ansonsten bitte mal konkreter.



  • asc schrieb:

    ... Ich finde die Sprache unübersichtlich und unleserlich,...

    Da ist C/C++ m.E. teilweise noch viel unleserlicher, man schaue sich z.B. nur mal die Quelltexte der std templates an. 😉

    Es ist nun mal so, das man mit dem am besten klar kommt, was man gewohnt ist. Ich habe z.B. lange gebraucht, um einen Sinn auf den Umstieg von Tubo PAscal auf C/C++ zu sehen. Der kam eigentlich erst, als ich feststellte, das Borland C++ damals schnelleren Code erzeugte als Turbo Pascal. Und so nach und nach habe ich dann auch die Features von C/C++ entdeckt und dies ist heute meine bevorzugte Sprache.

    Das ist natürlich schon > 20 Jahre her.



  • Burkhi schrieb:

    asc schrieb:

    ... Ich finde die Sprache unübersichtlich und unleserlich,...

    Da ist C/C++ m.E. teilweise noch viel unleserlicher, man schaue sich z.B. nur mal die Quelltexte der std templates an. 😉

    Es ist nun mal so, das man mit dem am besten klar kommt, was man gewohnt ist. Ich habe z.B. lange gebraucht, um einen Sinn auf den Umstieg von Tubo PAscal auf C/C++ zu sehen. Der kam eigentlich erst, als ich feststellte, das Borland C++ damals schnelleren Code erzeugte als Turbo Pascal. Und so nach und nach habe ich dann auch die Features von C/C++ entdeckt und dies ist heute meine bevorzugte Sprache.

    Das ist natürlich schon > 20 Jahre her.

    Mach C oder C++, aber mische nicht. Wenn Du C/C++ machst, dann wundert es keinen Profi, daß es "teilweise noch viel unleserlicher" ist.



  • volkard schrieb:

    ...
    Mach C oder C++, aber mische nicht. Wenn Du C/C++ machst, dann wundert es keinen Profi, daß es "teilweise noch viel unleserlicher" ist.

    Mach ich auch 😉 . ich wollte damit nur ausdrücken, das C oder C++ Quelltext auch für sich unleserlich sein kann. Unleserliche Programme bekommt man übrigens mit genügend willen 😃 in jeder Programmiersprache hin. 😉



  • Burkhi schrieb:

    Da ist C/C++ m.E. teilweise noch viel unleserlicher, man schaue sich z.B. nur mal die Quelltexte der std templates an. 😉

    Ich finde C++/Java und C# jedenfalls angenehmer vom Lesen her, und das obwohl ich mit C++ erst nach Pascal (und zuvor GFA-Basic) angefangen habe, und anfangs (wenn auch nicht allzu lange) die Sprache auch gut fand. Mehr brauche ich dazu auch nicht zu sagen - im Gegensatz zu Beispielsweise Java, bei dem ich einen WG-Mitbewohner einmal bei der Fehlersuche geholfen hatte bevor ich selbige Sprache erlernt hatte, habe ich Schwierigkeiten mit dem Lesen von Delphi-Code.

    Mehr ist hierzu aus meiner Sicht nicht zu sagen. Delphi finde ich genauso unleserlich wie Visual Basic. C++ ist sicherlich nicht das Optimum von Lesbarkeit, wobei es durchaus lesbar geschrieben werden kann, doch finde ich den "Grundaufbau" besser.



  • asc schrieb:

    Delphi finde ich genauso unleserlich wie Visual Basic.

    Nicht, wenn man sich dran gewöhnt hat. Hab früher jahrelang Delphi programmiert und fands viel leserlicher als Visual Basic. Jetzt hab ich das schon ewig nicht mehr programmiert und finds auch nicht mehr so toll. Aber immer noch viel besser als VB 😉



  • asc schrieb:

    Mehr brauche ich dazu auch nicht zu sagen

    Nein, natürlich nicht. Mich haben nur die Details interessiert, weil heftige Abwehrreaktionen ("Kündigungsgrund") nach meiner Erfahrung selten rationale Gründe haben. Meistens hört man dann "ist halt so" oder "die Details sind unwichtig; geh doch weg!!1" 🙂

    Unabhängig davon, was man von Delphi hält, die Arbeit mit RTL, VCL und FireMonkey aus Delphi nicht nur komfortabler (bessere IDE-Unterstützung), sondern auch viel irritationsärmer, weil diese Bibliotheken eng mit den Spracheigenschaften von Delphi verbunden sind. C++Builder ist ein sehr nützliches Werkzeug, wenn man Interop-Anforderungen mit bestehendem C++-Code hat, aber in C++Builder ist man als gelernter C++-Programmierer immer den Delphi-spezifischen Widernatürlichkeiten ausgesetzt:

    • Bifurkation der Objektmodelle ( TObject vs. alles andere) inklusive Abweichungen in der Konstruktions-/Destruktionsreihenfolge
    • keine Delphi-Klassen auf dem Stack
    • Ambiguität bei abstrakten Klassen, die auch als Interface-Typen benutzt werden können
    • RTTI (aber nur für bestimmte Typen in bestimmten Klassen)
    • untypische Spracherweiterungen wie __closure oder __property
    • unvollständig unterstützte Delphi-Sprachfeatures wie Metaklassen
    • auf mobilen Plattformen automatisches Lifetime-Management, wo man es nicht erwartet (d.h. manche Zeigertypen sind insgeheim Smartpointer)
    • ...

    Das hat ja alles seine Rechtfertigung, aber es ist einiges an zusätzlicher Komplexität, und nicht vielen gelingt es, dann noch sauber zwischen dem C++Builder-Dialekt und regulärem C++ zu trennen. Wäre es da nicht besser, man würde den Code, der mit den Delphi-Frameworks interagiert, soweit als möglich in Delphi schreiben, wo diese Eigenschaften natürlicher Bestandteil der Sprache sind?

    Ich sehe das analog zu C# und C++/CLI. Letzteres ist sehr nützlich, wenn man mit C++-Code interagieren will, aber egal ob man C# mag oder nicht, erspart man sich doch viel Aufwand und Irritationen, wenn man die managed only-Teile seiner Anwendung in C# schreibt. In C++/CLI muß man immer darüber nachdenken, ob man jetzt gcnew oder new (oder, Gott bewahre, ref new ) schreibt, ob man da ein Template oder ein generic benutzt, oder warum manche Typen nicht als Felder in manchen Klassen benutzt werden können. Und dann ist da noch die zusätzliche Komplexität, die sich durch das abweichende Laufzeitmodell ergibt (z.B. statische Variablen in C++/CLI-DLLs garantieren tagelanges Vergnügen bei der Fehlersuche).

    (Weil das auch Microsoft so sieht, ist übrigens /clr:pure ab dem kommenden VC++ deprecated.)


Anmelden zum Antworten