Zufriedenheit mit der Workbench

[Tom]

Hallo, Jan.

Sondern mach einfach einen Doppelklick auf die gesuchte Datei links im Projektmanager.

Ja, das mache ich natürlich auch. Und ich denke dabei an den Kumpel vor zwanzig, dreißig Jahren, der ein Auto hatte, das kurz vor dem Auseinanderfallen war (ein Ford Irgendwas), und mit dem man einfach keine scharfen Rechtskurven mehr fahren konnte, deshalb ist der Kumpel mit dieser Karre lieber dreimal nach links abgebogen als einmal nach rechts, und zwar keineswegs im sprichwörtlichen Sinn. Ich habe mich natürlich auch arrangiert und organisiert, aber ich wäre einen deutlichen Zacken produktiver, wenn ich nicht dreimal nach links abbiegen müsste, um einmal nach rechts zu kommen. Do you know what I mean?

[Manfred]

oder F5. Wobei setzen oft einfache ist als löschen. Da muß man dann in der Breakpointliste herumlatschen.

PS:Oh, Tom war schneller. (Hoffentlich nicht einsamer)

[Jan]

I knwo what you mean. Und ich bin absolut auf Deiner Seite damit.

Mir ging es nur darum klarzustellen, das diese Bedien-Mankos massiv lästig sind. Aber die Fehler und fehlenden Funktionen in meinen Augen viel schlimmer und schwerwiegender sind. Was sie in Deinem Beitrag dazu anders anhörte. Ich gestehe Dir ja (wie immer ) zu das Du anderer Meinung sein darfst und auch andere Prioriutäten haben darfst. Aber in meinen Augen ist das halt so das diese optischen Sachen schlimm, aber nicht so schlimm die die Funktionsprobleme sind.

Jan

[Jan]

Manfred,

oh ja, diese Breakpoints. Verschieben sich gerne mal zwischendurch auf Leerzeilen. Lassen sich nach Codeänderungen nicht an der gewünschten Stelle setzen (null Reaktion auf F5), außer man kompiliert vorher - was aber relativ neu ist seit ein oder zwei Jahren. Will man die um Bedingungen erweitern geht das nur über den sehr umständlichen Umweg über das Menü mit der Debug-Einstellung. Und manchmal hält der Debugger ums Verrecken nicht am Breakpoint an, so das ich da dann doch wieder ein AltD() setzen muß. Hab ich alles an Alaska geschickt. Und liegt dort weiterhin warm und trocken in der untersten Schublade.

Jan

[Tom]

Aber in meinen Augen ist das halt so das diese optischen Sachen schlimm, aber nicht so schlimm die die Funktionsprobleme sind.

Klar, dass das Ding Daten löscht, wenn man F3 drückt, das ist schon etwas, das mir ernsthaft Sorgen macht (und tatsächlich erzeugt nicht jede Löschung anschließend einen Syntaxfehler), oder diese Nummer, dass manchmal Fehlermeldungen kommen, wenn man Klammern löscht, die Workbench aber ohne Not weiterzuarbeiten scheint, da fallen mir beim Zuschauen nachgerade die Haare aus. Das sind Dinge, die korrigiert werden müssen.
Aber dass mich fünf Klicks kostet, was anderswo mit einem geht, oder dass ich verf*ckt noch eins nicht auf einen Blick sehen kann, was alles im Code geändert wurde, das hat so ein bisschen die Qualität des Nachbarn, aus dessen Wohnung es immer nach Fisch stinkt. Irgendwann entwickelt man den Wunsch, diesem Menschen etwas Böses angedeihen zu lassen. Vor allem, wenn es echt kein großes Problem wäre, mal die Fenster aufzureißen, bildlich gesprochen.

[Manfred]

also die Breakpoints verschieben sich natürlich, oder klappen nicht richtig, wenn man (mitten im Debuggen) den Code erweitert. Ich glaube zu dem Thema sagt Peter G. etwas auf der Entwicklerkonferenz.
@Tom,
sei froh, das der Nachbar das Fenster zu läßt. Wer weiß, was dann sonst nocht für Gerüche da heraus kommen....

[Jan]

Wenn man vom Teufel spricht ... Gerade hatte ich wieder das Phänomen das ich graue Haare bekomme weil die Breakpoints nichts stoppten. Also kontrolliert ob ich die an den richtigen Stellen gesetzt habe. Habe die alle raus genommen und neu gesetzt (hilft ja meistens). Neue gesetzt an Stellen, die garantiert durchlaufen werden. Nichts geholfen. Der stoppte einfach nicht.

Letzte Verzweiflungstat: Debuggee beenden. Workbench beenden. Workbench neu starten. Debuggee neu starten. Alles wieder gut. Hatte sich wohl intern irgend was verknotet.

jan

[Marcus Herz]

Hast du's gut. Bei mir hängt die sich so oft auf, dass ich über den Taskmanager killen muss. Und dann starte ich sie eh neu

[Jan]

Hallo Marcus,

ja, es gibt Tage da könnte ich die ganze Kiste an die Wand knallen. So viele Speicherfehler, wo dann jedes Mal nur noch der Taskmanager die Workbench beenden kann. Aber heute ist keiner solcher. Zum Glück.

Jan

[Armin]

Hallo Freunde der Workbench,

habe gerade heute seit langem etwas an unserem WAA-Projekt zu tun...

WAA ist nur sehr kompliziert mit der Workbench zu debuggen (und nur eine DLL). Deshalb nutze ich da noch xppdbg...
Dann von einem prg zum anderen wechseln und wieder zurück ist jedesmal aufregend...

Ich gehe schon soweit, dass wenn ich an einem prg arbeite und etwas in einem anderen nachschauen oder reinkopieren möchte, dann mache ich dieses mit notepad++ auf.

Klar gibt es da wahrscheinlich Tricks - aber wenn ich so selten damit arbeite, dann habe ich sie nicht unbedingt immer gleich parat.

Grüße,
Armin

[Tom]

Hallo, Armin.

Ich gehe schon soweit, dass wenn ich an einem prg arbeite und etwas in einem anderen nachschauen oder reinkopieren möchte, dann mache ich dieses mit notepad++ auf.

Ich würde sagen, dass diese Vorsicht etwas übertrieben ist. Man kann unproblematisch jede beliebige Datei (auch XML und so Zeug) in den Codeeditor ziehen/laden, ohne dass sich irgendwas am Projekt ändert. Man landet nur nach dem Schließen einer solchen Datei nicht wieder in derjenigen, die die zuvor zuletzt verwendete ist, das ist alles. Lässt man sie offen, wird sie in der nächsten Session mitgeöffnet, aber auch ohne Einfluss auf Projektdateien. Das funktioniert problemlos.

[Armin]

Hallo Tom,

ich habe da keine Angst, dass sich etwas ändert - d.h. es hat nichts mit Vorsicht zu tun. Nur das Wiederauffinden der prg, in der ich gerade arbeite ist etwas ungewohnt. Das Projekt besteht aus mehreren DLLs mit vielen prgs. Ich komme schon klar damit, aber wenn ich nach längerer Zeit wieder damit arbeite, dann stellt sich das Problem jedesmal wieder ein.

Grüße
Armin

[Tom]

Ah, verstehe. Ja, das ist nachvollziehbar.

[Manfred]

heute ist es wieder eine Katastrophe bei mir. Innerhalb weniger Minuten mehrmals total aufgehängt die WB beim Debuggen....

[Manfred]

Sorry, aber es ist einfach nur zum Kotzen mit der Arbeit damit derzeit. Andauernd stürzt das Teil ab beim Debuggen.

[RolandG]

Für die WB habe ich erst im letzten Jahr meine frühere Projekte-Struktur/Verwaltung umgestellt damit der Debuger und Editor alles finden konnte.
Aber auch nach meinen Projekte-Anpassungen debugge ich eigentlich nicht mal mit der WB, da für das (richtige?) debuggen auch der Editor wichtig ist mit dem man das steuert.
Ich habe zwar einige eigene EXE und DLL aber viele PRGs. Unterm Strich ist alles ein großes Projekt und hängt zusammen - da bringt mir schon der WB Projekt Manager nichts.
Gegenüber meiner bisherigen Arbeitsweise habe ich in der WB einfach noch nichts gefunden was mein Programmieren mit Xbase++ deutlich beschleunigen würde/könnte. Und nur weil es die WB gibt (und ich jedes Jahr bezahle) ist das kein Grund damit zu arbeiten. Von der WB habe ich mir viel mehr versprochen - aber vielleicht habe ich auch mit dem Umstieg zu viele Jahre (Jahrzehnte) gewartet.

Ich arbeite immer noch mit Multi-Edit, den habe ich früher mal optisch und funktionell umfangreich angepasst. Viele Farben, Schriftgröße, Fenster, Xbase++-Compilierung mit Error-Anzeige uvm.

Wünsche gäbe es viele...
Bei den heutigen großen Hauptspeichern wäre es prima wenn die WB sich vieles - z.B. meine PRGs + Includes - in den RAM ziehen würde. Da könnte man einiges beschleunigen. So muss ich auch mit der WB auf der HDD in den Dateien suchen (das machen anderen Editoren auch).

So gesehen gibt es für Xbase++ noch eine Menge anderer Dinge die mir viel wichtiger sind als die WB (die ist mir inzwischen egal - bis auf den Debugger)

[Tom]

Ich habe mich gerade wieder blödgeklickt, weil ich eine Markierung loswerden wollte. Und gestern musste ich wieder mal besonders viel mit Git spielen, weil ich Code durch die Suchen-Funktion versehentlich verändert hatte, die plötzlich zur Ersetzen-Funktion mutiert war. Glücklich, wenn man das bemerkt und viele Zwischenstände zum Vergleichen eingecheckt hatte. Pech, wenn das bis zum Kunden durchläuft.
Aber Frank und Till haben ja in Freiburg ausgeführt, dass die WB ein wichtiges Thema ist, das hohe Priorität hat (oder sie bald bekommt).

[Wolfgang Ciriack]

weil ich Code durch die Suchen-Funktion versehentlich verändert hatte, die plötzlich zur Ersetzen-Funktion mutiert war.

Das habe ich auch schon erlebt, ich dachte ich hätte mich "verdrückt".

[Manfred]

ich verstehe jetzt überhaupt nichts mehr. Gegeben ist ein xb.net Server, in dem ich oClient := threadobject() speichere. Sobald ich im Debugger Objektinspektor mir diese Instanz mit Inhalt anschauen möchte, hängt sich die WB total auf.

[Manfred]

man kann bei der WB schon fast ein System erkennen. Wenn ich eine Anwendung debugge, beende, verändere, neu kompiliere, oder einfach nur mehrmals den Debugvorgang nacheinander starte und beende, dann hängt die WB sich gnadenlos auf. Das ist zu über 90% reproduzierbar bei mir.

[Manfred]

ich bring das jetzt mal auch hier rein. Ich hatte die letzten Tage ein Problem, das es immer wieder Fehlermeldungen im Debugger gab, wenn ich ein Result von einem ADS abgerufen habe. Es wurde ein Feld angemeckert als unbekannt, was ich überhaupt nicht im Script stehen habe. Nachdem ich fast vom Teppichrand springen wollte, kam mir Marcus mit 2 weiteren Augen zur Hilfe und hat entdeckt, das ich überwachte Variablen oresult:diesesfeld stehen hatte. Da es das aber nicht gibt, kann der Debugger es auch nicht auswerten. Sowas ist mir vor längerer Zeit schonmal passiert. Ich hatte etliche Variablen in die Überwachung gestellt und beim Start des Programms waren die aber noch nicht bekannt. Also gab es jedesmal etliche Fehlermeldungen. Das hatte Alaska wohl irgendwann behoben. Deshalb kam ich erst überhaupt nicht auf die Idee in die Richtung zu forschen. Aber das war es denn.....

[Tom]

Heute ist wieder mal so ein Tag, an dem ich die ulkige Workbench hasse. Abgrundtief. Nicht nur, weil ich parallel mit VS Code gearbeitet habe, was sich anfühlt ,als würde man ständig zwischen einem Trabi und einem Ferrari umsteigen, sondern vor allem, weil die Suchenfunktion wieder minutenlang als Ersetzenfunktion hochstapelte. Dazu tonnenweise Geistermarkierungen. Oder es wurde nicht kopiert, was man markiert hatte, sondern nur Teile davon. Das ist ein Antiproduktivtool. (Und es macht mir Angst.)

[Manfred]

Tom, warum mußt Du auch immer wieder auf den Trabi zugreifen? Bleib doch bei der Workbench und gut iss.

[Tom]

Sagen wir's mal so. Ich würde meinen Arbeitsweg sogar freiwillig für ein Jahr lang mit dieser stinkenden und unbequemen Pappkarre absolvieren und währenddessen sogar die grausigen, ungefilterten Zweitakterabgase in den Innenraum leiten lassen, wenn die Workbench dafür zwei, drei Ticks komfortabler, zeitgemäßer und, vor allem, sicherer wäre.

(Edit. Ferrari baut keine Zweitakter, oder? )

(Editedit. Plse don't explain the joke. Thks.)