Inoffizielles deutsches Xbase-Forum

was auch sehr prickelnd ist, Das Programm wird mittendrin abgebrochen und die WB ist auch nicht mehr ansprechbar. Einfach nur in der Bedienung des Programmes, ohne überhaupt irgendwas im Debugger gemacht zu haben.

Manfred hat geschrieben: ↑Do, 12. Okt 2023 13:49 hier mal ein Dir als grobe Orientierung
...

128 Dateien mit insgesamt 12,3MB PRG Code? Und das ist das Projekt. Eine EXE?
Sind Addons enthalten? Wenn ja, welche?

Grüße
Frank

da ist express++ mit drin und List&Label ansonsten nix. Ist aber noch ein CRT Programm mit grafischem Aufbau.Die fertige EXE ist knapp 41MB groß, nebst ein paar eigenen DLL

und wieder einen jetz habe ich es genau beobachtet. Der Breakpoint wurde angesprungen und hat das Programm gestoppt. Ich habe mit der Maus in die WB geklickt um es weiterzuführen. Dabei kam dann die Fehlermeldung. Ich bin der Meinung ich habe in einen leeren Bereich des Codes geklickt mit der Maus. Ging aber alles zu schnell. Und natürlich mal wieder mitten im wichten Prüfprozess und jetzt muß ich wieder mit dem taskmanager das Programm beenden und alles wieder von vorne anfangen.

und das kam, als ich das programm beendet habe und die WB auch beenden wollte. und das kam, nachdem ich mehrmals OK geklickt hatte

Ich kenne diese Fehlermeldung ansich davon, wenn ich die Workbench mit geladenem Projekt über Nacht offen lasse. Die Projekte liegen bei dem Kunden ja auf dem Server. Und irgend etwas passiert dann nachts, das am nächsten Tag beim ersten Mausklick oder sogar schon Mausover in die WB diese Meldungsarie erscheint. Ich tippe auf kurze Netzwerkunterbrechungen z. B. wegen des Backups o. ä. Aber das ist nur im Nebel stochern.

Seit der 1819 habe ich das aber oftmals auch bei einem gerade erst geöffneten Projekt. 1/2 Stunde auf, schließen, Fehlermeldungen ohne Ende, wie in diesen Situationen gewohnt nur Taskmanager möglich.

Ich hatte das nächtliche Problem schon mehrfach an Alaska geschickt, inkl. Screenshots und log. Die haben keine Ahnung, was das sein könnte.

Jan

Ich lasse nie was nächtlich offen, es sei denn, ich sitze davor, aber bekomme aber auch tagsüber solche Meldungen. Manchmal werden sie durch Änderungen innerhalb komplexer Verschachtelungen ausgelöst, was vermutlich daran liegt, dass vorübergehend eine ganz andere Struktur vorliegt (weil etwa durch das Entfernen einer Klammer oder einer Iterationsabschlussformel plötzlich Code zusammenzugehören scheint, der das eigentlich nicht tut). Ich habe aber noch nicht beobachtet, dass die Fehlermeldung irgendeinen Schaden zur Folge gehabt hätte.

Frank Grossheinrich hat geschrieben: ↑Do, 12. Okt 2023 11:31 Ich verstehe den Frust, dabei muss es aber nicht bleiben

Hallo Frank,

Ihr habt diverse Mails von mir mit ellenlangen Auflistungen von Problemen und Vorschlägen zur Workbench. Ich arbeite ja schon seit der 1,.82 mit VX (damals noch extrem Beta), und seit den ersten lauffähigen Betas der 2.0 mit der Workbench (die 2.0 zur Devcon in Hannover habt Ihr auf meinem Rechner ja nie zum laufen bekommen). Ich bin überzeugter Fan der Workbench und hatte auf dem Forentreffen in Stuttgart auch mal eine Session darüber gemacht (mit einer für mich fiesen Frage von Tom , die zum Glück von Hubert schnell beantwortet werden konnte). Aber irgend wann hat Euch nicht mehr interessiert was ich da schreibe. Und mir erklärt das Ihr immer thematisch sammelt, und die Workbench sei aktuell einfach noch nicht dran wieder angefasst zu werden. Was inzwischen geschätzte vier oder fünf Jahre her ist. Seither tut sich gefühlt gar nichts mehr.

Jan

Frank Grossheinrich hat geschrieben: ↑Do, 12. Okt 2023 11:31 Hallo Manfred,



was bedeutet das alles? Laut deinem Titel sprichst du über Build 1819. Das macht Probleme?
Weiter verstehe ich, dass du es auch mit dem aktuelle Build 1948 versucht hast und hast da auch Probleme?
Definiere großes Projekt. Wie kann ich sehen, dass Breakpoints nicht mehr funktionieren, denn bei mir funktionieren sie.
Weiß unsere Support schon davon? Hast du es meinen Kollegen gesagt?

Auch wir wollen ja eine funktionierende WB. Wir setzen sie täglich von morgens bis abends ein.
Ich verstehe den Frust, dabei muss es aber nicht bleiben

Grüße
Frank

Hm, man könnte den letzten Satz jetzt so interpretieren, das Du das Verständnis für meinen Frust ablegen wirst?

Hm, man könnte den letzten Satz jetzt so interpretieren, das Du das Verständnis für meinen Frust ablegen wirst?

Das ist ganz eindeutig anders gemeint gewesen. Die Ursache für den Frust muss (und wird?) nicht bleiben.
Du bekommst eine einseitige Subskriptionskündigung.

(Just kiddin'. )

Servus,

kann leider alles von Manfred bestätigen - mit der Version 1741. Deshalb hab ich einen komplett neu in Xbase++ ausgebildeten 20jährigen Mitarbeiter verloren.

Er wollte wieder ausschließlich mit Visual Studio arbeiten, das bietet extrem viel mehr Möglichkeiten und stürzt nicht ständig beim Debuggen ab.

Übrigens: Ich kann nur empfehlen, ausschließlich mit der Workbench zu debuggen, alles andere ist umständlich und eingeschränkt.

und wieder so ein Mist beim Debuggen im Einzelschrittmodus. und man kommt zum Verrecken nicht mehr raus und muß somit über den Taskmanager die WB abbrechen.
Und fängt wieder von vorne an. Prima Tool, wirklich Klasse.

und das schlimmste ist, wenn man zwischendurch Breakpoints gesetzt hat, die sind dann alle weg.

Deswegen habe ich mir schon angewöhnt, vor dem Debuggen erst mal alles zu speichern.

öhm, dazu muß man aber die WB schließen. Die breakpoints werden nur dann gespeichert. Und das fände ich wirklich sehr blöde....
Zumal in diesem Falle die WB gerade neu gestartet wurde.

also ich drücke mich jetzt ganz höflich aus. Ich bin ein wenig verärgert. Die neue WB macht immer noch den Ärger mit dem Debugger. Ich habe eine zeitlang damit gearbeitet und plötzlich klappt der Debugger nicht mehr. Das Programm als solches klappt ohne WB gestartet, aber sobal die WB im Spiel ist und ich im Einzelschrittmodus stehe, hängt sie sich weg. Wenn ich im Debugger sage, er soll direkt bei der ersten Möglichkeit stehen bleiben, also Programmstart m. INIT Proceduren bleibt der Debugger irgendwo stehen, man sieht aber nicht wo und kann nichts mehr machen. Bricht man ab und startet den Vorgang neu, dann hängt sich die WB auf. Es ist zum

Nur mal so ins Blaue: Du nutzt doch zahlreiche Zusatzbibliotheken. Wenn Du Debuggen willst, kompilierst Du ja mit dem Schalter DEBUG = YES
Nutzt du denn von allen Zusatzbibliotheken dann auch die jeweilige lib mit den enthaltenen Debuginformationen?

Viele Grüße,
Martin

die Version läuft eine gewisse Zeit und dann kackt sie ab. Keine Ahnung warum ich habe alles rundherum schonmal neu kompiliert. Als einfache EXE klappt sie auch, nur über die WB mit dem Debugger läuft dann nichts mehr.

Hallo Manfred,

mit der 1976 habe ich (bis auf die schon diskutierte Blockmarkierung) nicht mehr Probleme als vorher.

Ich debug die INIT nie mit, aber ich hab eben mal die Option eingechaltet. Kein Problem.

Jan

so wie ich das jetzt sehe, hängt die WB sich in der Errorsys auf. Da der Debugger aber nichts anzeigt kann ich auch nicht sehen, wo er sich aufhängt. Mal sehen ob ich mit dem xppdbg weiter komme.

Hast Du die Standard-errorlog drin, oder deine eigene? Wenn Deine eigene: Was ist wenn Du die mal raus nimmst?

Jan

der xppdbg läuft einwandfrei durch. ich denke in dem und in der WB steckt das gleich unter der Haube?

also den Scheiß muß jetzt keiner verstehen. Sobald ich einen breakpoint setze in der WB und dann starte, hängt die sich weg. Ohne den überhaupt erreicht zu haben. Es gibt direkt Ärger kurz nach dem Start. Was soll denn der Mist? Das aber jetzt auch schon bei einer älteren WB version.

da hat sich irgendwas zerschossen. Wenn ich das gleiche Projekt auf einem anderen rechner laufen lasse, dann gibt es keine Probleme mit dem Debugger

jetzt habe ich den anderen PC auch auf die neueste version hochgezogen und er macht jetzt den gleichen Mist.