Version 1819

[Manfred]

und selbst wenn ich ein Altd() einbaue, bleibt der auch nicht stehen.

[Manfred]

aber davon ab, der Xppdbg bleibt auch bei einem altd() nicht stehen. Einzelschritt usw. klappt. Also ist alles eingebunden.

[Jan]

Vielleicht solltest Du mal mit einem der Rechner zu Alaska fahren, damit die den als Gesamtpaket untersuchen können.

Jan

[Manfred]

da ist irgendwas anderes faul. Ich habe jetzt mal andere projekte genommen und da klappt alles einwandfrei. Neu kompiliert. Debugger mit Breakpoints klappt und mit altd().

[Manfred]

es klappt wieder. Fragt mich aber derzeit nicht woran es wirklich lag, bzw. wie es dazu kommen konnte. Keine Ahnung.

[Tom]

Wir sind mithin bei Build 1976. Wäre es nicht an der Zeit, entweder den Thread neu zu betiteln oder einen neuen zu eröffnen?

[Manfred]

es ging ja eigentlich genau um die Version, weil ab da/danach die Probleme angefangen haben.
Warten wir mal ab, ob noch weiter was passiert. Ich habe jetzt mal alles auf die aktuelle version upgedatet

[Frank Grossheinrich]

Zur Information: Manfred war so nett (DANKE dafür) mal seinen Stoff zusammenzupacken und hat ihn mir/uns zur Verfügung gestellt. Ich werde mich heute damit auseinandersetzen und dann schauen wir weiter.

Gruß
Frank

[Manfred]

also bei dem letzten Problem mit dem Debugger, hat sich tatsächlich eine ältere DLL im Programmverzeichnis verirrt. Was mich aber auch wieder verwirrt hat, weil es zwischendurch trotzdem mal geklappt hat. Naja, weiß der Teufel, welcher Detail da wieder wo drin steckte. Das ist mir aber erst aufgefallen nach genauerem Hinsehen. Die anderen Programmverzeichnisse in meiner Testumgebung werden aus dem Grundsystem von Xbase++ gespeist, welches in die Systemumgebung bei der Installation eingetragen ist. Das besagte Programm ist aber auch das einzige, was mit eigenen DLLs gearbeitet hat. Das habe ich jetzt aber auch umgestellt.

[Manfred]

Zur Information: Manfred war so nett (DANKE dafür) mal seinen Stoff zusammenzupacken und hat ihn mir/uns zur Verfügung gestellt. Ich werde mich heute damit auseinandersetzen und dann schauen wir weiter.

Gruß
Frank

Sieht nach Hochwasser aus, so lang wie der Schauer anhält. Oder ist es der, der über den Rücken läuft?

[Tom]

Ich bin mit dem Alaska-Support auch in Sachen Workbench unterwegs. Ich glaube, die macht denen gerade ziemlich viel Arbeit.

[Manfred]

kann ich gut verstehen. Ich habe gerade das Problem, das es Fehler im Code gibt, die WB aber beim Compilieren an total anderer Stelle meckert. Sehr hilfreich.

[Tom]

das es Fehler im Code gibt, die WB aber beim Compilieren an total anderer Stelle meckert.

Vielleicht sind es ja auch mehrere Fehler?

[Manfred]

nein, so schlau war ich auch schon.

[Tom]

Ich kann jedenfalls kein grundsätzliches Fehlverhalten erkennen (2.00.1976). Großes Projekt, viele Dutzend Quellcodedateien, WB springt zum (bei mehreren: ersten) Fehler in der richtigen PRG.

[Manfred]

ich weiß, das ist ja das Problem. Deshalb findet Alaska ja auch den/die Fehler bei meinem Projekt nicht. Da gibt es wohl irgendeine Kombination, die so nur selten auftritt und deshalb schlecht gefunden werden kann.

[Tom]

Ich hatte nach den letzten Updates größere Probleme mit Markierungen und mit dem Löschen von senkrechten Markierungen. Nach Input vom Support half das Löschen der Registrygruppe für die Workbench. Nachteil: Alle individuellen Einstellungen wech.

[Jan]

Das der Compiler an falschen Stellen meckert habe ich auch ab und an. Es gibt Fehler, die sich anscheinend nach Compilerlogik nicht an Ort und Stelle bemerkbar machen, sondern erst bei anderen Strukturen. Beispiel: Ich vergesse irgend wo eine IF-Schleife zu schließen. Dann habe ich das ab und an mal das der den Fehler in der Funktion danach moniert, weil da plötzlich ein FUNCTION irgendwas mitten in der Schleife auftauchen soll. Hatte ich gerade diese Woche erst wieder gehabt.

Sehr beliegt auch, wenn ich bei umgebrochenen Codezeilen ein Komma vergesse und nur das Semikolon schreibe. Das wird oftmals auch erst sehr viel weiter unten moniert.

Nicht zu vergessen das von mir bei Alaska schon mehrfach und seit Jahren monierte Exit-Problem. Will ich auf eine Funktion springen, und es gibt in der Funktion darüber ein Exit, dann springt der Cursor zu diesem Exit und nicht zu der gesuchten Funktion.

Also mehrere Schwächen in der Workbench und im Compiler, die zu enormen Verwirrungen führen können. Und zu ausgedehnten Fehlersuchen, weil man an den falschen Stellen sucht

Jan

[Wolfgang Ciriack]

Ich hatte nach den letzten Updates größere Probleme mit Markierungen und mit dem Löschen von senkrechten Markierungen. Nach Input vom Support half das Löschen der Registrygruppe für die Workbench. Nachteil: Alle individuellen Einstellungen wech.

Konnte der Support nicht sagen, welcher Eintrag für das fehlerhafte Löschen der Spaltenmarkieren verantwortlich ist ?
Das Problem habe ich nämlich auch.

[Tom]

Konnte der Support nicht sagen, welcher Eintrag für das fehlerhafte Löschen der Spaltenmarkieren verantwortlich ist ?

Nein, leider nicht. Es gab mehrere Probleme - senkrecht markierte Blöcke haben eine Spalte zu viel gelöscht, Markierungen (Doppelklick) nahmen Satzzeichen und Anführungszeichen mit und dann noch die Sache mit den Geistermarkierungen (Markierungen bleiben, bis man sie außer Sicht scrollt). Letzteres geht nicht ganz weg, die beiden erstgenannten schon, aber welcher Key das im einzelnen gelöst hat, konnten sie mir nicht sagen. Ich habe halt Screenshots von allen Einstellungen gemacht und das danach wieder instandgesetzt. Auslöser ist also nicht irgendeine Einstellung, sondern irgendein Legacy-Ding in der Registry.

[Manfred]

Geistermarkierungen, da habe ich auch so meine Erfahrung mit gemacht.

[nightcrawler]

In anderen Programmierumgebungen ist es bei manchen (Quelle: andere Foren) schon vorgekommen, dass die Zeilenumbrüche falsch waren und deshalb die Debugger durchdrehten. Der Compiler hat es geschluckt.
Falls Du die Möglichkeit hast, prüfe mal auf Linux Zeilenumbrüche (0x0A) und ersetze diese durch Windows (0x0D 0x0A).

[Jan]

Nicht zu vergessen das von mir bei Alaska schon mehrfach und seit Jahren monierte Exit-Problem. Will ich auf eine Funktion springen, und es gibt in der Funktion darüber ein Exit, dann springt der Cursor zu diesem Exit und nicht zu der gesuchten Funktion.

I break together. Alaska hat den PDR 7298 vom 19.06.2020 tatsächlich mit Datum gestern geschlossen. Mit dem Update diese Woche sollte das Problem also endlich wohl erledigt sein. Ist aber auch das einzige Problem mit der Workbench, das behoben wurde.

Jan

[brandelh]

Alaska PDR 7298:

Code: Alles auswählen

=============== snip ================
FUNCTION A
   C()
RETURN NIL

PROCEDURE B()
   RETURN
   Exit
RETURN

PROCEDURE C()
RETURN
=============== snap ================

The above code cannot be compiled, but is valid to demonstrate the
problem.

Solution:
No Workaround for this problem known!

ähm, "no workaround" ... wie wäre es mit löschen dieses EXIT Statements ?
Übersehe ich da was ?

[Manfred]

das beispiel ist evtl. etwas zu trivial gewählt und soll nur der Anschaung dienen. Es geht um das EXIT als solches, wenn ich recht erinnere.