poke53280,12:poke53281,11:poke646,15:sys64764
super
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von lame-zock-opa am
poke53280,12:poke53281,11:poke646,15:sys64764
super
Da hat drazil was angerichtet. Der Bug ist eine größere Kopfnuss als ich dachte.
Da werde ich nach dem Aufstehen mit Stift und Papier bewaffnet einen neuen Versuch unternehmen dem Fehler auf die Spur zu kommen.
I'm so sorry. Ist aber wirklich ein schönes Projekt.
I'm so sorry. Ist aber wirklich ein schönes Projekt.
Das mit dem „angerichtet“ war natürlich nicht ernst gemeint.
Und Du hast Recht, ein schönes Projekt welches mir besonders in den letzten Wochen viel Freude bereitet hatte.
Nachtrag:
Da hatte ich bis in die Nacht an dem Bug gesessen und war mit der Erkenntnis ins Bett gegangen, das bisherige Versuche das Problem nicht lösen konnten.
Jetzt sitzte ich wieder an dem Problem und stelle fest das ich den Fehler so nicht mehr reproduzieren kann.
Hat sich über Nacht wohl selbst wegprogrammiert.
Und wieder ein Update meines "Special Interest"-Projekts zur Anzeige von (durch spezielle Kommentare) strukturiertem Quellcode.
Ich habe meine beiden Hauptprobleme gelöst und weitere Features eingebaut:
In der Form ist der Viewer bereits einigermaßen einsetzbar. Es fehlen aber noch ein paar Sachen wie das freie Markieren/Kopieren von Text und Komfortfeatures wie das Markieren passender Klammern oder das Markieren aller gleichen Worte, wenn man eins markiert hat usw.
Es gibt auch noch ein paar kleinere Probleme. Beim Umschalten zwischen den Tabs wird der Quelltext zuerst eine Zeile zu noch und eine Zeile zu kurz angezeigt (sieht man auch oben im Bild). Erst wenn man mit der Maus drüberfährt, springt die Anzeige auf die korrekte Darstellung um.
[EDIT]
Oh, das letztere Problem konnte ich mit einer Zeile korrigieren:
Muß man jetzt nicht unbedingt verstehen, aber jetzt scheint es zu tun wie erwartet.
Und weiter geht's.
Es fehlen jetzt eigentlich nur noch ein paar Kleinigkeiten wie die automatische Markierung von Klammern und das Kopieren von Blöcken oder der ganzen Ansicht in die Zwischenablage.
Ich bin auch noch nicht 100% zufrieden mit dem Mechanismus zum freien Markieren von Text. Eigentlich sollte der auch leere Zeichen hinter dem Zeilenende und Tabs berücksichtigen. Aber es geht auch so.
Aber dann bin ich wieder in eine Wand gerannt. Ich hatte ja früher schon geschrieben, daß mir das DPI-Scaling große Probleme bereitet hat und das es ein merkwürdiges Problem mit dem Hoch- und Runterspringen der Anzeige gab, was ich über Setzen des BACKINGSTORE_SCROLL_MODE beseitigt zu haben dachte.
Leider zeigten sich im praktischen Einsatz merkwürdige Artefakte beim Scrollen. Teils waren weiße Linien zu sehen, teils waren gerade Linien aus meinem korrekt gezeichneten BufferedImage "ausgefranst", also mal um einen Pixel nach oben oder unten versetzt. Ich kann nicht wirklich sagen, woran das genau lag, aber es hing eindeutig mit dem BACKINGSTORE_SCROLL_MODE zusammen, also mußte ich den wieder deaktivieren. Und sofort hatte ich wieder das Problem, daß die Anzeige hoch- und runtergesprungen ist. Es war inzwischen sogar schlimmer geworden. Ich konnte das zwar dahingehend "verbessern", daß das Springen weg war, aber dafür haben dann immer die ersten paar Zeilen Text gefehlt. Nach langen Debugging-Sitzungen und vielen Experimenten bin ich zu der Erkenntnis gelangt, daß die Anzeige um genau 60 Pixel verschoben ist. Aus der Tatsache, daß der Y-Offset größer geworden ist, seitdem ich TabbedPane und Menü eingeführt habe und gleichzeitig der X-Offset immer noch unauffällig war, kam ich auf die Idee, daß die 60 Pixel sich irgendwie aus dem Offset des ViewPorts zum Hauptfenster ergeben. Allerdings ergab sich damit nur ein Wert von 48 Pixeln. Mit meiner DPI-Skalierung von 1.25 wurden dabei auf wundersame Weise aber genau die gesuchten 60 Pixel.
Das hat mich dann nach einigen Fehlschlägen wieder auf die affine Abbildung gebracht, die mir das Leben wegen der DPI-Skalierung schwer gemacht hatte. Und siehe da: in der ursprünglichen Version war nicht nur die Skalierung enthalten, sondern auch die Verschiebung des ViewPorts:
Als ich diese affine Abbildung überschrieben habe, um die Skalierung um den Faktor 1.25 zu vermeiden, habe ich auch die Verschiebung ausgeknockt. Tatsächlich sogar die gesamte Verschiebung des Viewports.
Das erklärt auch ein anderes Phänomen, daß ich nicht wirklich verstanden, aber halt irgendwie hingenommen hatte: ich hatte irgendwie erwartet, daß ich den sichtbaren Ausschnitt in meinem JPanel trotzdem an den richtigen Koordinaten zeichnen muß. Stattdessen mußte ich aber quasi alles ab Offset (0,0) zeichnen und z.B. von der tatsächlichen Y-Position im Panel die Y-Position des sichtbaren Ausschnitts abziehen. Das war aber nur ein Resultat daraus, daß ich die affine Abbildung wegen der DPI-Problematik überschrieben hatte.
Hoffen wir mal, daß ich dieses Problem jetzt endgültig behoben habe.
[EDIT]
Auch wenn es "Special Interest" ist, habe ich den Status jetzt mal in ein Repository eingespielt und eine Website erstellt.
Ich arbeite ja zur Zeit an einem neuen Spiel, und habe dafuer auch vor einiger Zeit einen Leveleditor angefertigt in Python. Dort habe ich gestern bei unserem "42. Spieleentwicklertreffen" (https://spieleentwicklung-bodensee.de/) weitergemacht und ein paar coole Zeichenfunktionen eingebaut, mit denen das Levelbauen jetzt richtig viel Spass macht. Natuerlich kann ich dazu noch nichts zeigen, denn dann wuerde man ja was vom Spiel sehen
Aber ich freue mich schon, sofern das Spiel dann mal eines Tages fertig wird, auch ueber den Entwicklungsprozess zu sprechen und ein paar der internen Tools vorzufuehren
Ich arbeite ja zur Zeit an einem neuen Spiel, und habe dafuer auch vor einiger Zeit einen Leveleditor angefertigt in Python. Dort habe ich gestern bei unserem "42. Spieleentwicklertreffen" (https://spieleentwicklung-bodensee.de/) weitergemacht und ein paar coole Zeichenfunktionen eingebaut, mit denen das Levelbauen jetzt richtig viel Spass macht. Natuerlich kann ich dazu noch nichts zeigen, denn dann wuerde man ja was vom Spiel sehen
Aber ich freue mich schon, sofern das Spiel dann mal eines Tages fertig wird, auch ueber den Entwicklungsprozess zu sprechen und ein paar der internen Tools vorzufuehren
Klasse, da freue ich mich auf das Spiel und auf das Making-of!
Ich habe heute ein kleines BASIC Projekt fertig gemacht. Mein Ziel war es den Inhalt von mehreren SEQ Dateien in eine neue Datei im CSV Format zu schreiben um diese Dann z.B. in Excel verwursten zu können.
Das funktioniert auch soweit ganz gut. Allerdings fällt mir dann in der Datei auf, dass leere Felder zum Teil als NUL weggeschrieben wurden und zum Teil nicht.
Hier ein Screenshot aus Notpad++ wo man sehen kann was ich meine:
Ich lese die Daten aus dem SEQ Files in mehreren Schleifen wie folgt aus:
Daher würde ich jetzt erwarten, dass entweder überall ein NUL drin steht, oder gar nicht.
Hat jemand von euch eine Idee woran das liegen könnte ?
Das File lies sich jedenfalls in LibreOffice Calc ohne Gemecker einlesen...
Edit: beim drüber schauen habe ich ggf. den Fehler schon gefunden. Das liegt wohl weniger an der Einleseroutine als an dem PRINT# der die Daten ins neue File schreibt.
get#8,a$:a$=a$+chr$(0)
Damit hängst du an A$ ein CHR$(0) (also NUL) an. Das macht keinen Sinn.
Das macht man, wenn man mit ASC(A$) den Ascii-Code bestimmen will und nicht weiß, ob da ein CHR$(0) drinnen war (weil das GET# das überliest und dann A$ leer läßt).
Da du A$ aber direkt weiterverarbeitest schreibt du damit die NUL in die Ausgabe.
Lasse doch einfach das "+CHR$(0)" weg.
Je nachdem, was du machen willst, kann es auch sinnvoll sein, folgendes zu machen:
Entweder
oder
Beides macht das gleiche, wobei ich die untere Variante "eleganter", die obere Variante als wahrscheinlich schneller einstufe.
EDIT: Ach, Mist, ich hatte die Schreibroutine komplett übersehen. Damit ist das nicht korrekt.
Ich verstehe aber noch nicht genau, was du genau machen willst...
Ich glaube so ist es richtig:
Zum Hintergrund: Mein BBS schreibt täglich 10 Werte in eine SEQ Datei aus 10 verschiedenen Speicherstellen. Also quasi print#xx,peek(12345).
Wenn im Speicher also der Wert 9 drin stand, dann wird praktisch ein chr$(9) fortgeschrieben.
Jetzt gehe ich im nachhinein hin und lese diese SEQ Files wieder aus. Damit ich die Werte danach z.B. in einer Excel Tabelle verwenden kann, kann ich mit einem chr$(9) nichts anfangen. Ich will ja den Wert 9 haben.
Mein Denkfehler war, dass ich nicht dran gedacht hatte den Wert mit ASC in eine Zahl zu wandeln.
Aktuell läuft das Ganze noch einmal, es werden 365 Files eingelesen (pro Tag eins) und in ein neues File gepackt.
Mal sehen, wie das Ergebnis gleich ausschaut.
Edit: sieht schlecht aus. Illegal quantity Error. Arrrrghh.
Edit: sieht schlecht aus. Illegal quantity Error. Arrrrghh.
Hast du das "+CHR$(0)" rausgenommen? Da du jetzt ASC() nutzt muss das drinnen bleiben!
Um es richtig zu verstehen: Du willst den ASC-Wert dessen, was du ausgelassen hast, als String einer Dezimalzahl in die CSV schreiben, wobei du das führende Leerzeichen weglassen willst (deshalb das MID$())?
Wenn man's richtig macht dann funktioniert es auch
Junge, junge..... zum Teil sind im Array leere Strings. Die entstehen dadurch, dass ich beim Einlesen der Daten, falls die Einlesedatei nicht existiert, oder Fehler hat, weiter zum nächsten File (Tag) springe.
Das macht nachher beim ASC Probleme.... logisch.
Hier mal der komplette Sourcecode, falls Interesse besteht und jemand mal so was ähnliches machen will.
Das kann natürlich noch alles verfeinert werden mit mehr Sicherheits schick schnack etc. Für meinen Bedarf reicht das erst mal.
Nur nervt noch die Garbage Collection, die Pausenzeiten des Todes verursacht. Also besser VICE im Warp Mode laufen lassen....
Das Ergebnis exportiert vom Diskimage auf PC sieht dann so aus:
Und kann direkt in Excel / Calc eingelesen werden.
Wegen der GC: Wenn ich gerade nichts übersehen hast du doch 3 verschachtelte Schleifen (mm, dd, v), um die Daten in ein Array einzulesen, und dann drei verschachtelte Schleifen in der gleichen Reihenfolge, um die Daten wegzuspeichern.
Darüber hinaus werden die Elemente des Array auch jeweils nur ein einziges Mal benötigt.
Übersehe ich da auf die Schnelle etwas?
Falls ja, wieso packst du nicht alles (Lesen und Schreiben) in die gleichen Schleifen und arbeitest ohne Array? Dann hast du nicht so viele String-Variablen, so dass die GC deutlich schneller ist.
Ja hast Du Recht. Das macht Sinn.
Das Programm entstand zuerst mit der Idee 8 Zieldateien zu erstellen anstatt eine. Deswegen hatte ich mir überlegt, wie ich das am besten machen könnte.
Dann kam die Idee mit dem Array. Im Laufe der paar Stunden, die ich da dran gegrübelt habe, hatte ich dann die Idee mit 8 Zieldateien wieder verworfen. Eine reicht ja.
Warum 8 und nicht 10 -> 2 Werte sind jeweils Hi und Low Bytes einer Zahl.
Ich lasse das für mich jetzt erst mal so. Sind ja nur noch 2 Läufe für 2021er und 2022er Files. Danach hab ich 1 Jahr Ruhe hahaha...
Falls ja, wieso packst du nicht alles (Lesen und Schreiben) in die gleichen Schleifen und arbeitest ohne Array? Dann hast du nicht so viele String-Variablen, so dass die GC deutlich schneller ist.
Richtig, falls man das in einem Rutsch machen kann und die Daten sonst nicht zwischendurch braucht.
Die GC kann da schon ungut auffallen. Wenn man an der Array-Struktur festhalten möchte, wäre ja ein Float-Array auch möglich.
Dabei braucht man zwar 5 Byte/Wert statt 4 Byte/Wert (im String-Fall: 3 Descriptor im Array + Character am Heap).
D.h. ca. 23 KByte statt 18 KByte. Wenn man den Platz ohnehin hat ...
Bei 3-dimensionalen Arrays sollte man schon auf den Platzverbrauch schauen und berücksichtigen, dass das es auch einen 0 Index gibt.
Wenn man DIM(12,31,9) macht und dann den Index von 0 bis 9 gehen lässt, spart man sich schon 2 KByte und entsprechend, wenn man das bei den anderen Indizes auch macht (sollte einem der Speicher knapp werden).
Gerade am Anpassen von Football Manager in Richtung C16 (64k)...
EDIT: Die CPC-Version dient als Vorlage
Auf der Arbeit kam bei einer zuvor funktionierenden Excel Tabelle der Laufzeitfehler 80028029.
Public Sub ArbeitsblattUmschalten(sReitername As String)
Dim i As Integer
Dim Counter As Integer
Dim Name As String
Dim wkSheet As Worksheet
' Das hier funktioniert
For Each wkSheet In ThisWorkbook.Worksheets
Name = wkSheet.Name
If UCase(Name) = UCase(sReitername) Then
wkSheet.Activate
Exit Sub
End If
Next
' Das funktioniert nicht: Excel Laufzeitfehler 80028029
Counter = Sheets.Count
For i = 1 To Counter
Name = CStr(ThisWorkbook.Sheets(i).Name) ' <<< hier liegt das Problem
If Name = CStr(sReitername) Then
ThisWorkbook.Worksheets(sReitername).Select
Exit Sub
End If
Next i
End Sub
Dieser Fehler ist öfter im Internet zu finden, aber keine Lösung des Problems. Zumindest hatte bei mir nix davon funktionieren wollen.
Einen Tipp hatte ich ohne Nachdenken nachgemach und hatte als Ergebnis über fast alle Blätter einen #BEZUG Fehler.
Problem war im Grunde diese Zeile: ThisWorkbook.Sheets(i).Name
Diese Tabelle wird täglich von mir benutzt und die Makros laufen auch alle, aber plötzlich kam dieser Fehler. Wenn ich die anderen Beiträge im Web richtig verstanden habe, dann ist das ein Bug in Excel.
Nach einigem Rumtesten kam ich dann auf eine Lösung des Problems.
Zuhause wollte ich mit Excel was ausprobieren und brauchte Binärzahlen mit mehr als 11 Stellen. Nach fast 40 Jahren habe ich mich zum ersten mal näher mit der Umrechnung von BIN<>DEZ beschäftigt. Jetzt kann meine Tabelle Binärzahlen bis 128 Bit.
Weiter an meiner Tabelle zum Umrechnen von großen Zahlen BIN2DEZ und DEZ2BIN.
Scheinbar kann Excel Binärzahlen >128 Bit als Dezimalzahl darstellen, dann in der
Schreibweise als Zahl x 10 y. Beim umgekehrten Weg, also DEZ2BIN ist bei x 10 11
Schluss.
Das sollte aber für weitere Programmierexperimente ausreichend sein.
Nicht wirklich gecodet, aber wieder viel mit Excel rumgespielt.
Jetzt ist die Tabelle ~60MB groß und nun muss auch mein
16-Kern Threadripper Denkpausen einlegen.
Der Taskmanager sagt das Excel >800MB Speicher benötigt.
Und ich bin noch gar nicht fertig damit. Mal schauen wann
der Rechner, W10 oder Excel in die Knie geht.
Auf der Arbeit ne Exceltabelle erweitert. Die zeigt mir an wie
lange ich noch min. Arbeiten muss.
96 Monate.