letzter Beitrag von syshack am
HOL2001: Da hast Du mich aber eiskalt erwischt, das einfach umzuräumen während ich eine Antwort tippe Aber Danke für den eigenen Thread, der alte Thread-Titel hat mich schon die ganze Zeit gestört...
Hehe, sorry, war keine Absicht. Aber so ein Projekt wie deins verdient halt auch eine gesonderte Behandlung. 
ZitatJupp, bin das ganze mal umgekehrt angegangen, d.h. hab mir ein PRG erstellt, das in einem PRINT statement einfach alle Chars von 128 bis 255 hatte und hab das dann mal mit PetCat umgewandelt. Schon hatte ich eine vollständige Liste dessen, was ich erzeugen und verarbeiten kann
vorsicht.... guck dir lieber mal den source von petcat an, da stehen alle codes die petcat "versteht" in arrays drin... es gibt nämlich durchaus verschiedene varianten der gleichen codes die petcat bei der eingabe versteht - bei der ausgabe wird aber immer nur die "favourisierte" variante benutzt.
sinn macht das vor allem für die die auch mal was aus irgendwelchen magazinen abtippen wollen - die haben eben genau diese unterschiedlichen codes benutzt.
achja, und ansonsten bitte nicht zu sehr auf den output von petcat verlassen, vor allem nicht was die vollständigkeit der codes und das verhalten in diversen grenzfällen angeht. ich hab bisher *jedes* mal wenn ich mal petcat ernsthaft benutzt hab (was zugegebenermassen eher selten vorkommt) irgendeinen lustigen bug diesbezüglich gefunden 
und gefixt hab ich das dann auch immer nur so weit das es für das was ich grade machte reichte 
Kuhl, das Tool kommt mir gerade richtig. Werde ich gleich mal antesten. .NET rocks!
Und danke an den Mod, der dämliche Threadtitel ging mir schon lange auf den Sack.
Ein paar Anmerkungen, bitte als konstruktive Kritik auffassen
Bei den grafischen Dialogen (Disk-File-Auswahl, Font-Anzeige) wird das Bild immer zweimal aufgebaut, und auch nicht weltbewegend schnell. Du machst doch da nicht PutPixel-Aufrufe oder so was?
Auch das Hauptfenster leidet da bei mir stark drunter, ich bin da regelmässig bei 120ms. Das bremst auch die Cursor-Bewegungen stark aus. Und der Rechner ist wahrlich keiner der langsamen Sorte.
Upps, sehe grade von der Exception, du machst die Darstellung doch nicht im Timer-Handler? Immer nur Invalidate aufrufen, der Paint-Handler soll die Darstellung machen.
Der Disk-File-Auswahl-Dialog: Doppelklick zum Auswählen wäre praktisch. Generell wirkt der Dialog recht träge, evtl. durch den Grafikaufbau?
Der Zeilennummer<>Labelwechsel ist der Hammer! Da wünsche ich mir eigentlich nur noch, dass ich quasi eine Art Projekt-File speichern kann, damit die Labelbezeichnungen nicht immer flöten gehen.
Ich wollte mal Control-Rechts/Links testen, war ganz links in einer Zeile, da gab es eine Exception. Ctrl-Links und Rechts wäre superwichtig für mich, das bin ich von einem anständigen Editor gewöhnt
@Sauhund:
Genaugenommen wollte ich nie so viel Arbeit in diese ganze Petcat-Geschichte stecken, das hat sich irgendwie verselbstständigt... Eigentlich wollte ich nur irgendwelche kurzen Codeschnipsel mit ein paar <PRINT"{down}{down}HALLO"> einfach einfügen können, ohne hinterher die {down} von Hand ersetzen zu müssen.
Zur "Wirkungsweise" nochmal eine Erklärung: Im gewählten blablabla-tokens.txt File stehen jeweils {code}=Wert. Bei der Umwandlung von ASCII in Programmcode wird alles außerhalb von Anführungszeichen 1:1 übernommen, bei allem in Anführungszeichen wird diese Liste abgeklappert und bei einem passenden Code das entsprechende Ersatzzeichen genommen. d.h. man kann durchaus für ein und denselben Zielcode verschiedene Quellcodes haben:
Beim umgekehrten Weg wird der erste passende Code in die Zieldatei gesetzt, in diesem Falle würden alle Leerplätze durch {space} ersetzt werden.
Dann kann man noch einstellen, ob die {blabla} Codes case-sensitive sind, weil BasText wohl {a} für ein ungeshiftetes a erzeugt und {A} für ein geshiftetes. Da ist das dann blöd, wenn beim Einlesen erstmal alles in Uppercase umgewandelt wird. Andererseits its PetCat nicht case-sensitive, manchmal hat man Listings mit {clr} und manchmal {CLR}. Naja, usw, usw,... allein dieses Thema könnte ein ganzes Buch füllen, hab ich das Gefühl.
Da alles über die einstellbaren und frei editierbaren ASCII-Tokenfiles steuerbar ist, kann sich da jeder austoben. Wenn also irgendwer ein neues solches File erzeugt, darf er mir das gerne zukommen lassen, das wird dann in die Release-Suite mit aufgenommen
Endurion:
Komisch dass das bei Dir so langsam ist, ich entwickle auf einem ollen Core2Duo 2.1 GHz mit einer ATI 4350, sowie einem 2 GHz Celeron(!) mit einer uralten NVIDIA 7500LE, also alles beileibe keine Boliden. Und ich habe immer Aufbauzeiten von 3-4ms pro Zeile bzw. ca. 30-40ms für eine komplette Bildschirmseite.
Irgendwie scheint da BasEdit nicht mit Deiner Graphikkarte/Treiber zu harmonieren 
Das Invalidate hab ich wieder rausgeschmissen, das sorgt nämlich für ein unerträgliches Flackern weil dabei das Fenster automtisch ge-cleared wird, das ging gar nicht. Ich mache kein PutPixel, sondern ein DrawImageUnstretched, das funzt eigentlich sonst überall ganz prima.
Im MainWindow hab ich tatsächlich einen Timer, der sich um den Bildschirmaufbau kümmert. Das hat sich so ergeben, weil das Invalidate unbrauchbar war und ich einen anderen Weg gesucht habe. Insgesamt ist das GDI+ nicht das schnellste, allerdings bist Du bisher der Einzige, der solche Probleme hat.
Das Flackern und mehrfach Aufbauen habe ich immer dann, wenn ein anderes Programm/Fenster in den Vordergrund kommt bzw. mein MainWindow überlappt. Da kollidieren dann meine Timer-Aufrufe und das System-bedingte Invalidate.
Wenn Du in Programm im Label-Mode bearbeitest, speicherst Du das am Besten als PETSCII. Das kannst Du dann auch wieder laden und alles ist gut. Wenn Du das dann auf der echten Maschine bzw. im Emulator laufen lassen willst, speicherst Du es einfach als PRG-File, das wird dann automatisch wieder in den Zeilennummern-Mode zurückgewandelt. Bei F5 (Save&Run) sogar vollautomatisch im Hintergrund.
Control-Links und Rechts schaue ich mir mal an, eigentlich benutze ich die auch ständig und die sollten auch funktionieren... Da fehlt wieder irgendwo eine Abfrage auf "Nicht am Anfang der Zeile" oder so, .NET mit seiner Stringbehandlung ist da extrem pingelig, nicht so vergebend wie Basic V2.
Ist es eigentlich schon zu spät den Editor mit einem UI auszustatten, den es unter möglichst vielen Systemen gibt?
Kurz und bündig: Ja.
Momentan hab ich auch einfach zu viele andere Baustellen, als dass mich das reizen würde Sorry für alle, die deswegen außen vor bleiben müssen...
Wofür auch ne UI, das Editor-Fenster bietet recht viel über die Kontext-Menüs, finde das jetzt nicht sonderlich umständlich.
Ist es eigentlich schon zu spät den Editor mit einem UI auszustatten, den es unter möglichst vielen Systemen gibt?
Wozu? Die allermeisten Systeme sind sowieso WinDoof ...
Kurz und bündig: Ja
Momentan hab ich auch einfach zu viele andere Baustellen, als dass mich das reizen würde
Schade, aber danke für deine ehrliche Antwort.
Wäre sowas aus deiner Sicht den überhaupt anstrebensam oder sieht du dort keine Motivation auch in Zukunft Anstrengungen zu unternehmen?
Wofür auch ne UI, das Editor-Fenster bietet recht viel über die Kontext-Menüs, finde das jetzt nicht sonderlich umständlich.
Mir ging es nicht um das äußere, denn das ist ja Geschmackssache. Es ging um die Portierbarkeit auf andere Systeme. Das .Net existiert ja nur unter Windows....
Wozu? Die allermeisten Systeme sind sowieso WinDoof ...
Dazu werd ich jetzt mal nichts sagen. Danke für dein qualifizierte Antwort.
Nana, jetzt keinen OS-Streit hier in meinem schönen Thread 
Wie ich weiter oben schonmal erwähnte, war eine frühe Version wohl unter Mono lauffähig, falls jemand Zeit und Lust hat, kann er gerne mal probieren, ob das immer noch gilt. Wenn das geht wäre es natürlich prima
Neue Version 1.28 hochgeladen:
Ok, das ist jetzt hoffentlich meine letzte Änderung zum ASCII-Export... Upper-/Lowercase Characters werden jetzt erwartungsgemäß umgesetzt, sowohl innerhalb als auch außerhalb von Anführungszeichen. Ebenso werden "unübersetzbare" Zeichen, also diese ganzen Graphik-Sonderzeichen etc. außerhalb von Anführungszeichen einfach 1:1 weggeschrieben, innerhalb von Anführungszeichen wird erst nach einer Übersetzung {blabla} gesucht. Falls gefunden, wird die genommen, falls nicht, wird das Zeichen wieder 1:1 weggeschrieben. Und damit mir das .NET Framework nicht wieder dazwischenpfuscht, schreibe ich das jetzt alles byteweise in eine Datei, dann erhält man auch nicht mehr lauter ? für unbekannte Zeichen. Klappe zu, Affe tot.
Falls Ihr einfach nur einen Quelltext im Label-Mode sichern udn später wieder laden wollt, bitte nicht als ASCII, sondern als PETSCII-Datei speichern! Die speichert die Datei 1:1 ohne irgendwelche Schickimickis ab, da geht nix verloren...
bei der Übergabe einer aus einem Diskimage zu ladenden Datei direkt bei Programmstart wird jetzt der Name dieser Datei auf die gleiche Weise umgesetzt, wie ich das auch beim Laden von Basic-Quellcodes mache. Das bedeutet eine datei, die auf der Disk im Standard-zeichensatz "FILE01" heißt wird als "file01" übergeben - ungeshiftete Zeichen. Über Großbuchstaben in Dateinamen in Diskimages lass ich mich hier nicht weiter aus, die sehen als ASCII-Zeichen wüst aus. Mein Tipp: Macht Euch ein Arbeits-Diskimage, benennt die Dateien streng nach der Regel das nur die Zeichen "a"-"z" und "0"-"9" drin vorkommen und alles wird gut. Ein hübsches Directory könnt Ihr ja später mit beliebigen Tools basteln
Danke für das Feedback. Der Rechner, auf dem es lahmt, war mein dicker Arbeitsbolide im Büro. Das ist so ein Dell XPS irgendwas. Auf jeden Fall nicht gerade die untere Hälfte. Interessanterweise flutscht das auf meinem lahmen Krüppel zuhause einwandfrei (GeForce FX 5500). Muß mal den Geier fragen... vielleicht weiß er das?
Wenn du das nachverfolgen willst, ich helfe gern beim Debuggen (hab im Büro diverse Visual Studios drauf).
Endurion: Na da bin ich aber froh, dass das wohl eher ein Einzelfall zu sein scheint. bei PCs ist das mit der Eingrenzung ja immer schwierig, da können Virenscanner, irgendwelche anderen Hintergrundprogramme, ein unglücklicher Graphiktreiber oder sonstwas Schuld sein. Wahrscheinlich fühlt sich mein 8-Bit-Basic-Editor auf Deiner Monstermaschine einfach unwohl 
Falls mir mal 'ne coole Testsuite dafür einfällt, um meinen BasEdit auf diversen Rechnern zu checken, komme ich gern auf Dich zurück, momentan bin ich allerdings eher ratlos.
Ach ja, hab vorhin nochmal eine neue Version 1.29 hochgeladen:
Das war auch so ein Drama, Vice macht merkwürdige Bit-Shiftereien mit Dateinamen, die man an ein Diskimage ranhängt, um aus einem ASCII-Dateinamen einen CBM-kompatiblen Dateinamen zu machen. Aber mein Tester hat mir jetzt versichert, dass das mit normalen, geshifteten und gecommodorten Zeichen geht, sogar ein Farbcode in einem Dateinamen wurde korrekt durchgereicht. Das Thema schließe ich hiermit auch ab.
Nachtrag: Hab jetzt auch den Fehler beim wortweisen Springen nach links mittels Strg-Links gefunden. Passiert nur im Label-Mode bzw. wenn man vor der Zeilennummer noch Spaces hat, da gerate ich dann in eine Fast-Endlosschleife, die irgendwann in einem Integer-Überlauf bei -2 Mrd und ein paar Zerquetschte endet. Zum Glück sind die PCs heutzutage schnell genug, dass das tatsächlich auftritt. Ab der nächsten Version (1.30) behoben.
Mensch Schlowski,
gute arbeit, du hast ja noch einige bugs gefunden und behoben
die ich nie gesehn haette zum ersten weil ich nie oder selten mit
d64 disks rumhantiere zum andern das ich dann doch auf das petscii
format umgestiegen bin 
(gerade wegen dem label mode der da
mitgespeichert wird)
trozdem werde ich deine relaeses weiter testen und vorkommende
bugs melden
salute Haubitze
Einen hätte ich noch:
Wäre supersuperklasse, wenn man beim Label-Modus auch längere Variablennamen benutzen könnte. Die dann beim Zurückwandeln in zwei-Zeichen umgewandelt würden. Dann könnte man im Entwurfmodus übersichtlichere Variablennamen benutzen.
Naja, benutzen kannst Du sie schon, sie werden nur nicht automatisch gekürzt -> verschwendeter Basic-Speicherplatz...
Außerdem, um das Feature sinnvoll zu unterstützen, müsste man auf doppelte Namen prüfen um bei sowas wie TEST=5 und IF TEIL=3 THEN... warnen zu können, dass TEST und TEIL beide zu TE werden. Da steckt noch ein bisschen mehr dahinter, ansonsten ist das Ganze fehlerträchtiger als nützlich, weil sich jeder darauf verlässt, dass die Variablen ja schön zurückgekürzt werden. Aber dran gedacht hab ich auch schon
Aber in dem Zusammenhang schwebt mir auch noch sowas wie IF..THEN..ELSE vor, oder DO..LOOP oder WHILE...WEND, d.h. ein paar Konstrukte, die sich beim Zurückwandeln vom Label in den Line# Mode auch noch sehr schon durch ein paar clever zusammengebaute Basic V2 Befehle ersetzen lassen.
So viele Ideen, so wenig Zeit...
Außerdem, um das Feature sinnvoll zu unterstützen, müsste man auf doppelte Namen prüfen um bei sowas wie TEST=5 und IF TEIL=3 THEN... warnen zu können, dass TEST und TEIL beide zu TE werden. Da steckt noch ein bisschen mehr dahinter, ansonsten ist das Ganze fehlerträchtiger als nützlich, weil sich jeder darauf verlässt, dass die Variablen ja schön zurückgekürzt werden. Aber dran gedacht hab ich auch schon
ich würde die einfach in einer tabelle sammeln, und dann beim wandeln in richtigen basic text einfach der reihe nach durch AA, AB, AC usw ersetzen (wie der richtige basiccode am ende aussieht ist ja wurscht)
Wie sauhund sagt. Also nicht einfach kürzen, sondern eindeutige neue Variablen neu erzeugen. Ist halt ziemliche Einbahn, von kurz auf lang macht nicht wirklich Sinn.
Zuerst dachte ich: "Ist doch blöd, dann kann man den Basic-Code gar nicht mehr verstehen." Aber nach ein bisschen Nachdenken stimme ich Euch zu, der Basic-Quelltext, der dann rauskommt ist eigentlich egal, weil in dem eh niemand mehr rumändern soll. Und wenn ich meine anderen Ideen auch noch verwirkliche, haben wir eh keine 1:1 Hin- und Rückübersetzungen mehr...
Ok, ist auf meiner wachsenden ToDo-Liste
