Überlappung mit Linie ...

[Jan Bochmann]

Guten Tag und Gesundes Neues Jahr,

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Auf ein gutes neues 2007!

Folgende Unregelmäßigkeit fiel mir auf:

Die Eingabezeile eines Signalelements enthielt folgende Einschränkung:
U1(Z=5:40-5:41),U0

Diese Einschränkung sollte erweitert werden um "*(Z=22:58-22:59)":
U1(Z=5:40-5:41),*(Z=22:58-22:59),U0

Dabei erhielt ich Fehlermeldung Nr. 869: Überlappung Linie "*" mit Linie "U0". Ich klickte auf den Abbruch-Button und öffnete das Dialogfeld erneut
=> Die Eingabezeile war gelöscht.

Hierin liegt m.E. ein Fehler, denn wenn ich eine bestehende Anweisung nicht erweitern kann, dann muss diese bei einem Abbruch der Eingabe erhalten bleiben und darf nicht gelöscht werden. Dieser Fehler tritt bei gleicher Vorgehensweise auch beim Rangierpunkt auf; er ist also nicht auf Signale beschränkt.

</tr></td></table>

Das ist an vielen Stellen so. Ansonsten müßte meist 2mal Pufferspeicher vorhanden sein, einmal für die Originaldaten und einmal für die neu eingegebenen Daten. Das war in früheren Versionen schlicht unmöglich und hat sich daher bis heute an vielen Stellen gehalten. Bei einigen sehr komplexen Dingen ist es auch heute noch problematisch, z.B. Taktpunkte mit bis zu 7 Wochentagen.

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">

Merkwürdigerweise wird Fehlermeldung Nr. 869 nicht ausgegeben, wenn ich die Erweiterung nicht einfüge, sondern an die bestehende Anweisung anhänge:
U1(Z=5:40-5:41),U0,*(Z=22:58-22:59)

Funktioniert die erweiterte Anweisung jetzt, oder verbleibt BAHN u.U. in einem undefinierten Zustand?

</tr></td></table>

Das war lange Zeit auch nicht gestattet und führte zum selben Fehler. Es ist aber später mal zugelassen worden (BAHN 3.81r1 8/2003). In diesem Fall bedeutet "*" = "für alle anderen", d.h. für alle, die vorher nicht genannt worden sind oder wo die Bedingungen (Zeitangaben) vorher nicht galten. In diesem Fall also auch für U1 von 22:58-22:59.

Schöne Grüße
Jan B.

[Jan Bochmann]

Guten Tag,

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Mahlzeit...

Diese Antwort befriedigt nicht wirklich...</tr></td></table>

Wird mit BAHN 3.84 geändert, und zwar bereits rückwirkend mindestens ab Beta5. Es handelt sich wie gesagt im wesentlichen um Algorithmen, die etliche Jahre alt sind. Unter DOS und Win16 waren 16KB Stack für temporäre Eingaben schon sehr viel, unter Win32 hat man dagegen als Standard bereits 1MB.

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
, denn:
wenn ich in der Eingabezeile eines Signalelementes eine Änderung vornehme,
diesen Vorgang aber abbreche, dann bleibt die bisherige Anweisung erhalten;</tr></td></table>

Es gibt einen Unterschied zwischen

1. "Abbrechen" (Da bleiben die Daten erhalten)

und

2. "OK" Betätigen und danach "Abbrechen".

Bei "OK" wird versucht, die Daten zu übernehmen. Dazu wird heute meistens die komplette Zeile geprüft und dann -wenn fehlerfrei- übernommen. Wegen Mangels an Speicherplatz geschah das früher aber in Teilschritten. D.h. erst prüfen erster Teil, wenn OK, diesen übernehmen. Dann prüfen 2.Teil, usw. Vor der Übernahme des ersten Teils mußten die alten Daten bereits vollständig gelöscht werden. Ansonsten hätte sich eine neue Eingabe mit einer alten widersprechen können und genauso unverständliche Reaktionen erzeugt. Wenn nun aber beim 3.Teil der Eingabe ein Fehler festgestellt wird, dann ist eben schon alles weg. Genaugenommen müßte bei Betätigen von "OK" also erstmal der Button "Abbruch" entweder deaktiviert oder in "Schließen" umbenannt werden.

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Vorschlage: Könnte nicht ein Kapitel
"Bekannte Probleme" in die Hilfe aufgenommen werden?</tr></td></table>

Schon die Antwort zum ersten Beitrag habe ich großenteils aus der Hilfe kopiert: Der Hilfetext zur Fehlermeldung 869 beschreibt die Verwendung des "*". Wozu Dinge schreiben, die dann keiner liest?

MfG
Jan B.

[Rolf R]

Hallo Gerd,

die Quintessenz aus Deinen Beiträgen dürfte wohl sein, dass Du es gern möchtest, dass auch fehlerhafte Einträge abgespeichert werden sollten -
nur eben mit einer Fehlermeldung.
Ist doch richtig?

Die Problematik steckt dann vielmehr im Detail:
a) Was passiert, wenn die Fehlermeldung in diesem Falle übergangen würde?
b) Wie sollte die Fehler-Prüfungsroutine das Ganze verarbeiten?
Einerseits soll sie einen Fehler akzeptieren, den Sie aber andererseits nicht akzeptieren darf (wofür sollte sie auch sonst gut sein?).

Besonders die *-Funktion hat ja ihre Nachwirkungen:
es müssen in allen betroffenen Linien bestimmte Hintergrundfunktionen aktiviert oder desaktiviert werden, entsprechend müssten Sie dann alle rückgängig gemacht werden - das wäre sicherlich eine gewaltiger Aufwand -
unabhängig davon, wie sie verarbeitet werden.

Ich denke mal, dass die jetzige Funktionsweise die wirkungsvollste ist, zumal sie sich letztlich nur auf die letzte fehlerhafte Eingabe bezieht. Der restliche Teil der Einschränkungen bleibt ja bestehen.

P.S.: zur 1. Anfrage, warum einmal Fehler 869 erschein und einmal nicht:
Ich denke, dass versuchte Jan Bochmann zu erklären: es liegt an die verschiedenen Definitionen für die Linie "*"
a) U1(Z=5:40-5:41),*(Z=22:58-22:59),U0 -> hier steht der * für alle Linien außer U1, also auch für U0. Und da Du U0 explizit ergänzt hast, ist sie 2x erwähnt
b) U1(Z=5:40-5:41),U0,*(Z=22:58-22:59) -> hier steht der * für alle Linien außer U1 und U0, weil diese Linie vor dem *-Eintrag erwähnt wurden.

Grüße

Rolf

[Rolf R]

Hi Gerd,

klasse - dann sind wir ja ein Stück weiter.
In der 3.84 Beta5 ist das System meinen Erfahrungen nach genau so aufgebaut, aber ich kann damit gut leben.

Ich hatte Jan auch so verstanden, dass er die Funktion neu definiert hatte -
so dass das Sternchen je nach Standort unterschiedliche Werte hat, was zuvor nur einen Wert kannte - nämlich alle Linien - ohne Ausnahme.
Das hatte natürlich den Nachteil, dass man, wenn man z.B. die 100. Linie einbaute und diese an einer Weiche abzweigen musste, alle anderen 99 Linien neu berücksichtigen musste.

Rolf