Hello, Guest the thread was called9.3k times and contains 389 replays

last post from wweicht at the

DT128-Native-Copy Test für MegaPatch128

  • Denn ich habe habe es in der Zwischenzeit so angepasst, dass nur bei "nicht GEOS" die Lfw-Wechselfunktion nicht mit angeboten wird.

    und was ist, wenn ich gerade ein DNP im aktuellen Fenster offen habe, das UVs enthält. Dann müßte "nicht GEOS" das doch wieder mit anzeigen und ich kann es öffnen. Was passiert da dann?


    Eigentlich müsste doch die Routine danach dann MP3 verlassen und das "nicht Geos"-Programm versuchen zu starten (siehe Ergänzungen zum MegaAss-Handbuch der Bachmänner Kapitel T-B.14.9 ToBasic)....


    Gruß
    Werner


    PS: OK, habe es gerade probiert (mit TD V5.02). Das UV wird korrekt als neues Fenster geöffnet. UVs hier nicht anzuzeigen würde ich aber besser finden ;-) ....

  • und wofür dieser Aufwand?

    Damit es besser aussieht :bgdev .


    Rein theoretisch müßte das korrekte Öffnen des UVs an der Stelle auch ein paar Bytes "kosten" und vielleicht findet sich im Quellcode an der Stelle oder in der Nähe noch das eine oder andere Byte, das eingespart werden kann....
    Schick mir doch einfach mal den aktuellen Quellcode vom TD128. Vielleicht entdecke ich ja noch was.


    Gruß
    Werner


    Nachtrag: habe jetzt auch das Kopieren von gateWay-Treibern mit TD128 V5.02 probiert. Funktioniert tadellos. Und sehr gut: Sie lassen sich nicht starten! Klasse Arbeit!!!

  • Nach längerer Zeit findet Ihr im Anhang DT128 V5.03.


    - C=+Shift+E ist entfallen!

    - Den GEOS.Editor startet man jetzt per Klick auf den kleinen Bereich links der Lfw-Grafiken, da wo A: B: C: D: steht.

    - Per Home-Taste gelangt man bekanntlich zur 1. Directoryseite. Zur letzten gelangt man per Shift+Home-Taste.


    Pusti64

  • Was meinst Du mit Gummiband

    Wie beim GeoDesk64.

    Man kann einen Rahmen (Gummiband) um die Dateien ziehen, welche man kopieren will.

    UV'S kannst Du doch bereits damit kopieren.

    Ups, hab ich das nicht mitbekommen. :schande:

    Das ganze Unterverzeichnisse mit TD128 kopiert werden können.

    Also ich klick das UV an und leg es auf einem anderen LfW (welches UV unterstützt) ab, es wird das UV auf dem Ziel erstellt und der Inhalt kopiert.


    Gruss C=Mac.

  • Sorry, ich war jetzt total verkehrt. UV'S kann man noch nicht mit TD128 kopieren!

    Man... da hab ich ja jetzt völlig umsonst getestet ;)



    Aber was mir auch aufgefallen ist: Ich hab einige Verzeichnisse erstellt. Die tauchen aber in TopDesk nicht auf. In DualTop oder GeoDOS aber schon, d.h. die Verzeichnisse sind angelegt.


    Kann es sein das beim erstellen eines neuen Verzeichnisses das Ordner-Byte im Verzeichnis-Eintrag nicht gelöscht oder korrekt gesetzt wird? Ich hab hier ganz komische Werte in den beiden ersten Bytes eines Verzeichnis-Eintrages. Z.B. $A5 $04, Und da es keine Ordner gibt zeigt mit TopDesk die Dateien auch nicht an :(

    Wenn die Routine zum erstellen eines Verzeichnisses von GeoDOS oder GeoDesk übernommen wurde... die gehen von $00-Bytes an den ersten beiden Stellen aus. TopDesk müsste da entweder $00 oder die aktuelle Ordner-Nummer reinschreiben.


    Ist aber nur eine Vermutung...


    Hier mal ein ein Laufwerk in TopDesk/links und DualTop/rechts.


    Hier der erste Verzeichnis-Sektor, die Ordner-Bytes, die eigentlich $00 sein müssten (weil die UVs im Hauptverzeichnis ausserhalb eines Ordners erstellt wurden) sind invertiert...

  • Nachtrag:

    Ich konnte das Verhalten eben auch mit TopDesk 64 V4.1+ auf einem frisch angelegten GEORam-Native-Laufwerk nachstellen:

    -Neues RAMNative-Laufwerk einrichten.

    -Ordner erstellen...

    -Einige Dateien in den Ordner kopieren

    -RAMDisk löschen

    -Mehrere Verzeichnisse erstellen


    Die Verzeichnisse, die an der Stelle der zuvor in Ordner kopierte Dateien im Verzeichnis-Sektor angelegt werden, haben nach wie vor das Ordner-Byte im Verzeichnis-Eintrag und werden daher nicht angezeigt.

    Für die erste Datei #1 im Sektor ist es das Byte $0020 im Sektor, für jede weitere Datei jeweils das Byte vor der Dateityp-Kennung, also $0021 für Datei #2, $0041 für Datei #3 usw. Da muss beim erstellen eines neuen Verzeichnisses entweder eine $00 rein oder die aktuelle Ordner-Nummer.


    Wäre gut wenn VALIDATE das prüfen würde und nicht mehr vorhandene Ordner aus den Verzeichnis-Einträgen löscht.

  • Das Problem ließ sich recht einfach beheben und die neu erstellten UV's werden jetzt korrekt angezeigt.


    Gibt es noch weitere Probleme?

    Hängt mit dem vorherigen Problem zusammen: Ich hab einen Ordner geöffnet und wollte dort ein UV erstellen. Das landete im Hauptverzeichnis. Wenn Du das Ordner-Byte jetzt aber korrekt setzt, dann müsste das jetzt auch funktionieren.


    Mehr konnte ich bisher nicht testen...

  • Funktioniert auch.

    Fragt sich nur, wer sich so ein Durcheinander anlegen würde?

    Wenn man Ordner gewöhnt nutzt man das evtl. zum sortieren/gruppieren, keine Ahnung... ist mir halt so aufgefallen ;)


    Gibt es noch weitere Probleme?

    Noch etwas, das ist aber kaum der Rede Wert... ist mir nur aufgefallen weil ich von VICE oder TC64 verwöhnt bin was Geschwindigkeit angeht:

    1.RAMNative-Laufwerk öffnen, Ordner erstellen und öffnen...

    2.Laufwerk B (oder C/D) öffnen.


    Das 2te Laufwerk ist jetzt aktiv.

    Jetzt den aktiven Ordner auf dem 1sten Ordner mit einem kurzen Mausklick schließen. Da ich ungeduldig bin bewege ich die Maus schon für die nächste Aktion.

    Wenn der Ordner geschlossen wurde und sich die Maus jetzt auf einem anderen Eintrag im Fenster mit dem Ordner befindet, dann wird dieser automatisch geöffnet.

    Falls die Maus im Fenster ist ohne ein Eintrag in der Nähe flackert der Mauspfeil... bewege ich die Maus jetzt nur auf ein Icon -> Datei wird geöffnet, ohne das ich eine Taste gedrückt habe.


    Ich vermute mal da müsste man nach dem schließen des Ordners ":pressFlag" löschen nachdem mouseData wieder $80 ist (also Maustaste losgelassen). In etwa so:

    Code
    1. .WM_WAIT_NOMSEKEY
    2. lda mouseData ;Maustaste gedrückt?
    3. bpl WM_WAIT_NOMSEKEY ; => Ja, warten...
    4. ClrB pressFlag ;Tastenstatus löschen.

    Aber erst nachdem ein kurzer oder langer Klick erkannt wurde und der Order/das UV geschlossen wurde. Ist aber jetzt wirklich meckern auf hohem Niveau.


    Ansonsten hab ich nichts mehr feststellen können...:thumbsup:

  • keine Ahnung... ist mir halt so aufgefallen

    Ist auch nicht so wichtig. Ich finde es gut, dass Du auch Kombinationen getestet hast, für die Du aktuell keinen Anwendungsfall hast.


    :ilikeit: