XE6: Hauptfenster startet nicht



  • wenn ich meine VCL-Anwendung mit F9 kompilieren lasse läuft die Komilierung und das Linken durch. Dann schliesst sich das kleine Fenster und das Ereignisprotokoll wird gefüllt. Nur das Hauptfenster meiner Anwendung startet nicht. In dem Ereignisprotokoll werden mehrere Module gestartet, Threads gestartet und wieder beendet.
    Die Anwendung scheint auch zu laufen, da das grüne Dreieck ausgegraut ist. Wenn ich dann mit Strg+F2 abbreche und erneut starte erhalte ich folgenden Linkerfehler:

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

    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.

    Erst wenn ich den Rechner neustarte bekomm ich wieder das anfängliche Verhalten.



  • zwischendurch ging es dann mal wieder und das Hauptfenster wurde wieder geöffnet. Fehlermeldungen erscheinen nicht. Jemand eine Idee?



  • Ich habe keinen XE6, doch beim XE4 habe ich das Verhalten auch immer mal wieder (in der Regel nach häufigen Debugging). Schließen/Neustarten des C++ Builders hilft dann meist.

    P.S: Wenn das nur meine einzigen Probleme mit dem RadStudio wären... Ich frage mich ob dort überhaupt einmal etwas bezüglich Stabilität gemacht wird.



  • Ich frage mich, wohin Embarcadero mit dem RAD Studio überhaupt will. Es erscheinen so gut wie keine Bugfixes, stattdessen gibt es jedes Jahr ein neues Major Release mit neuen Features (das man natürlich kaufen muss). Ich habe den Eindruck, dass (ähnlich wie bei Telefongesellschaften) Bestandskunden stiefmütterlich behandelt werden, die haben die Suite ja schließlich schon bezahlt. Vielmehr soll die Zielgruppe vergrößert werden, damit noch mehr Leute das Ding kaufen. Oberflächlich betrachtet ist das RAD Studio ja ganz gut, und auch die Feature Liste liest sich nicht schlecht. Einfache Fensteranwendungen sind ruck-zuck zusammengeklickt und ab dem Zeitpunkt, wo man sich über bestimmte Dinge nur noch aufregt kommt man davon nicht mehr weg, weil zu viel Code portiert werden müsste.



  • DocShoe schrieb:

    Es erscheinen so gut wie keine Bugfixes

    Nun doch, man zeigt ja immer gerne die Bugfix-Listen; aber für die Fixes muß man halt auch das nächste Release kaufen.

    DocShoe schrieb:

    Ich habe den Eindruck, dass (ähnlich wie bei Telefongesellschaften) Bestandskunden stiefmütterlich behandelt werden, die haben die Suite ja schließlich schon bezahlt. Vielmehr soll die Zielgruppe vergrößert werden, damit noch mehr Leute das Ding kaufen.

    Die allgemeine Hoffnung der geduldigen Nutzerschaft ist ja, daß nach Unterstützung von OS X, Android, iOS, 64-Bit-Windows, einem gescheiten C++-Compiler und, als letzten fehlenden Baustein, einem gescheiten Compiler auch für 32-Bit, der technologischen Rückstand so weit aufgeholt ist, daß Embarcadero wieder die Qualität verbessern kann. Aber das Management glaubt, daß sie eine Version mit "genau wie das letzte Release, nur mit weniger Bugs" nicht verkauft bekommen. Das ist auch, glaube ich, schon immer so gewesen, daß jede Version mit einer Handvoll Buzzword-Features rauskam, von denen dann die meisten nach zwei, drei Releases wieder versandeten. (Bei XE waren ja wider allgemeines Erwarten weder x64-Support noch Multiplatform-Unterstützung reif für die Auslieferung – es war ja noch vor dem Erwerb des FireMonkey-Vorläufers VGScene –, also haben sie so viele Bugfixes reingenommen wie möglich und dann diese ganzen Software-Bundlings mit Beyond Compare, AQtime, Final Builder etc. eingeführt, damit das Marketing auch was zu bewerben hat.)

    Die einzige realistische Hoffnung ist wohl, daß nach dem besagten Aufholen sich wenigstens so eine Art Gleichgewicht wiederherstellt.



  • audacia schrieb:

    DocShoe schrieb:

    Es erscheinen so gut wie keine Bugfixes

    Nun doch, man zeigt ja immer gerne die Bugfix-Listen; aber für die Fixes muß man halt auch das nächste Release kaufen.

    Und einige starke Bugs sind noch seit C++ Builder 6 Zeiten im Programm. Des weiteren sind die Updatepreise stark überzogen (Noch vor ich glaube 2 Jahren waren die beim C++ Builder akzeptabel).

    audacia schrieb:

    Die allgemeine Hoffnung der geduldigen Nutzerschaft ist ja, ...als letzten fehlenden Baustein, einem gescheiten Compiler auch für 32-Bit, der technologischen Rückstand so weit aufgeholt ist...

    Wir warten schon lange auf einen aktuellen 32-Bit Compiler, und der wird immer wieder geschoben. Wir werden keine Updates mehr machen, wenn nicht eindeutige Verbesserungen in der IDE oder ein Austausch des bcc32 erfolgt ist. Sollte sich Embarcadero noch viel Zeit lassen, wird für uns die Firma wohl Geschichte sein (Das Ziel ist ohnehin eine Wegmigration, die wäre auch schon im Gange wenn wir nicht aktuell permanent ausgelastet wären).



  • ich hatte gestern mehrmals immer wieder den Builder neugestartet aber dann konnte ich nicht mehr kompillieren weil der Prozess im Taskmanager noch offen war. Nur ein Neustart des Rechners schafft Abhilfe. Teilweise öffnet sich dann aber wieder das Hauptfenster nicht. Ich hatte gestern dann aufgegeben. Heute den Builder gestartet und kompiliert und siehe da es funktioniert wieder obwohl am Code nichts geändert wurde.



  • 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. Und das gerade zu der Zeit, als Microsoft XP auslaufen ließ, man also fortan gleich das systemeigene Scenic Ribbon verwenden kann, das ab Vista dabei ist, so daß es kaum noch einen Grund gibt, überhaupt das VCL-Ribbon zu benutzen 😞

    Was BCC angeht, so habe ich ein wenig resigniert und verwende meistenteils Visual C++. Für die VCL kenne ich nach wie vor keine ebenbürtige Alternative, aber wenn ich den Anwendungskern eh in eine DLL auslagern muß, kann ich für das UI auch Delphi nehmen; das ist dann wie C++Builder, nur viel angenehmer. Ein paar existierende C++Builder-Anwendungen habe ich aber noch, für deren Pflege wäre ein Clang-basierter BCC32 sehr nett.

    Hat jemand verfolgt, auf welcher Clang-Version die aktuellen Releases basieren? Ich hatte nämlich den Eindruck, daß sie immer noch auf ihrem privaten Fork von Clang 3.1 oder 3.3 festsitzen. Das ist ja langfristig auch nicht gut.

    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.



  • 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. 😉


Log in to reply