GEOS MegaPatch V3 Release 2018

Es gibt 1.222 Antworten in diesem Thema, welches 218.920 mal aufgerufen wurde. Der letzte Beitrag (2. Juli 2025 um 17:17) ist von darkvision.

  • Nachtrag:

    im DS 8 (Hautdatensatz ist 1) gibt es auch noch einen Änderung von Flag_SetColor (am Anfang bei Offset a2). Die muß auch noch verhindert (sta $9fd0 durch 3x ea ersetzen) werden.

    Ansonsten schreibt TD auch noch auf andere System-Einstellungen, z.B. Farbe ab $9fea. Aber das ist erstmal nicht so schlimm ... :wink: .

    Gruß

    Werner

    Wäre es denn nicht am einfachsten, das Farbe An/Aus-Icon und die Funktion dahinter zu entfernen? :wink:

    Pusti64

  • am einfachsten, das Farbe An/Aus-Icon und die Funktion dahinter zu entfernen? :wink:

    Die einfachsten Lösungen sind nicht immer die besten :wink: .

    Denn dann hätten wir ja immer noch das Problem, dass TD einfach so die System-Farben ändert.

    Zunächst habe ich mal einen Patch (PatchSystem) erstellt, der die von mir beschriebene Änderung im TD128 V5.0 vom 28.12.2021 durchführt (kommt anbei als D64). Patch 1 macht die Änderung, Patch 2 macht die Änderung wieder rückgängig. Aber bitte aufpassen, es findet keinerlei Prüfung statt (also keinerlei Garantie für nichts :wink: )

    Ich habe es schon erwähnt, bevor wir da wirklich ran gehen (TD ändern) brauchen wir eine Möglichkeit, die MP3-System-Farben (22 Bytes ab $9fea) ändern zu können.

    Dann erstmal die Farb-Einstellung in TD aufräumen. Man könnte z.B. das erste Lfw.-Fenster aus "$9ff6" oder "$9ff7" nehmen. Die Dialog-Box-Einstellung (die obere) z.B. aus $9fef oder $9ff0 ...

    Mich beschleicht mehr und mehr das Gefühl, ich habe seit dem Erscheinen von MP3 noch nie alle MP3-Standard-Farben gesehen, weil TD da immer schon "reinpfuscht" ... :wink:

    Gruß

    Werner

  • Hallo,

    zunächst mein Patch ist nicht für die Algemeinheit :wink: . Er soll zunächst einmal nur testen, ob und wie die Änderung wirkt. Was die Sache bei mir besser (noch nicht gut :wink: ) macht, kann ja bei Anderen irgendwelche Probleme verursachen. Es ist also "nur ein Test" ....

    Das wollte ich nur noch einmal klar stellen.

    Ich habe mir den "veralteten" Quellcode von TD jetzt nochmal etwas genauer angesehen. Dabei habe ich im Quelltext "...H" 2 und im Quelltext "...M" 4 Stellen gefunden, wo mir nicht ganz klar sind ob störend oder nicht....

    Auf jeden Fall wird da in den System-Bereich von MP3 (Farben) gespeichert.

    Gruß

    Werner

  • Ich habe es schon erwähnt, bevor wir da wirklich ran gehen (TD ändern) brauchen wir eine Möglichkeit, die MP3-System-Farben (22 Bytes ab $9fea) ändern zu können.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Quick&Dirty... Auf die Schnelle einfach den Editor von GDOS als extra AutoStart-App umgesetzt, der Farbfächer unter GEOS128 80Z ist leider nicht sortiert, aber als ColorPicker reicht das erstmal aus. Ist eigentlich für 40Z... aber scheint auch unter 80Z zu funktionieren. Man kann die App auch vom DeskTop starten.

    Die Farben werden direkt in MP3_COLOR_DATA geändert und beim beenden im Infoblock der AUTOEXEC-Datei gespeichert. Sollte in 40Z und 80Z funktionieren. Ein Problem ist definitiv das es für 80Z und 40Z unterschiedliche Farben gibt, im Infoblock aber nicht ausreichend Platz ist. Daher speichert das Programm nur die aktuellen Werte für den aktuellen Screen und kopiert die beim Start wieder zurück nach MP3_COLOR_DATA. Man sollte also die AutoExec für 80Z nicht in die AutoExec für MP-64 kopieren.

    Sollte auch unter MP3-64 funktionieren, aber nicht unter GDOS64 (weil Farben in der INI im RAM/REU gespeichert werden).

    Falls das Programm weiterhilft kann ich da gerne noch die eine oder andere Stunde an Zeit investieren, ist jetzt aber erstmal nur eine Notlösung...

    Hier mal ein paar Screenshots aus MP3-128/80Z mit angepassten Farben.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Unter MP3-64:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das übliche kleingedruckte: Alles ohne Gewähr, Benutzung auf eigenes Risiko ;)

  • Kleine Anmerkung:

    Der Wert in GEOS/Dateiauswahlbox -> Systemicons ist zwar in der Farbtabelle definiert, GEOS/MP3 verwendet aber die Farbe für GEOS/Dialogbox-Systemicons. Die Menüicons im Editor werden aus C_WinIcon ausgelesen, im TaskManager sind die Farben für die Icons aber fest einprogrammiert.

    Müsste ich mir in MP3 mal anschauen was man da ändern kann...

  • Anbei r02 von MP3ColEdit:

    * Sortierte Farben für 80Z im ColorPicker

    * Sortierte Liste der MP3-Farbregister

    * Anzeige der MP3-Registeradresse

    * Farbflag im Infoblock für Bootvorgang ergänzt (Farben werden nur eingelesen wenn Modus 40/80Z stimmt)

    * Infoblock-Button ergänzt (ließt die im Infoblock gespeicherten Farben ein)

    Der Wert C_Mouse wird aktuell im MP3-Kernal nicht verwendet, in r01 war der ausgeblendet, der Vollständigkeit wegen wird der jetzt in der Liste der Farben angezeigt. Warum der Doppelt enthalten ist kann ich heute nicht mehr sagen...

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Anbei r02 von MP3ColEdit:

    Frei nach dem Motto "Unmögliches wird sofort erledigt, Wunder dauern etwas länger" :wink: hat darkvision wieder mal zugeschlagen. Danke! :thumbsup::dafuer::thnks:.

    So wie ich das sehe, funktioniert das wie gewünscht :wink: .


    Ich finde aber, die Anzeige ist etwas suboptimal:

    - Anfangs habe ich mich gewundert, warum kein Balken bei der Auswahl erscheint. Dann begriff ich, daß das alles zusammengehört. Allerdings sollte die Anzeige der Adresse/Erklärung etwas vom Auswahlfenster abgesetzt werden (Linie dazwischen oder extra Fenster)

    - die Icons "Standard-Farben" und "InfoBlock" sollten kurz blinken, damit man sieht, es passiert etwas

    - insgesamt die Anzeige bei MP3-128 auf 80-Zeichen-Darstellung aufblasen

    - das Programm zur Applikation machen, die AUTO_EXECs erzeugt, die die Farben laden . Dann könnte man verschiedene Farbeinstellungen im Vorrat haben ud bräuchte nur die kleinen AUTO_EXECs austauschen...

    Nur so kurz meine Vorschläge :wink: .

    Gruß

    Werner

    PS: und nicht vergessen, die Anleitung (Teil D, S. 473) anzupassen. Der Editor sollte dort erwähnt werden. Aber da kommt ja vielleicht noch eine Änderung wegen der Aussagen über TD :wink: (mal sehen was wird ...)

  • - Anfangs habe ich mich gewundert, warum kein Balken bei der Auswahl erscheint. Dann begriff ich, daß das alles zusammengehört.

    Ist halt für Dich neu... in GDOS64 ist das schon länger so... ;)

    - die Icons "Standard-Farben" und "InfoBlock" sollten kurz blinken, damit man sieht, es passiert etwas

    Auch das ist ein Feature das es in GDOS64 schon gibt, denn da gibt es weitaus mehr Icons die man anklicken konnte und die bisher kein visuelles Feedback gegeben haben. Ich hab das jetzt in MegaPatch übernommen, braucht aber noch ein paar weitere Tests.

    Allerdings sollte die Anzeige der Adresse/Erklärung etwas vom Auswahlfenster abgesetzt werden (Linie dazwischen oder extra Fenster)

    Hab ich anders umgesetzt, da im 40Z-Modus ich ja an die Cards der C64-Grafik gebunden bin.:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Mit dem Vorsatz "Info" und der anderen Hintergrundfarbe hebt sich das von der Farbwahl ab. Aber Danke für den Tipp.

    - insgesamt die Anzeige bei MP3-128 auf 80-Zeichen-Darstellung aufblasen

    In gar keinem Fall. Man sieht ja schon bei den bisherigen Register-Menüs das ein stupides verdoppeln der Menüs nur dazu führt, das zwar ein größerer Bereich des Bildschirms belegt wird, aber nicht mehr Informationen angezeigt werden. Auch die Dateiauswahlbox ist ein schlechtes Beispiel dafür. Für den 80Z-Modus müsste man eher eigene Menüs definieren, ein einfaches verdoppelt sieht einfach Sch... aus. In MP3 ist das schon immer so, daran werde ich nichts mehr ändern. Und im neuen GEOS.ColorEditor werde ich keine getrennten Versionen entwickeln. Das ist mir den Aufwand für eine getrennte 80Z-Version nicht mehr Wert... Der Source-Code ist aber seit heute online, jeder kann das Tool forken und getrennte UIs für den 40Z- und 80Z-Modus einbauen. In MegaPatch bleibt das so, auch weil das ein Menü ohne DOUBLE_W ist und ich damit einen weiteren Bug fixen konnte. Ist also eher eine Testsuite für die Programmierer-Schnittstelle von MegaPatch ;)

    PS: und nicht vergessen, die Anleitung (Teil D, S. 473) anzupassen. Der Editor sollte dort erwähnt werden. Aber da kommt ja vielleicht noch eine Änderung wegen der Aussagen über TD :wink: (mal sehen was wird ...)

    Teil D ist ein Handbuch für Programmierer... nicht für Anwender. Der Editor muss daher dort nicht erwähnt werden. Aber ich werde vorsorglich den TopDesk aus dem Text rausnehmen. Im übrigen ändert auch die StandAlone-Version von GeoDesk64 die Systemfarben beim Start. Ich hab zumindest den Sourcecode so geändert, das die aktuellen Farben importiert werden, bevor ein Farbprofil geladen wird. Im anderen Fall kann man ja das Farbprofil anpassen.

    Der nächste Snapshot wird dann auch getrennte Farben für System-Icons in Dateiauswahlbox und Dialogbox ermöglichen. Die entsprechenden Routinen verwenden jetzt die System-Farben.

    Ansonsten gab es in MegaPatch ein paar Fehlerkorrekturen, im besondern zu dem von WW gemeldeten Bug mit DB_DblBit. Das betraf auch die Dateiauswahlbox. Sollte jetzt behoben sein, kann aber dazu führen das bestehende Anwendungen, die sich auch DB_DblBit verlassen bzw. selbst verändern, nicht mehr korrekt funktionieren. Muss ich weiter testen...

    Aus meiner Sicht sollte keine Anwendung DB_DblBit anpassen. In MegaPatch erfolgt das ein Einzelfällen trotzdem, da ältere Anwendungen sich evtl. darauf verlassen.

    Im Register-Menü wurde eine Erweiterung von GDOS64 übernommen:

    - die Icons "Standard-Farben" und "InfoBlock" sollten kurz blinken, damit man sieht, es passiert etwas

    Das geht jetzt in MegaPatch automatisch... für darauf angepasste Anwendungen immer, für ältere Anwendungen gibt es im GEOS.Editor eine angepasste Option zum Menü/Icon-Status. Ist die Option für Icons aktiviert, dann blinkt ein Icon im Register-Menü auch dann, wenn es in der Anwendung nicht explizit angefordert wurde.

    Für Register-Menüs, die nicht mit der Verdopplungstechnik arbeiten, war es bisher ein Problem wenn Checkboxen verwendet wurden. Die wurden im 80Z-Modus immer verdoppelt und waren dann doppelt so breit wie das Optionsfeld.

    - das Programm zur Applikation machen, die AUTO_EXECs erzeugt, die die Farben laden . Dann könnte man verschiedene Farbeinstellungen im Vorrat haben ud bräuchte nur die kleinen AUTO_EXECs austauschen...

    Hatte ich mir überlegt. Aber wie viele Versionen hat man davon auf der Bootdisk? Bei AutoExecs würden die ja immer auch automatisch geladen und gestartet. Auch einzelne Datenfiles müssten ja entweder eine eigene Routine mitbringen um die Farben zu installieren oder der Editor müsste das erledigen. Im Editor bin ich aber bei der Menü/Icon-Blinken-Optionen schon an die Speichergrenzen gestoßen.

    Ich hab mich dann für die AutoExecs entschieden. Den neuen ColorEditor kann man auf der Bootdisk duplizieren und in jeder Version eigene Farben einstellen. Über die neuen AutoLoad/AutoSave-Buttons kann man einstellen ob die Einstellungen aktualisiert werden sollen. Das braucht zwar etwas mehr Speicher, aber der Aufwand ist geringer. Und eigentlich war der ColorEditor ja nur ein Hack um euch die Anpassung des TopDesk zu erleichtern ;)

    In MegaPatch (Editor, TaskMan, Spooler) sollten jetzt alle Icons die Systemfarben verwenden. Damit sollten sich fast alle Farben/Icons usw. anpassen lassen. Auch hier sind weitere Tests/Feedback erforderlich.

    Ich teste jetzt noch etwas weiter... dann gibt es neue Snapshots... und eigentlich wollte ich am Wochenende nur das MegaAssembler-Handbuch querlesen... ;(

  • Hallo,

    Bei AutoExecs würden die ja immer auch automatisch geladen und gestartet.

    Nicht unbedingt :wink: .

    Für Geos gab (gibt) es "AntiExec", für MP3 seit 2019 "ExitAutoBoot_MP3". Hier der Link dahin: Bitte melde dich an, um diesen Link zu sehen.

    Allerdings sollte die Anzeige der Adresse/Erklärung etwas vom Auswahlfenster abgesetzt werden

    Hab ich anders umgesetzt,

    Oder eben so, sieht auf jeden Fall besser (eindeutiger) aus.

    - das Programm zur Applikation machen, die AUTO_EXECs erzeugt,

    Man könnte auch Daten-Files (nur die Farb-Codes) speichern, die das Programm beim Start einliest. Man legt einen Namen fest, der vom Programm gelesen wird. Und schon kann man mehrere Daten-Files auf Disk haben. Zum Wechseln müßten die betreffenden nur umbenannt werden ....

    Den neuen ColorEditor kann man auf der Bootdisk duplizieren und in jeder Version eigene Farben einstellen.

    Und das funktioniert? :wink: Ich habe da andere Erfahrungen.

    2 Programme mit gleicher Klasse und unterschiedlichen Namen kann man auf Disk haben. Aber wenn ich das 2. Programm starte, dann wird immer das erste auf Disk geladen. Da da nach der Klasse der Datei gesucht wird ....

    Habe das gerade nochmal im aktuellen MP3-128 probiert: BootTrans (kopieren von Dateien automatisch beim Booten) dupliziert und in der neuen Version eine andere Datei-Liste eingestellt (für ganz schlaue :wink: : das 2. BootTrans war für die Erstellung der Datei-Liste auf einer anderen Disk). Beim Booten wird 2x die 1. Liste geladen: Das 2. Programm wird garnicht geladen. :wink:

    Also muß man dann auf jeden Fall die Reihenfolge der Dateien auf Disk ändern...

    Gruß

    Werner

  • Und das funktioniert? :wink: Ich habe da andere Erfahrungen.

    Schon getestet... geht problemlos... sicherlich wäre es auf Deine Art und weise einfacher, aber dafür braucht es ja eine SaveFile-Routine, einen Infoheader, eine Routine zur Eingabe des zu ladenden Farbprofiles. Das alles braucht auch Speicher. Wenn man nicht gerade vor hat vier oder mehr Farbprofile auf der Disk zu haben, dann ist das einfache duplizieren genauso Speicherintensiv.

    Ich gehe aber eh nicht davon aus das die Nutzer ein Dutzend Farbprofile erstellen und die alle auf der Bootdisk haben wollen. Am Anfang vielleicht eine Lustige Spielerei, aber am Ende richtet man sich ein Farbprofil ein und das wars dann. Alternativen kann man auf einer extra-Disk vorhalten.

    Bei GDOS64 ist das was anderes, das kann ja beim booten ein Farbprofil passend zu einem zufällig gewählten Hintergrundbild laden. Da kann es durchaus Sinn machen zu einem Dutzend Wallpaper auch ein Dutzend Farbprofile auf der Disk zu haben. Ich glaub aber kaum das jemand dieses Feature nutzt...

    Über AutoSave und AutoLoad kann man ja steuern ob das Profil angewendet werden soll oder nicht (ohne ExitAutoBoot...) und wenn man AutoSave abschaltet, dann kann man nach dem Start über den Reload-Button das Farbprofil anwenden. Automatisch anwenden hatte ich eingebaut, aber dann könnte man nicht zwischendurch mal nur eine einzelne Farbe ändern.

    Da da nach der Klasse der Datei gesucht wird ....

    Wer macht denn sowas? Ich nicht ;)

    Also muß man dann auf jeden Fall die Reihenfolge der Dateien auf Disk ändern...

    Nö... ich hab da zusätzliches geheimes Wissen was das unnötig macht ;)

    Die Autoren des MegaAssembler-Handbuchs haben zwar zur Routine GetFile einen halben Roman geschrieben, aber etwas wichtiges vergessen: Da GetFile im Anschluss z.B. LdApplic aufruft und LdApplic in r9 einen Zeiger auf den Verzeichniseintrag erwartet, ist eigentlich klar das nach GetFile (nach dem internen Aufruf von FindFile) in dirEntryBuf der Verzeichniseintrag der gestarteten Datei liegt. Dort kann man sich den Infoblock rausnehmen, dann muss man nicht selbst nach der Datei suchen was dann zu den von Dir beschriebenen Problemen führt.

    GetFile setzt intern r9 direkt auf dirEntryBuf, LdApplic lädt dann den InfoBlock nach fileHeader. Damit muss man nicht mal den Infoblock einlesen, die Farbdaten liegen praktischerweise dann schon ab $81xx im Speicher (ich verwalte die Farbdaten im Infoblock, daher geht da auch nur ein Farbprofil für 40Z oder 80Z, nicht beides...). Alternativ könnte man die Farbdaten auch in der Anwendung am Anfang im Speicher halten, dann wäre ggf. Platz für 40Z+80Z, aber dann verschenkt man noch mehr Speicher: Im Infoblock gibt es ja extra reservierte Bytes für Programmdaten.

    Ich lese den Infoblock aber trotzdem ein und vergleiche die GEOS-Klasse, falls mal eine DeskTop-Oberfläche auf die Idee kommt die Datei auf andere Art und Weise zu laden und zu starten als über GetFile. Ist nur zur Absicherung...

    Auch die AutoBoot-Routine macht das ähnlich, wobei das Verzeichnis durchgeblättert wird, der Eintrag ggf. nach dirEntryBuf kopiert wird und dann über LdApplic die Anwendung gestartet wird. dirEntryBuf/fileHeader sind dann entsprechend vorbereitet.

    Zu GetFile werde ich noch was dazu ins Handbuch packen.

    Ich hab die beiden Buttons jetzt durch größere Icons ersetzt. Die könnte ich in der Breite doppeln, damit die nicht so gestaucht aussehen. Dann wäre aber kein Platz mehr Text. Und dann wäre die Optik wieder unterschiedlich. Ich glaub ich lasse das jetzt so und mach die Snapshots fertig...

  • Ich hab jetzt einen neuen Snapshot hochgeladen und den unter MP64/128 und de/en installiert. Auch die paar Dialogboxen und Registermenüs die ich getestet hab scheinen optisch unverändert zu sein. Aber vor allem Dialogboxen im 80Z-Modus sollte man sich genauer anschauen ob alle Icons die richtige Breite haben.

    Damit sollte für Programmierer das manuelle setzen von DB_DblBit durch eine Anwendung im Vorfeld unnötig werden, da DoDlgBox sowohl für normale Dialogboxen als auch für die Dateiauswahlbox das Bit immer überschreibt.

    Das der neue GEOS.ColorEditor zugegeben etwas gewöhnungsbedürftig ist, ich aber keine weitere Zeit mehr damit vergeuden will für ein Programm, das evtl. kaum jemand nutzen wird ;) , hier eine kurze Anleitung und am Ende auch ein paar Beispieldateien:

    Nach der Installation ist der GEOS.ColorEditor noch nicht initialisiert, d.h. beim ersten Boot-Vorgang passiert nichts, da noch keine Farbinformationen im Programm gespeichert wurden.

    Man muss das Programm also mind 1x vom DeskTop aus starten. Beim Start wird dann geprüft ob gültige Farbdaten im Programm gespeichert sind. Dabei wird zum einen der Bildschirm-Modus (40/80-Zeichen) getestet und ob die gespeicherten Farbwerte <>0 sind.

    Wenn keine Farben gespeichert sind oder der Bildschirm-Modus nicht kompatibel ist, dann werden die aktuellen Farben von MegaPatch in den Zwischenspeicher übernommen und der Anwender bekommt das Menü angezeigt, um einzelne Farben zu ändern.

    Wenn die Farben bzw. der Bildschirm-Modus gültig ist, dann wird ebenfalls das Menü angezeigt, allerdings kann man jetzt über den Reload-Button die im Programm gespeicherten Farben einlesen und anwenden oder man passt nur einzelne Farben im System an.

    Über des Reset-Button (X) kann man die Standard-MegaPatch-Farben einstellen.

    Beim beenden des Programms gibt es zwei Möglichkeiten:

    Beenden:AutoSave ist aktiviert. In dem Fall werden die Farbeinstellungen im Programm gespeichert, und zwar alle Farben die aktuell in MegaPatch eingestellt sind.

    Beenden:AutoSave ist deaktiviert. In dem Fall wird das Programm nur beendet und die gespeicherten Farbeinstellungen im Programm werden nicht verändert.

    Letzteres bietet sich daher an, wenn man alle Farben eingestellt hat und man nicht möchte das die Farbeinstellungen evtl. überschrieben werden.

    Beim nächstem Systemstart wird dann wieder geprüft ob die gespeicherten Farbeinstellungen gültig sind bzw. ob der Bildschirm-Modus kompatibel ist. Ist das der Fall werden die Farben in MegaPatch übernommen.

    Im Menü kann man allerdings durch die Option GEOSBoot:AutoLoad regeln, ob das Profil angewendet werden soll. Deaktiviert man die Option, dann muss man weder den Dateityp von "AutoExec" auf "Anwendung" ändern oder über Zusatztools die Ausführung des Programms beim Start unterbinden. Soll das Farbprofil beim nächsten Start nicht angewendet werden, dann GEOS.ColorEditor starten und beide Optionen (AutoLoad und AutoSave) deaktivieren. AutoSave sollte deshalb deaktiviert werden, weil sonst die aktuellen Farben automatisch übernommen werden, obwohl man nur den AutoStart abschalten will.

    Beim beenden des Programms wird immer versucht die beiden Optionen AutoLoad und AutoSave im Programm zu speichern, unabhängig davon ob AutoSave aktiv ist oder nicht. AutoSave bezieht sich nur auf die Farbeinstellungen.

    Damit beim nächsten Update von MegaPatch der ColorEditor nicht überschrieben und damit alle Farbeinstellungen wieder gelöscht werden, empfiehlt es sich das Programm umzubenennen, z.B. in GEOS.MyColors. Das Programm ist nicht an eine bestimmte Version von MegaPatch gebunden, und wird dann nach einem Update auch weiterhin funktionieren. Durch den geänderten Dateinamen wird es auch nicht durch das Update überschrieben.

    Im Anhang ein D64 mit ein paar Farbdateien, für den 40Z bzw. 80Z-Modus. Die Dateien sind aber so eingestellt das diese beim Start nicht automatisch angewendet werden und auch Änderungen nicht automatisch speichern. Einfach unter MP64 oder MP128 starten und über den Reload-Button (die zwei runden Pfeile) aktivieren und das Programm beenden. Die Beispiele ändern nur temporär die Systemfarben, beim nächsten Bootvorgang ist alles wieder auf Standard.

    Will man eine Farbeinstellung beim Bootvorgang aktivieren dann auf die Bootdiskette kopieren, Programm starten und "GEOSBoot:AutoLoad" aktivieren und das Programm beenden, fertig.

    Oder, wenn die gewünschten Farben aktiv sind, einfach den GEOS.ColorEditor von der Bootdiskette starten und gleich wieder beenden. Wenn "Beenden:AutoSave" aktiviert ist (Standard) dann übernimmt das Programm die aktuellen Einstellungen in die Boot-Konfiguration.

    Die Beispiele kann man auch unter älteren Snapshots verwenden, allerdings braucht es den neuen Snapshot um die verschiedenen Farben für Icons in Dialogboxen und Dateiauswahlboxen zu ermöglichen. Im 80Z-Modus kann bei älteren Snapshots zusätzlich noch ein Bug im Registermenü sichtbar werden (falsche Breite der Checkbox-Icons).

    Wie weiter oben beschrieben wird der GEOS.ColorEditor mit seinen gespeicherten Farbeinstellungen beim nächsten Update überschrieben. Wenn die Datei umbenannt wird bleiben die Einstellungen auch nach einem Update erhalten.

    Und zumindest aktuell ist es noch so das TopDesk und GeoDesk die Farben ändern. GeoDesk-Nutzer können allerdings auf den GEOS.ColorEditor verzichten, da ist die Farbwahl ja im Programm eingebaut ist und als extra Farbprofil-Datei (mit zusätzlichen Informationen) gespeichert werden kann. Für GDOS-Nutzer ist das ebenfalls nicht notwendig, da die Farben in der INI-Datei gespeichert werden und die Angaben aus dem GEOS.ColorEditor immer überschreiben würden.

  • Hallo,

    Ich hab jetzt einen neuen Snapshot hochgeladen

    Danke. :thumbsup:

    Habe bisher nur 1x MP3-128 deutsch (auf WinVice 3.6.1; auf FD-2000 (1581-Format)) installiert. Installation lief problemlos.

    Festgestellt habe ich bis jetzt 2 Probleme unter TD 128 (aktuelle Version). Bin aber nicht sicher, ob das mit MP3 oder TD zu tun hat :wink: :

    1. Datei - Info

    Hier ist das Schließen-Icon oben etwas nach rechts verschoben. Das kann aber auch mit einer falschen Koordinate in TD zusammenhängen (8 Pixel Raster bei Farbe). MP3 verschiebt ja automatisch, wenn da was nicht stimmt ...

    2. Menü Speziell - Farbe ändern

    Hier sind die benutzerdefinierten Icons (Standard, Farbe aus, Farbe an) jetzt scheinbar 2x (doppelt) vergrößert.

    Auch das könnte an TD liegen. TD arbeitet ja überwiegend in 80-Zeichen. Habe mich schon immer gefragt, warum da im Quellcode zumindest teilweise über DOUBLE_B, DOUBLE_W und/oder ADD1_W verdoppelt wird.

    Beides trat in der "alten" MP3-Version nicht auf.


    Mehr, wenn ich mehr getestet habe ... :wink:

    Gruß

    Werner

  • Beides trat in der "alten" MP3-Version nicht auf.

    Kann sein das beides von den TD-Entwicklern damals über DB_DblBit "gepatcht" wurde. Wenn die Icons schon doppelt so breit sind, dann müsste das DOUBLE-Bit raus. Oder man halbiert die Buttons in der Breite und setzt das DOUBLE-Bit. Das würde ein paar Bytes einsparen, aber evtl. ist es einfacher DOUBLE-Anweisungen rauszunehmen, wenn nicht unbedingt erforderlich (weil eh nur 80Z). Die Verdopplung der Icons wird über r3H, also die X-Koordinate der Dialogbox erkannt. Dort das Bit rausnehmen und die echte Koordinate reinsetzen, dann sollte es passen.

    Damit war zu rechnen, und es dürfte wie in MegaPatch (TaskManager z.B.) sein das man um die bisherigen Fehler drumherum gearbeitet hat. Die Fehler in Dialogboxen ohne Schatten bzw. einige Buttons in der Dateiauswahlbox traten auch in älteren Snapshots auf, die hat man jetzt nicht mehr. Dafür müsste man die "Hacks" in anderen Anwendungen rausnehmen. TD war ja mal auch für 40Z, daher das ganze DOUBLE usw.

    Das mit dem Infobox-Icon ist mir auch aufgefallen, das Farbenmenü schau ich mir mal an. Wenn das so die einzigen Baustellen wären würde ich die Anwendung anpassen, denn einen Fix der sowohl die Probleme im alten und die Probleme im neuen Snapshot beseitigt dürfte es nicht geben.

    Im aktuellen Snapshot gibt es jetzt zumindest kein unerklärliches Verhalten mehr (wie z.B. bei deinem OK-Box-Demo, das unter dualTop beim ersten Start funktioniert und danach nicht mehr und in TopDesk nie funktioniert hat...).

  • Das mit dem Infobox-Icon ist mir auch aufgefallen,

    Das ist ja nachträglich (durch Pusti64 ) in den TD gekommen (sieht irgendwie besser aus :wink: ). Hatte noch nicht die Zeit, aber es sieht verdammt danach aus, daß an dieser Stelle bei den x-Koordinaten nicht auf 8x8-Raster geachtet wurde.

    Aber jetzt wird erstmal MP3-64 installiert ....

    Gruß

    Werner

  • Hier sind die benutzerdefinierten Icons (Standard, Farbe aus, Farbe an) jetzt scheinbar 2x (doppelt) vergrößert.

    OK, läßt sich hier nachvollziehen. Hab mir die Definitionstabelle angeschaut, die arbeitet nicht mit DOUBLE_W, setzt aber über DB_USR_ROUT nach Aufbau der Box DB_DblBit und überschreibt damit den Systemwert. Wären die drei Icons nur in halber Größe gezeichnet (wie OK und CANCEL) dann würde es passen. Der Screenshot zeigt die Box ohne Verdopplungstechnik. Vermutlich hat man damals deswegen das manuelle Überschreiben von DB_DblBit eingebaut... den sowas ähnliches gab es auch im TaskManager.

    Da werde ich mir was überlegen müssen wie man das zuverlässig erkennen kann ohne Tausch gegen die anderen behobenen Fehler. Das Problem ist das mischen von gedoppelten Icons und nicht gedoppelten Icons in einer Dialogbox die nicht gedoppelt wird und durch das manuelle überschreiben von DB_DblBit nach Aufbau der Box....

  • Hallo,

    OK, läßt sich hier nachvollziehen. Hab mir die Definitionstabelle angeschaut, die arbeitet nicht mit DOUBLE_W, setzt aber über DB_USR_ROUT nach Aufbau der Box DB_DblBit und überschreibt damit den Systemwert.

    Mach mal langsam :wink: .

    Ich halte nicht so viel davon, daß Fehler in anderen Programmen durch ein neues System "umgangen" (quasi gepatcht) werden. Dann lieber das fehlerhafte Programm ändern (notfalls erstelle ich für das Icon-Problem einen Patch für TD, bis das endgültig gelöst ist) oder wir lassen es erstmal so, funktionell gibt es ja keine Probleme ...

    Und genau an dieser Stelle sollte/wird wohl sowieso geschraubt werden müssen (ich hoffe auf die Hilfe von Pusti64 ). In meinem Kopf stelle ich mir das etwa so vor :wink: :

    - Links das oberste Icon (Fenster1) kann raus. Kann durch C_WinBack erschlagen werden

    - Mitte die obere DB-Schaltfläche kann raus. Kann durch C_DBoxBack erschlagen werden

    Übrigens: zumindest bei TD128 ändern die "Dialogbox" und die "Fehlerbox" NICHT permanent den DB-Hintergrund. Das läuft so ab: Wert aus MP3-Farbtabelle lesen und auf dem Stack sichern, Farbwert auf hellblau oder rot setzen, Dialogbox aufbauen und nach Abbau der DB wird sofort der ursprüngliche Farbwert wieder aus dem Stack in die System-Tabelle geschrieben.

    - Ganz oben das TD-Menü kann als Schaltfläche raus. Kann durch C_PullDMenu erschlagen werden

    - ob "Farbe aus" und "Farbe an" raus können/sollten, wird sich zeigen müssen :wink: ...

    In dem Zusammenhang können dann auch die 3 Icons "repariert" werden. Ich plädiere für Bild verkleinern. Und man hat wieder einiges an Speicherplatz zurück gewonnen. Da muß sowieso im gesamten TD gehandelt werden. Da kommen bestimmt 1-3 kB zusammen, die TD kleiner werden könnte .....


    Ansonsten (MP3 64/128 ist jetzt auch auf C128 installiert) bisher keine weiteren Probleme aufgetreten. Gute Arbeit. :thanx:

    Gruß

    Werner

  • Mach mal langsam :wink: .


    Ich halte nicht so viel davon, daß Fehler in anderen Programmen durch ein neues System "umgangen" (quasi gepatcht) werden.

    Ich auch nicht... aber wenn das hier der Fall ist dann kann das Problem auch noch in anderen Applications auftauchen.

    Das eigentliche Problem ist ja nicht TopDesk (die DialogBox hat zwar einen seltsamen Aufbau, aber es ging ja bisher), sondern das ich eine Änderung eingebaut hatte die zu kleine Icons verhindern sollte, so wie hier:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Der gegenteilige Effekt ist bei Deinem OK-Demo aufgetreten, da TopDesk DB_DblBit gesetzt war irgend wann das Bit 7 in der OK-Icon-Tabelle gesetzt und dann wird das OK-Icon immer verdoppelt. Eigentlich müsste Deine DBox so aussehen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Die Box nutzt kein DOUBLE-x, allerdings hat bisher jeder Dialogbox das DOUBLE-Bit direkt in den Kernal-Tabellen für das OK-Icon gesetzt, und wenn es einmal gesetzt ist wird es immer gedoppelt.

    Ich hab jetzt den Code etwas angepasst das nur bei Systemicons wieder das DOUBLE-Bit geODERt wird, aber vorher immer ein Bit 7 gelöscht wird. Damit passt Dein OK-Demo (denn richtig ist es mit der halben Größe), die TopDesk-Dialogbox und das Problem mit der GetFiles-Box ist auch behoben...

    Wirklich sauber wäre aber nur eine Dialogbox im 80Z-Modus mit Systemicons welche die Dialogbox selbst verdoppelt und auch die Position der Systemicons verdoppelt. Die Breite wird dann automatisch geregelt. User-Icons können dann ohne Verdopplung arbeiten, dürfen also mit doppelter Breite erstellt werden.

    Ohne Verdopplung muss man den Trick mit DBUSRROUT und DB_DblBit anwenden (so macht es TopDesk), was aus meiner Sicht Falsch ist den DB_DblBit ist ein internes Register von DoDlgBox, die Adresse könnte sich ja ändern oder ganz wegfallen.

    Ich teste das noch etwas... dann gibts einen BugFix...

  • Aus meiner Sicht, kann das auch komplett weg. Denn ich persönlich habe das z.B. nie genutzt und glaube auch kaum, dass das hier jemand braucht.

    Pusti64

  • glaube auch kaum, dass das hier jemand braucht.

    Einspruch :wink: .

    Das erste wenn eine neuer TD erscheint ist, die Farbeinstellungen für die 4 Lfw.-Fenster zu ändern. Mir gefallen die grauen Linien nicht. Die müssen schwarz sein.

    Und es könnte auch andere geben, die z.B. mehr oder weniger Kontrast wollen/brauchen und das über diese Einstellungen realisieren. Ein wenig Anwender-Einstellung muß schon sein .... :wink:

    Gruß

    Werner

  • Ich dachte, das geht jetzt über den GEOS128.EDITOR bzw. mit dem GEOS.ColorEditor???

    Pusti64