Also, ich hab bei der neuen Version 2 Probleme festegestellt. Ich weß natürlich nicht ob da mein REchner "Spinnt" oder es tatsächlich ein Bug ist.
1. Wenn ich mit dem Kursor ganz an der Rechten oder unteren Rand gehe stüzt BAHN ab (Fehler reproduzierbar!)
2. Wenn ich von der 1:1 ansich auf eine kleine Ansicht wechsle (z.B.: 1:256) und dann nach "Süden" verschiebe wir ein ein Element hoher Steifen aus der letzten Ansicht sichtbar (Verschwindet bei nachmaligen Hin- und Her-Verschieben) - ebenfalls repoduzierbar.
3. Beim Welseln zwischen 2 kleinen Ansichten (von 1:256 nach 1:512) erscheine kleine Teile von Stecken dort wo sich eigentlich rag nicht sind, auch sehen Strecken aus, als seien sie unterbrochen, wird aber wieder hegestellt, sobalt ein Zug sie durchfahren hat. (passiert nicht immer, aber doch relativ oft)
Meine Frage geht eigentlich dahin, ob es sich her um echte Fehler handelt, oder ob mein Windows mir da irgendwie Mist baut.
Gruß
Holger
Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">1. Wenn ich mit dem Kursor ganz an der Rechten oder unteren Rand gehe stüzt BAHN ab (Fehler reproduzierbar!)
</tr></td></table>
Ist bei mir noch nicht vorgekommen - scheint aber eher ein Problem von BAHN zu sein als von Windows. Scheinbar kommt BAHN mit einer Cursor-Position 32768 nicht zurecht (befindet sich ja im Osten bzw. Süden).
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">2. Wenn ich von der 1:1 ansich auf eine kleine Ansicht wechsle (z.B.: 1:256) und dann nach "Süden" verschiebe wir ein ein Element hoher Steifen aus der letzten Ansicht sichtbar (Verschwindet bei nachmaligen Hin- und Her-Verschieben) - ebenfalls repoduzierbar. </tr></td></table>
Ist ein Problem aus r3 und wurde hier im Forum schon öfter moniert.Scheinbar kann BAHN (oder die Grafikkarte) die neue Ansicht nicht schnellanzeigen (könnte auch am Arbeitsspeicher liegen). Das Problem sollte eigentlich mit r3a behoben werden, ist es aber noch nicht. Aber Jan Bochmann arbeitet sicherlich dran.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">3. Beim Welseln zwischen 2 kleinen Ansichten (von 1:256 nach 1:512) erscheine kleine Teile von Stecken dort wo sich eigentlich rag nicht sind, auch sehen Strecken aus, als seien sie unterbrochen, wird aber wieder hegestellt, sobalt ein Zug sie durchfahren hat. (passiert nicht immer, aber doch relativ oft) </tr></td></table>
dito. Bis zur endgültigen Lösung kannst Du Dich hier mit einem kleinen Trick behelfen, in dem Du das Fenster von BAHN minimierst und anschließend wieder maximierst.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Meine Frage geht eigentlich dahin, ob es sich her um echte Fehler handelt, oder ob mein Windows mir da irgendwie Mist baut.
</tr></td></table>
Ich denke, dass es hier wohl darauf hinausläuft, dass sowohl BAHN als auch Windows ihr Zusammenspiel verbessern müssen. Aber es ist kein Problem von Deinem Windows.
Grüße
Rolf
</tr></td></table>
Ist bei mir noch nicht vorgekommen - scheint aber eher ein Problem von BAHN zu sein als von Windows. Scheinbar kommt BAHN mit einer Cursor-Position 32768 nicht zurecht (befindet sich ja im Osten bzw. Süden).
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">2. Wenn ich von der 1:1 ansich auf eine kleine Ansicht wechsle (z.B.: 1:256) und dann nach "Süden" verschiebe wir ein ein Element hoher Steifen aus der letzten Ansicht sichtbar (Verschwindet bei nachmaligen Hin- und Her-Verschieben) - ebenfalls repoduzierbar. </tr></td></table>
Ist ein Problem aus r3 und wurde hier im Forum schon öfter moniert.Scheinbar kann BAHN (oder die Grafikkarte) die neue Ansicht nicht schnellanzeigen (könnte auch am Arbeitsspeicher liegen). Das Problem sollte eigentlich mit r3a behoben werden, ist es aber noch nicht. Aber Jan Bochmann arbeitet sicherlich dran.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">3. Beim Welseln zwischen 2 kleinen Ansichten (von 1:256 nach 1:512) erscheine kleine Teile von Stecken dort wo sich eigentlich rag nicht sind, auch sehen Strecken aus, als seien sie unterbrochen, wird aber wieder hegestellt, sobalt ein Zug sie durchfahren hat. (passiert nicht immer, aber doch relativ oft) </tr></td></table>
dito. Bis zur endgültigen Lösung kannst Du Dich hier mit einem kleinen Trick behelfen, in dem Du das Fenster von BAHN minimierst und anschließend wieder maximierst.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Meine Frage geht eigentlich dahin, ob es sich her um echte Fehler handelt, oder ob mein Windows mir da irgendwie Mist baut.
</tr></td></table>
Ich denke, dass es hier wohl darauf hinausläuft, dass sowohl BAHN als auch Windows ihr Zusammenspiel verbessern müssen. Aber es ist kein Problem von Deinem Windows.
Grüße
Rolf
Mein Link-Tipp zu BAHN: http://www.gerdinoack.de. Dort findet Ihr Filme und Grafiken zu BAHN von Gerd (Username gnock) und mein neues Fahrzeugarchiv, das auch unter dem neuen Direktlink www.gerdinoack.de/Fahrzeugarchiv_385/ zu erreichen ist.
-
Markus Klingsiek
- Beiträge: 252
- Registriert: Montag 26. Mai 2003, 22:28
- Wohnort: Indienststellung: Minden/Westf, Überstellung nach Wien 2006, Überstellung ins Waldviertel 2014
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Der erste Fehler lässt sich bei mir am Rechner mühelos reproduzieren. Zwar wechseln im Statusfenster noch die Koordinaten, wenn ich mit dem Cursor nach rechts unten gehe, aber das Bild friert ein und BAHN stürzt dann irgendwann ab, spätestens nach dem Zoom-Wechsel. War es das, was du meintest?
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
OK, erstamal danke für die Antworten.
Der Absturz ereignet sich bei mir bereits bei 32763. Dann kommt einfach die typische Windows-Meldung. "Programm muß beendet werden..."
Gruß
Holger
Der Absturz ereignet sich bei mir bereits bei 32763. Dann kommt einfach die typische Windows-Meldung. "Programm muß beendet werden..."
Gruß
Holger
-
richterjue
- Beiträge: 365
- Registriert: Samstag 1. November 2003, 16:28
- Wohnort: Bad Teinach-Zavelstein und Fürstenwalde
- Kontaktdaten:
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Hallo
Ich vermute anhand der Zellen 32763 Position das es sich hier um einen im Quellcode nur sehr schwer zu ermittelnden Pointerfehler in C# handelt der zu einem Speicherüberlauf des lokalen Stack führt. Da ja Bahn während der Simulation komplett im Arbeitsspeicher gehalten wird, ist es eher ein Problem der verwendeten C#-Routinen. Diese aber durch Assembler-Code zuersetzen ist sehr mühsehlig, da man hier sich nicht zu 100% auf die API von Microsoft verlassen kann, und beim Wechsel zu den API-Funktionen das Ruckeln auch wieder verstärkt wird. Fremdcode zu verwenden ist auch nicht möglich, da es eine ähnliche Lösung nicht gibt und Bahn ja auch in diesem Punkt ein wenig einzigartig ist. Da hat Jan sicherlich noch eine harte Nuß zu knacken. [img]icon_lol.gif[/img]
Hoffen wir das, er für des Rätzels Lösung ein gute Idee hat. Ich bin an dieser Stelle auch ratlos.
Herzliche Grüße
richterjue
Ich vermute anhand der Zellen 32763 Position das es sich hier um einen im Quellcode nur sehr schwer zu ermittelnden Pointerfehler in C# handelt der zu einem Speicherüberlauf des lokalen Stack führt. Da ja Bahn während der Simulation komplett im Arbeitsspeicher gehalten wird, ist es eher ein Problem der verwendeten C#-Routinen. Diese aber durch Assembler-Code zuersetzen ist sehr mühsehlig, da man hier sich nicht zu 100% auf die API von Microsoft verlassen kann, und beim Wechsel zu den API-Funktionen das Ruckeln auch wieder verstärkt wird. Fremdcode zu verwenden ist auch nicht möglich, da es eine ähnliche Lösung nicht gibt und Bahn ja auch in diesem Punkt ein wenig einzigartig ist. Da hat Jan sicherlich noch eine harte Nuß zu knacken. [img]icon_lol.gif[/img]
Hoffen wir das, er für des Rätzels Lösung ein gute Idee hat. Ich bin an dieser Stelle auch ratlos.
Herzliche Grüße
richterjue
Zuletzt geändert von richterjue am Dienstag 8. Juli 2008, 21:25, insgesamt 1-mal geändert.
-
micha88
- Beiträge: 1989
- Registriert: Freitag 18. Februar 2005, 12:50
- Wohnort: Marbach am Neckar
- Kontaktdaten:
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
@Richterjue: Bist du dir sicher, dass BAHN C# verwendet? BAHN verwendet wohl nicht mal C++, siehe http://jbss.de/faq.htm .
Außerdem muss der Fehler ja garnicht nicht schwer zu beheben sein, zumindest im Forum wurde der Fehler ja meines Wissens bisher noch nicht beschrieben. Am schwierigsten sind nämlich die Fehler zu beheben, die noch keiner bemerkt hat [img]icon_wink.gif[/img]
Oder hat die Zahl 32763 für dich irgendeine magische Bedeutung, dass du genau bei diesem Fehler auf eine schwer zu knackende Nuss schließt?
Außerdem muss der Fehler ja garnicht nicht schwer zu beheben sein, zumindest im Forum wurde der Fehler ja meines Wissens bisher noch nicht beschrieben. Am schwierigsten sind nämlich die Fehler zu beheben, die noch keiner bemerkt hat [img]icon_wink.gif[/img]
Oder hat die Zahl 32763 für dich irgendeine magische Bedeutung, dass du genau bei diesem Fehler auf eine schwer zu knackende Nuss schließt?
-
Markus Klingsiek
- Beiträge: 252
- Registriert: Montag 26. Mai 2003, 22:28
- Wohnort: Indienststellung: Minden/Westf, Überstellung nach Wien 2006, Überstellung ins Waldviertel 2014
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
So kompliziert muss es gar nicht mal sein...
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Oder hat die Zahl 32763 für dich irgendeine magische Bedeutung, dass du genau bei diesem Fehler auf eine schwer zu knackende Nuss schließt?</tr></td></table>
Ich hätte spontan darauf getippt, dass es sich um eine Überschreitung der Bereichsgrenze eines Datentypen handelt. Daten und Zahlen werden in einer Programmiersprache solchen Typen angegeben.
Es gibt verschiedene Datentypen, einer davon nennt sich (je nach Sprache) Integer oder Short. Dessen Obergrenze liegt bei 32767. Größer darf der Wert einer numerischen Variable, die als Integer deklariert wurde, nicht sein. Wird diese Grenze aber überschritten, hat das unangenehme Konsequenzen - i.d.R führt es unweigerlich zum Programmabsturz.
Man kann solche Fehler abfangen, oder aber, und das wird bei BAHN vermutlich der Fall sein, man stellt einfach durch den Quellcode ansich sicher, dass ein "Überlauf" einer Variable ausgeschlossen ist.
Diese Datentyp-Obergrenzen sind übrigens wohl auch seit jeher der Grund für die "krumme" Größe der BAHN-Welt (1024, 2048, 16383, 32767). Soll die Welt also in Zukunft größer werden, erfordert das einen Sprung in den nächst größeren Datentypen. Der Höchstwert wäre dann 65535... Aber den Datentypen umzustellen ist schon in wenig Quellcode eine Menge Frickelei, insbesondere bei strikter Programmierung...
Die Int-Obergrenze liegt wie gesagt bei 32767. Woher aber jetzt die "4 weniger" kommen, ist mir ein Rätsel. Da kann man nur spekulieren. Gibt es da einen Verrechnungs-Fehler mit der z-Ebene? Oder liegt es an der Darstellung etc. etc. etc.? Das wird Jan wohl besser wissen, denn er kennt ja den Quellcode.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Oder hat die Zahl 32763 für dich irgendeine magische Bedeutung, dass du genau bei diesem Fehler auf eine schwer zu knackende Nuss schließt?</tr></td></table>
Ich hätte spontan darauf getippt, dass es sich um eine Überschreitung der Bereichsgrenze eines Datentypen handelt. Daten und Zahlen werden in einer Programmiersprache solchen Typen angegeben.
Es gibt verschiedene Datentypen, einer davon nennt sich (je nach Sprache) Integer oder Short. Dessen Obergrenze liegt bei 32767. Größer darf der Wert einer numerischen Variable, die als Integer deklariert wurde, nicht sein. Wird diese Grenze aber überschritten, hat das unangenehme Konsequenzen - i.d.R führt es unweigerlich zum Programmabsturz.
Man kann solche Fehler abfangen, oder aber, und das wird bei BAHN vermutlich der Fall sein, man stellt einfach durch den Quellcode ansich sicher, dass ein "Überlauf" einer Variable ausgeschlossen ist.
Diese Datentyp-Obergrenzen sind übrigens wohl auch seit jeher der Grund für die "krumme" Größe der BAHN-Welt (1024, 2048, 16383, 32767). Soll die Welt also in Zukunft größer werden, erfordert das einen Sprung in den nächst größeren Datentypen. Der Höchstwert wäre dann 65535... Aber den Datentypen umzustellen ist schon in wenig Quellcode eine Menge Frickelei, insbesondere bei strikter Programmierung...
Die Int-Obergrenze liegt wie gesagt bei 32767. Woher aber jetzt die "4 weniger" kommen, ist mir ein Rätsel. Da kann man nur spekulieren. Gibt es da einen Verrechnungs-Fehler mit der z-Ebene? Oder liegt es an der Darstellung etc. etc. etc.? Das wird Jan wohl besser wissen, denn er kennt ja den Quellcode.
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Woher aber jetzt die "4 weniger" kommen, ist mir ein Rätsel. Da kann man nur spekulieren. Gibt es da einen Verrechnungs-Fehler mit der z-Ebene? Oder liegt es an der Darstellung etc. etc. etc.? Das wird Jan wohl besser wissen, denn er kennt ja den Quellcode.</tr></td></table>
Kann es nicht sein, dass BAHN normalerweise anfängt nach rechts zu scrollen, wenn man 4 Cursorschritte vom rechten Bildschirmrand entfernt ist? Ich könnte mir das vorstellen... Dann würde BAHN nämlich versuchen, die Spalte 32768 darzustellen...
Kann es nicht sein, dass BAHN normalerweise anfängt nach rechts zu scrollen, wenn man 4 Cursorschritte vom rechten Bildschirmrand entfernt ist? Ich könnte mir das vorstellen... Dann würde BAHN nämlich versuchen, die Spalte 32768 darzustellen...
-
Gast
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Also, bei mir stellt sich das Problem mit der 384r3 so dar:
Cursor setzen in Zoom 1:1 und höher:
32763,16384 -> kein Problem
16384,32763 -> Programmabsturz
32763,32763 -> Programmabsturz
Cursor setzen in Zoom 1:2 und niedriger:
32763,16384 -> kein Problem
16384,32763 -> kein Problem
32763,32763 -> kein Problem
Der Absturz scheint demnach nur beim Setzen der Y-Koordinate in den Zoomstufen 1:1 und höher aufzutreten - somit dürfte Jan B. gefragt sein.
Schöne Grüße
GNock
Cursor setzen in Zoom 1:1 und höher:
32763,16384 -> kein Problem
16384,32763 -> Programmabsturz
32763,32763 -> Programmabsturz
Cursor setzen in Zoom 1:2 und niedriger:
32763,16384 -> kein Problem
16384,32763 -> kein Problem
32763,32763 -> kein Problem
Der Absturz scheint demnach nur beim Setzen der Y-Koordinate in den Zoomstufen 1:1 und höher aufzutreten - somit dürfte Jan B. gefragt sein.
Schöne Grüße
GNock
-
richterjue
- Beiträge: 365
- Registriert: Samstag 1. November 2003, 16:28
- Wohnort: Bad Teinach-Zavelstein und Fürstenwalde
- Kontaktdaten:
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Ich habe schon vor längerer Zeit mit Jan mal persönlich gesprochen in welcher Porgrammiersprache Bahn erstellt wurde. Er hat mir gesagt des es ein relativ altes C# ist. Er wollte im laufenden Jahr hier einen Wechsel zu einer neueren Sprache mit einem neueren Compiler wechseln. Ich denke das er zu C++ wechselt, da das sicherlich am einfachsten ist. Man muß dabei nähmlich nicht alles gleich "Neu" schreiben und kann sich ersteinmal auf die Problemgebiete stürzen. Ich denke das hier die Grafikausgabe momentan der größte Brocken ist. Ist ja schließlich mit dem letzten Release ja besser geworden.
Mann kann nämlich für die mitllerweile sehr unübersichtlichen Listen bei Taktpunkten/Datenwechselpunkten, vielleicht eine macroähnliche Sprachkomponente einführen. Aber da erwarte ich sicherlich zuviel. Besser finde ich jedenfalls da eher die Multithreadingfähigkeiten umzusetzen.
Herzliche Grüße
Jürgen Richter
Mann kann nämlich für die mitllerweile sehr unübersichtlichen Listen bei Taktpunkten/Datenwechselpunkten, vielleicht eine macroähnliche Sprachkomponente einführen. Aber da erwarte ich sicherlich zuviel. Besser finde ich jedenfalls da eher die Multithreadingfähigkeiten umzusetzen.
Herzliche Grüße
Jürgen Richter
-
micha88
- Beiträge: 1989
- Registriert: Freitag 18. Februar 2005, 12:50
- Wohnort: Marbach am Neckar
- Kontaktdaten:
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
Du meinst aber sicher C und nicht C#.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Mann kann nämlich für die mitllerweile sehr unübersichtlichen Listen bei Taktpunkten/Datenwechselpunkten, vielleicht eine macroähnliche Sprachkomponente einführen. Aber da erwarte ich sicherlich zuviel. Besser finde ich jedenfalls da eher die Multithreadingfähigkeiten umzusetzen.</tr></td></table>Natürlich kann man innerhalb von BAHN eine Skript-Sprache einführen. Davon wird BAHN aber nicht einfacher... schon die BAHN 3.84-Signalanlagen sind für viele sehr kompliziert.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Mann kann nämlich für die mitllerweile sehr unübersichtlichen Listen bei Taktpunkten/Datenwechselpunkten, vielleicht eine macroähnliche Sprachkomponente einführen. Aber da erwarte ich sicherlich zuviel. Besser finde ich jedenfalls da eher die Multithreadingfähigkeiten umzusetzen.</tr></td></table>Natürlich kann man innerhalb von BAHN eine Skript-Sprache einführen. Davon wird BAHN aber nicht einfacher... schon die BAHN 3.84-Signalanlagen sind für viele sehr kompliziert.
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Also, bei mir stellt sich das Problem mit der 384r3 so dar:
Cursor setzen in Zoom 1:1 und höher:
32763,16384 -> kein Problem
16384,32763 -> Programmabsturz
32763,32763 -> Programmabsturz
Cursor setzen in Zoom 1:2 und niedriger:
32763,16384 -> kein Problem
16384,32763 -> kein Problem
32763,32763 -> kein Problem
Der Absturz scheint demnach nur beim Setzen der Y-Koordinate in den Zoomstufen 1:1 und höher aufzutreten - somit dürfte Jan B. gefragt sein.
Schöne Grüße
GNock</tr></td></table>
Also das mit Zoom 1:2 kann ich so nicht bestätigen. Bei Y=32763 stürzt bahn zuverlässig ab, unabhängig der Auflösung.
Gruß
Holger Echtermeyer
Cursor setzen in Zoom 1:1 und höher:
32763,16384 -> kein Problem
16384,32763 -> Programmabsturz
32763,32763 -> Programmabsturz
Cursor setzen in Zoom 1:2 und niedriger:
32763,16384 -> kein Problem
16384,32763 -> kein Problem
32763,32763 -> kein Problem
Der Absturz scheint demnach nur beim Setzen der Y-Koordinate in den Zoomstufen 1:1 und höher aufzutreten - somit dürfte Jan B. gefragt sein.
Schöne Grüße
GNock</tr></td></table>
Also das mit Zoom 1:2 kann ich so nicht bestätigen. Bei Y=32763 stürzt bahn zuverlässig ab, unabhängig der Auflösung.
Gruß
Holger Echtermeyer
Zuletzt geändert von Holger am Donnerstag 10. Juli 2008, 02:22, insgesamt 1-mal geändert.
-
Jan Bochmann
- Beiträge: 2211
- Registriert: Sonntag 16. März 2003, 15:25
- Kontaktdaten:
Re: Bahn 3.84r3a Programmabsturz und seltsames Verhalten
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"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">1. Wenn ich mit dem Kursor ganz an der Rechten oder unteren Rand gehe stüzt BAHN ab (Fehler reproduzierbar!)
</tr></td></table>
Ist bei mir noch nicht vorgekommen - scheint aber eher ein Problem von BAHN zu sein als von Windows.</tr></td></table>
Das ist ein Problem von BAHN. Danke für den Hinweis.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Scheinbar kommt BAHN mit einer Cursor-Position 32768 nicht zurecht (befindet sich ja im Osten bzw. Süden).</tr></td></table></tr></td></table>
Der Cursor darf gar nicht auf diesen Wert gelangen. Aber normalerweise ist östlich und südlich vom Cursor auch noch etwas zu sehen. Dabei gibt es immer einige Rundungsdifferenzen, abhängig sowohl vom BAHN-Anzeigemaßstab als auch von der Größe des Editfensters (also meist auch von der Bildschirmauflösung, wenn man die gesamte Breite nutzt).
Der Absturz läßt sich im Notfall vermeiden, wenn man alle Arten von Textanzeige ausschaltet (normale Texte, Linie/Zugnummer und Objekte im Streckennetz).
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">2. Wenn ich von der 1:1 ansich auf eine kleine Ansicht wechsle (z.B.: 1:256) und dann nach "Süden" verschiebe, wird ein ein Element hoher Streifen aus der letzten Ansicht sichtbar (verschwindet bei nachmaligen Hin- und Her-Verschieben) - ebenfalls reproduzierbar. </tr></td></table>
Ist ein Problem aus r3 und wurde hier im Forum schon öfter moniert.Scheinbar kann BAHN (oder die Grafikkarte) die neue Ansicht nicht schnellanzeigen (könnte auch am Arbeitsspeicher liegen). Das Problem sollte eigentlich mit r3a behoben werden, ist es aber noch nicht. Aber Jan Bochmann arbeitet sicherlich dran.</tr></td></table>
Ja.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">3. Beim Wechseln zwischen 2 kleinen Ansichten (von 1:256 nach 1:512) erscheine kleine Teile von Strecken dort wo sie eigentlich gar nicht sind, auch sehen Strecken aus, als seien sie unterbrochen, wird aber wieder hergestellt, sobald ein Zug sie durchfahren hat. (passiert nicht immer, aber doch relativ oft) </tr></td></table></tr></td></table>
Das dürfte mit dem vorherigen Problem zusammenhängen.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">dito. Bis zur endgültigen Lösung kannst Du Dich hier mit einem kleinen Trick behelfen, in dem Du das Fenster von BAHN minimierst und anschließend wieder maximierst.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Meine Frage geht eigentlich dahin, ob es sich her um echte Fehler handelt, oder ob mein Windows mir da irgendwie Mist baut.
</tr></td></table>
</tr></td></table>
Das liegt an BAHN, d.h. Windows ist hier unschuldig.
Grüße
Jan B.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">1. Wenn ich mit dem Kursor ganz an der Rechten oder unteren Rand gehe stüzt BAHN ab (Fehler reproduzierbar!)
</tr></td></table>
Ist bei mir noch nicht vorgekommen - scheint aber eher ein Problem von BAHN zu sein als von Windows.</tr></td></table>
Das ist ein Problem von BAHN. Danke für den Hinweis.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Scheinbar kommt BAHN mit einer Cursor-Position 32768 nicht zurecht (befindet sich ja im Osten bzw. Süden).</tr></td></table></tr></td></table>
Der Cursor darf gar nicht auf diesen Wert gelangen. Aber normalerweise ist östlich und südlich vom Cursor auch noch etwas zu sehen. Dabei gibt es immer einige Rundungsdifferenzen, abhängig sowohl vom BAHN-Anzeigemaßstab als auch von der Größe des Editfensters (also meist auch von der Bildschirmauflösung, wenn man die gesamte Breite nutzt).
Der Absturz läßt sich im Notfall vermeiden, wenn man alle Arten von Textanzeige ausschaltet (normale Texte, Linie/Zugnummer und Objekte im Streckennetz).
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote"><table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">2. Wenn ich von der 1:1 ansich auf eine kleine Ansicht wechsle (z.B.: 1:256) und dann nach "Süden" verschiebe, wird ein ein Element hoher Streifen aus der letzten Ansicht sichtbar (verschwindet bei nachmaligen Hin- und Her-Verschieben) - ebenfalls reproduzierbar. </tr></td></table>
Ist ein Problem aus r3 und wurde hier im Forum schon öfter moniert.Scheinbar kann BAHN (oder die Grafikkarte) die neue Ansicht nicht schnellanzeigen (könnte auch am Arbeitsspeicher liegen). Das Problem sollte eigentlich mit r3a behoben werden, ist es aber noch nicht. Aber Jan Bochmann arbeitet sicherlich dran.</tr></td></table>
Ja.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">3. Beim Wechseln zwischen 2 kleinen Ansichten (von 1:256 nach 1:512) erscheine kleine Teile von Strecken dort wo sie eigentlich gar nicht sind, auch sehen Strecken aus, als seien sie unterbrochen, wird aber wieder hergestellt, sobald ein Zug sie durchfahren hat. (passiert nicht immer, aber doch relativ oft) </tr></td></table></tr></td></table>
Das dürfte mit dem vorherigen Problem zusammenhängen.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">dito. Bis zur endgültigen Lösung kannst Du Dich hier mit einem kleinen Trick behelfen, in dem Du das Fenster von BAHN minimierst und anschließend wieder maximierst.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Meine Frage geht eigentlich dahin, ob es sich her um echte Fehler handelt, oder ob mein Windows mir da irgendwie Mist baut.
</tr></td></table>
</tr></td></table>
Das liegt an BAHN, d.h. Windows ist hier unschuldig.
Grüße
Jan B.