Programm testen - amiga-news.de Forum

amiga-news.de Forum > Amiga, AmigaOS 4 > Programm testen

[ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2-

[ - Beitrag schreiben - ]

28.01.2008, 22:37 Uhr

ZeroG
Posts: 1487
Nutzer

@Ralf27:
Ne, das wars leider noch nicht.
Jetzt schepperts woanders, siehe 68k-Stacktrace. Oben fängt dein Programm an, dann gehen die folgenden Funktionsaufrufe nach unten weiter. Am ende erfolgt dann ein lesezugiff auf einen Nullzeiger in der rtg.library.

Zitat:
Crash log for task "WBSudoku1.5.0"
Generated by GrimReaper 52.3
Crash occured in module at address 0x7F5713D0
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 016DA720 6812432C 6812433C 00000000 68768E54 00000001 680C7548 00000000
8: 6812432C 7F5713B8 980840AF 00000001 00000004 68124334 0144ACB4 0001A224
16: 6A39C000 69693B50 688927F0 0144A8A4 00000000 683FCCB8 680C74F9 00000190
24: FFFFFFFF 00000005 BBC2B938 00000000 68768E54 68899008 68768004 68769810

FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 0 0
4: 0 0 0 0
8: 0 1.67772e+07 1e+61 1e-59
12: 1.45833 1e-05 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 1e+61 1e-59 0.5 4.5036e+15
28: nan 65536 1.67772e+07 0

FPSCR (Floating Point Status and Control Register): 0x00000000

SPRs (Special Purpose Registers):
Machine State (msr) : 0x0000F030
Condition (cr) : 0x22000000
Instruction Pointer (ip) : 0x7F5713D0
Xtended Exception (xer) : 0x20000000
Count (ctr) : 0x01450224
Link (lr) : 0x7F5713B8
DSI Status (dsisr) : 0x40000000
Data Address (dar) : 0x00000000

680x0 emulated registers:
DATA: 00000000 68768E54 680C74F9 00000190 FFFFFFFF 00000005 BBC2B938 00000000
ADDR: 690C75E0 680C7548 68768E54 68899008 6812433C 68768004 68769810 68124330
FPU0: 0 0 0 0
FPU4: 0 0 0 0

Symbol info:
Instruction pointer 0x7F5713D0 belongs to module "" (HUNK/Kickstart)

Stack trace:

68k Stack trace:
683fccb6 (68k IP) - "WBSudoku1.5.0" Hunk 0000 Offset 00000cae (SegList: 1a0ff001)
683fccba - "WBSudoku1.5.0" Hunk 0000 Offset 00000cb2 (SegList: 1a0ff001)
01e41cf6 - "Kickstart/dos.library.kmod" Hunk 0001 Offset 00000772
01688034 - "Kickstart/rtg.library" Hunk 0000 Offset 00020b50
0156ce14 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00025b70
0156ce98 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00025bf4
0157011c - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00028e78
0167ade4 - "Kickstart/rtg.library" Hunk 0000 Offset 00013900

68k disassembly:
683fccae: ffa0 linef
683fccb0: 2c5f movea.l (sp)+,a6
683fccb2: 2e00 move.l d0,d7
683fccb4: 2007 move.l d7,d0
*683fccb6: 4eab97e8 jsr -0x6818(a3)

[ - Antworten - Zitieren - Direktlink - ]

28.01.2008, 22:38 Uhr

NoImag
Posts: 1050
Nutzer

@ Ralf27:

So, ich habe jetzt nochmal etwas ausführlicher getestet. Dabei sind mir folgende Dinge aufgefallen:

1) Bei einem 16er Feld (alle getesteten Skins) gibt es massive Grafikfehler und zwar sowohl unter AGA als auch CGFX auf der WB und einem eigenen Screen.
2) Im Optionen-Menü sind noch massive Probleme mit mutual exclusive (dazu im nächsten Beitrag mehr) drin:
- Punkt "Hilfen" sind die Unterpunkte verknüpft obwohl es keinen Sinn macht
- bei "neue Felder" funktioniert die Verknüpfung nicht so wie sie sollte.
- "immer eigener Screen" und "nur wenn Skin zu groß" schließen sich nicht gegenseitig aus
- bei "Programm" funktionieren die Verknüpfungen auch nicht richtig

Des Weiteren ist mir aufgefallen:
- "Feld selbst füllen" lässt sich nicht abbrechen (weder übers Menü, noch über Commodities Exchange)
- Das Fenster sollte sich zentriert in der Mitte der WB öffnen.
- die Screenauswahl sollte WBSudoku sich zumindest bis zum Programmende merken

Außerdem habe ich zwei Fragen:
- Was macht "alle Felder aufdecken"? Oder hatte ich zu wenig Geduld?
- Was macht "eindeutige Spielfelder"?

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

28.01.2008, 23:15 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Ralf27:

Zitat:
- Menüpunkte, die ein Fenster öffnen, sollten mit "..." enden (Styleguide-Empfehlung).
Hm, ich frag mich eben wo ich das Einfügen könnte.

Die Punkte gehören in die Texte (bei Englisch ohne, bei Deutsch mit Leerzeichen vom eigentlichen Text getrennt), also in den Katalog.

Zitat:
Zitat:
- Tastaturabkürzungen für die Menüs (geht einfach mit Gadtools)
Ich benutzte Gadtools und hab die Option bereits drin, aber noch nicht im Programm nach außen hin eingefügt.
Da ist auch fraglich, wie ich das am besten machen könnte, bzw. wo ich welche Abkürzungen nehmen könnte, oder ob ich das ganze gar noch Konfigurierbar machen könnte.

Für einige Befehle gibt es Standard-Abkürzungen, z.B. N für Neu, L für Laden, S für Speichern.
Die Texte dürfen auf keinen Fall konfigurierbar sein und sollen auch bei allen Sprachen gleich sein (Styleguide-Empfehlung). Der Hintergrund ist, dass jeder das Programm auf jedem Amiga gleich bedienen kann, ohne umlernen zu müssen. Diese Empfehlung gilt allerdings nur für die Menüs, nicht für Gadgets in Requestern.

Zitat:
Zitat:
- Im Skin-Menü sollte angezeigt werden, welcher Skin gerade ausgewählt ist (wie bei den Optionen).
Steht bereits im Fenstertitel. Vielleicht kann man noch einen Haken davorsetzen.

Genau das meinte ich. Es geht auch nicht darum, dass diese Information nicht verfügbar ist, sondern dass das Skinmenü eingentlich eine Auswahl bietet.

Zitat:
Zitat:
- Im Optionen-Menü eine Trennlinie zwischen verschiedenen zusammengehörigen Einstellungen verwenden (geht einfach mit Gadtools).
Welche könnte ich da zusammen fassen?

Trennlinien würde ich im Untermenü "Neue Felder" zwischen "Feld selbst füllen" und "Einsteiger", bei "Größe" zwischen "eindeutige Spielfelder" und "4er", bei "Programm" zwischen "nur Screen wenn Skin zu groß" und "Sound" einfügen. Bei Drucken bin ich mir nicht sicher (ich weiß nicht, was die Bedeutung der Einstellungen ist), aber vor "voreingestellte Auflösung" kommt mir sinnvoll vor.

Zitat:
Zitat:
- Du scheinst bei den Optionen immer "mutual exclusive" zu verwenden, auch da, wo es überflüssig ist.
Was meinst du damit, bzw. was ist das?

Wie bei den Druckknopfgadgets können auch bei den Menüs Auswahlpunkte zusammengefasst werden, dass sie sich gegenseitig ausschließen. Wenn Du also den einen Punkt auswählst, dann wird ein anderer derzeit ausgewählter Punkt deselektiert. Im Optionen-Menü hast Du bei allen Auswahlpunkten diese Option gewählt, wobei aber praktisch nichts so funktioniert, wie es sollte (siehe meinen vorherigen Beitrag). Die Bits, die Du in der NewMenu-Struktur in nm_MutualExclude angibst, sind wohl noch fehlerhaft. Bei Menüpunkten, die nicht nm_MutualExclude nutzen (also für sich alleine stehen) muss in den Flags MENUTOGGLE gesetzt sein. Ich hoffe, dies ist nun klarer.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

29.01.2008, 20:37 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von NoImag:
@ Ralf27:

So, ich habe jetzt nochmal etwas ausführlicher getestet. Dabei sind mir folgende Dinge aufgefallen:

1) Bei einem 16er Feld (alle getesteten Skins) gibt es massive Grafikfehler und zwar sowohl unter AGA als auch CGFX auf der WB und einem eigenen Screen.

Ja, aber nur bei dem Standard16er, die anderen laufen bei mir hier richtig. Ich muß mal denn Standard16er korrigieren. Aber auch der 4er ist so sehr fehlerhaft. Liegt auch hier am Skin. Die Skins, die man separat runterladen kann, laufen.

Zitat:
2) Im Optionen-Menü sind noch massive Probleme mit mutual exclusive (dazu im nächsten Beitrag mehr) drin:
- Punkt "Hilfen" sind die Unterpunkte verknüpft obwohl es keinen Sinn macht

Inwiefern? Ich kann da kein Fehler entdecken.

Zitat:
- bei "neue Felder" funktioniert die Verknüpfung nicht so wie sie sollte.

Mir ist leider auch aufgefallen das das DirScan-Problem einiges am System und auch an der Menustruktur durcheinanderwürfelt. Im aktuellen Archiv ist auch das Programm *ohne* Dirscan enthalten.

Zitat:
- "immer eigener Screen" und "nur wenn Skin zu groß" schließen sich nicht gegenseitig aus

Eigentlich schon. "immer eigner Screen" ist ja immer.

Zitat:
- bei "Programm" funktionieren die Verknüpfungen auch nicht richtig

Wo genau?

Zitat:
Des Weiteren ist mir aufgefallen:
- "Feld selbst füllen" lässt sich nicht abbrechen (weder übers Menü, noch über Commodities Exchange)

Ja, hm. Ist noch eine kleine Baustelle. Versuch einfach mal irgend eine Taste zu drücken, dann sollte es weitergehn. Muß ich wirklich mal umbauen.

Zitat:
- Das Fenster sollte sich zentriert in der Mitte der WB öffnen.

Beim ersten öffnen, ja. Das kann man noch einbauen.

Zitat:
- die Screenauswahl sollte WBSudoku sich zumindest bis zum Programmende merken

Das ist so eine Sache:
Die Skins sind unterschiedlich groß und auch die Farbtiefe kann unterschiedlich sein. Gerade mit dem Customchipsatz sollte man immer denn passenden Screen auswählen. Außerdem kann man denn ausgewählten Screenmod dem jeweiligen Skin zuweisen, bzw. wird das dann in die entsprechende .dat-Datei des Skins geschrieben.

Zitat:
Außerdem habe ich zwei Fragen:
- Was macht "alle Felder aufdecken"? Oder hatte ich zu wenig Geduld?

Also, das Programm generiert ein Spielfeld, aber öffnet keine Felder. Mann kann dann auswählen welche Felder angezeigt werden sollen. Kann man aber auch als Baustelle bezeichnen...

Zitat:
- Was macht "eindeutige Spielfelder"?

Das bezieht sich auf die Spielfelder die aufgedeckt werden. Wenn "eindeutige Spielfelder" aktiviert wird, dann deckt das Programm die Felder so auf, das man das Spielefeld logisch und eindeutig lösen kann. Ist diese Option nicht aktiviert, dann öffnet das Programm die Spielfelder ohne darauf zu achten das man das Spielfeld eindeutig lösen kann. Es wird dann wesentlich schwieriger. Bzw. es gibt immer nur eine Lösung, aber der Weg dahin ist schwerer.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

29.01.2008, 22:13 Uhr

Ralf27
Posts: 2779
Nutzer

Hab eben die Skinfehler bei Standard9 und Standard16 beseitigt. Aber leider kann ich es gerade nicht hochladen, da der Server nicht die ganze Datei annimmt?!? Kann wohl noch etwas dauern...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

30.01.2008, 21:09 Uhr

Ralf27
Posts: 2779
Nutzer

Die aktuelle Version ist oben. Im Archiv ist eine Version ohne DirScan. Die mit ist leider als noch Fehlerhaft...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

31.01.2008, 16:44 Uhr

DaxB
Posts: 1421
Nutzer

Die MuForce Hits beim starten sind hier mit der neuen Version noch vorhanden.

Ich würde es besser finden, wenn beim download ein Fenster erscheint und wenn fertig sich beendet und nicht wie jetzt umgekehrt.

[ - Antworten - Zitieren - Direktlink - ]

31.01.2008, 23:09 Uhr

NoImag
Posts: 1050
Nutzer

@Ralf27:

Ich habe jetzt nochmal mit der DirScan-freien Version getestet. Der größte Teil der von mir beobachteten Probleme mit dem Optionen-Menü sind darauf zurückzuführen, dass irgendetwas die Menüs zerschießt. Dies ist jedoch nicht das DirScan! Die Probleme treten auch mit der DirScan-freien Version auf, allerdings abhängig davon, was sonst noch so läuft.

Was mir weiterhin beim Optionen-Menü aufgefallen ist:
- Es schein so, dass Du nirgendwo nm_MutualExclude benutzt. Stimmt das? Wenn ja, dann solltest Du das ändern.
- Wenn man z.B. von Einsteiger auf Schwer wechselt und die Frage nach einem neuen Spielfeld verneint, dann wird der Haken vor der alten Einstellung nicht gelöscht, es befindet sich aber auch vor der neuen ein Haken. Dies gilt für jeden Schwierigkeitsstufenwechsel.
- Wenn man "immer eigener Screen" wählt, dann wird der Haken vor "nur wenn Skin zu groß" nicht gelöscht (und umgekehrt).

Zitat:
Zitat:
1) Bei einem 16er Feld (alle getesteten Skins) gibt es massive Grafikfehler und zwar sowohl unter AGA als auch CGFX auf der WB und einem eigenen Screen.
Ja, aber nur bei dem Standard16er, die anderen laufen bei mir hier richtig. Ich muß mal denn Standard16er korrigieren. Aber auch der 4er ist so sehr fehlerhaft. Liegt auch hier am Skin. Die Skins, die man separat runterladen kann, laufen.

Nicht nur der Standard-16er hat Grafikfehler. Der Geo16 erzeugt massig Enforcer-Hits, wenn der Cursor zur Auswahl einer Zahl oberhalb der 1 (und damit zur Hälfte im Fensterrahmen) steht. Dies ist normalerweise zu Beginn der Fall. Der Cursor selbst ist dabei Grafik-Müll. Der Standard16 erzeugt bei mir keine Enforcer-Hits. Die Tetris16 und Smiley16 funktionieren.

Zitat:
Zitat:
- die Screenauswahl sollte WBSudoku sich zumindest bis zum Programmende merken
Das ist so eine Sache:
Die Skins sind unterschiedlich groß und auch die Farbtiefe kann unterschiedlich sein. Gerade mit dem Customchipsatz sollte man immer denn passenden Screen auswählen. Außerdem kann man denn ausgewählten Screenmod dem jeweiligen Skin zuweisen, bzw. wird das dann in die entsprechende .dat-Datei des Skins geschrieben.

Ich verstehe das Problem und die Konfigurationsmöglichkeit ist gut. Mit einer Grafikkarte ist es aber lästig, wenn ohne vorherige Konfiguration bei jedem Skin-Wechsel auf Interlace geschaltet wird (was bei mir passiert). Vielleicht kannst Du ja abfragen, ob ein Grafikkarten-Screen eingestellt wurde und in diesem Fall den Screen-Mode beibehalten.

Die Version mit DirScan hat bei mir beim Start zwei Enforcer-Hits Byte-Read auf 00000000.

Trotz allem ein schönes Programm!

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 10:55 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von NoImag:
@Ralf27:
Ich habe jetzt nochmal mit der DirScan-freien Version getestet. Der größte Teil der von mir beobachteten Probleme mit dem Optionen-Menü sind darauf zurückzuführen, dass irgendetwas die Menüs zerschießt. Dies ist jedoch nicht das DirScan! Die Probleme treten auch mit der DirScan-freien Version auf, allerdings abhängig davon, was sonst noch so läuft.

Frage an Ralf27:
Du benutzt doch nicht etwa mit SADD() ermittelte String-Adressen für die Erzeugen der Menüs?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 14:41 Uhr

DaxB
Posts: 1421
Nutzer

Die Hits beim starten mit der ohne DirScan Version treten nicht auf. Mit DirScan das selbe wie bei NoImag.

[ Dieser Beitrag wurde von DaxB am 01.02.2008 um 14:43 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 14:51 Uhr

MaikG
Posts: 5172
Nutzer

>Du benutzt doch nicht etwa mit SADD() ermittelte String-Adressen
>für die Erzeugen der Menüs?

Ich glaub das kennt er schon.

Für die Problemerklärung allerdings logisch:
Flüchtige Strings -> Recursives aufrufen einer Function ->
Low Stack ->Garbage Collection -> Strings weg -> Hit

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 21:23 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von NoImag:
@Ralf27:

Ich habe jetzt nochmal mit der DirScan-freien Version getestet. Der größte Teil der von mir beobachteten Probleme mit dem Optionen-Menü sind darauf zurückzuführen, dass irgendetwas die Menüs zerschießt. Dies ist jedoch nicht das DirScan! Die Probleme treten auch mit der DirScan-freien Version auf, allerdings abhängig davon, was sonst noch so läuft.

Da ist mir eben ein Problem aufgefallen: Ich hab vorher denn Speicher mit MEMF_CLEAR aufgefordert und das immer, wenn ich ein Menu aufbauen wollte, wa sich jetzt nicht mehr mache. Jetzt forder ich einmal Speicher an (der auch größer ist für andere Programmteile) und gebe ihn nur noch am Schluss frei. So kann es vorkommen das schon Werte im Speicher stehn. Hab ich eben korrigiert, aber noch nicht hochgeladen.

Zitat:
Was mir weiterhin beim Optionen-Menü aufgefallen ist:
- Es schein so, dass Du nirgendwo nm_MutualExclude benutzt. Stimmt das? Wenn ja, dann solltest Du das ändern.

Hab ich wirklich noch nicht. Hab ich bis jetzt auf Null gelassen. Ich hab in denn Autodocs bis jetzt leider noch keine Verständliche Infos dazu gefunden. Im Internet bin ich etwas fündig geworden (allgemeine Beschreibung), aber wie ich das genau anwende....

Zitat:
- Wenn man z.B. von Einsteiger auf Schwer wechselt und die Frage nach einem neuen Spielfeld verneint, dann wird der Haken vor der alten Einstellung nicht gelöscht, es befindet sich aber auch vor der neuen ein Haken. Dies gilt für jeden Schwierigkeitsstufenwechsel.
- Wenn man "immer eigener Screen" wählt, dann wird der Haken vor "nur wenn Skin zu groß" nicht gelöscht (und umgekehrt).

Ja, das werd ich heute beides ändern.

Zitat:
Zitat:
Zitat:
1) Bei einem 16er Feld (alle getesteten Skins) gibt es massive Grafikfehler und zwar sowohl unter AGA als auch CGFX auf der WB und einem eigenen Screen.
Ja, aber nur bei dem Standard16er, die anderen laufen bei mir hier richtig. Ich muß mal denn Standard16er korrigieren. Aber auch der 4er ist so sehr fehlerhaft. Liegt auch hier am Skin. Die Skins, die man separat runterladen kann, laufen.
Nicht nur der Standard-16er hat Grafikfehler. Der Geo16 erzeugt massig Enforcer-Hits, wenn der Cursor zur Auswahl einer Zahl oberhalb der 1 (und damit zur Hälfte im Fensterrahmen) steht. Dies ist normalerweise zu Beginn der Fall. Der Cursor selbst ist dabei Grafik-Müll. Der Standard16 erzeugt bei mir keine Enforcer-Hits. Die Tetris16 und Smiley16 funktionieren.

Hm, da hab ich wohl noch einiges an arbeit vor mir. Denn wie es aussieht muß ich dann wirklich alle übergebenen Daten, die ich von den Skin.dat bekomme, komplett und weitergehend überprüfen.

Zitat:
Zitat:
Zitat:
- die Screenauswahl sollte WBSudoku sich zumindest bis zum Programmende merken
Das ist so eine Sache:
Die Skins sind unterschiedlich groß und auch die Farbtiefe kann unterschiedlich sein. Gerade mit dem Customchipsatz sollte man immer denn passenden Screen auswählen. Außerdem kann man denn ausgewählten Screenmod dem jeweiligen Skin zuweisen, bzw. wird das dann in die entsprechende .dat-Datei des Skins geschrieben.
Ich verstehe das Problem und die Konfigurationsmöglichkeit ist gut. Mit einer Grafikkarte ist es aber lästig, wenn ohne vorherige Konfiguration bei jedem Skin-Wechsel auf Interlace geschaltet wird (was bei mir passiert). Vielleicht kannst Du ja abfragen, ob ein Grafikkarten-Screen eingestellt wurde und in diesem Fall den Screen-Mode beibehalten.

Geb bitte mal in denn ToolTypes folgendes ein:

code:
ONLYCGX=1

Dann dürften nur noch CGX-Screens verwendet werden.
Aber eigentlich ist das der falsche Name, denn dann werden alle Screens genommen die nicht Nativ sind, bzw. nicht von den Customchips generiert werden. Ist auch noch eine Notlösung.

Zitat:
Die Version mit DirScan hat bei mir beim Start zwei Enforcer-Hits Byte-Read auf 00000000.

Hm, ja leider. Der Code dazu ist gerade im Programmiererforum.

Zitat:
Trotz allem ein schönes Programm

Danke, das liest man gerne.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 21:24 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Du benutzt doch nicht etwa mit SADD() ermittelte String-Adressen für die Erzeugen der Menüs?

Das hab ich ganz am Anfang mal gemacht (sogar noch vor der Gadtools-Zeit) bis ich seltsame Zeichenkette gesehn habe.

Bzw. nein, läuft alles über AllocVec() und ist somit vor dem Basiccompiler gesichert.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 22:19 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von NoImag:
Die Version mit DirScan hat bei mir beim Start zwei Enforcer-Hits Byte-Read auf 00000000.

Ich bin leider als noch recht ratlos woher das kommen kann. Denn eigentlich müßte das ja auffallen, wenn ich irgendwo eine falsche Variable übergeben würde. Hm...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

01.02.2008, 22:29 Uhr

Ralf27
Posts: 2779
Nutzer

Mir ist nun auch klar wie das mit nm_MutualExclude funktioniert. Hab da eine Beschreibung zu pOS gelesen (war auf deutsch, deswegen hab ich es wohl verstanden

). Ich nehme mal schwer an das das mit dem Classic-OS und neuer genau so läuft.

Die Sache mit dem Haken vor "immer eigener Screen" und "nur wenn Skin größer" ist so eine Sache. Mann kann ja beides Abhaken und bei bedarf auch den Haken bei "immer eigener Screen" weg machen. Am besten wäre es wohl, wenn man bei der Auswahl von "immer eigener Screen" einfach denn Menupunkt "nur wenn Skin größer" in Geisterschrift belegt.
Ist aber irgendwie Auslegungssache.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

02.02.2008, 22:07 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Ralf27:
Mir ist nun auch klar wie das mit nm_MutualExclude funktioniert. Hab da eine Beschreibung zu pOS gelesen (war auf deutsch, deswegen hab ich es wohl verstanden ). Ich nehme mal schwer an das das mit dem Classic-OS und neuer genau so läuft.

Für den Fall, das pOS das anders macht:
Jedes Bit in nm_MutualExclude entspricht einem Menüpunkt (oder in einem Untermenü einem Untermenüpunkt). Das erste Bit gehört zum ersten Punkt usw. Bei den Menüpunkten, deren Bit gesetzt ist, wird automatisch der Haken gelöscht, wenn der Menüpunkt, in dessen Struktur sich nm_MutualExclude befindet, ausgewählt wird. Ein Beispiel: Die Menüpunkte 1, 2 und 3 schließen sich gegenseitig aus. In nm_MutualExclude muss dann bei Punkt 1 Bit 2 und 3, bei Punkt 2 Bit 1 und 3 und bei Punkt 3 Bit 1 und 2 gesetzt sein.
Wenn von diesen drei Menüpunkten immer einer ausgewählt sein muss, dann darf bei diesen drei Menüpunkten TOGGLESELECT nicht gesetzt sein.

Zitat:
Die Sache mit dem Haken vor "immer eigener Screen" und "nur wenn Skin größer" ist so eine Sache. Mann kann ja beides Abhaken und bei bedarf auch den Haken bei "immer eigener Screen" weg machen. Am besten wäre es wohl, wenn man bei der Auswahl von "immer eigener Screen" einfach denn Menupunkt "nur wenn Skin größer" in Geisterschrift belegt.
Ist aber irgendwie Auslegungssache.

Ich habe diese Einstellungen so verstanden, dass es genau zwei Möglichkeiten gibt:
- Es wird ein eigener Screen geöffnet, wenn der Skin zu groß für die WB ist.
- Es wird immer ein eigener Screen

Diese beiden Möglichkeiten schließen sich gegenseitig aus (einmal immer, einmal nicht immer), also wäre nm_MutualExclude genau das Richtige.

Die Geiserschrift wäre natürlich auch möglich, ist aber aufwändiger zu programmieren und nach meiner Erfahrung ist dies auch eher unüblich.

Sollte es noch die Möglichkeit geben, dass keines von beiden ausgewählt sein kann, dann lautet die Lösung nm_MutualExclude und TOGGLESELECT gleichzeitig zu nutzen.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

02.02.2008, 22:13 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Ralf27:

Zitat:
Original von NoImag:
Die Version mit DirScan hat bei mir beim Start zwei Enforcer-Hits Byte-Read auf 00000000.
Ich bin leider als noch recht ratlos woher das kommen kann. Denn eigentlich müßte das ja auffallen, wenn ich irgendwo eine falsche Variable übergeben würde. Hm...

Bekommst Du keine Enforcer-Hits? Wo der Enforcer-Hit autritt, kannst Du feststellen, indem Du an bestimmten Punkten im Quellcode Breakpoints setzt und so den Bereich immer weiter einschränkst. Wie Du in Basic Breakpoints setzt, weiß ich nicht. Zur Not kannst Du einfach einen Standard-Requester öffnen und bei Bestätigung des Requesters das Programm einfach weiterlaufen lassen.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

02.02.2008, 22:23 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Ralf27:

Zitat:
Original von NoImag:

Zitat:
Zitat:
- die Screenauswahl sollte WBSudoku sich zumindest bis zum Programmende merken
Das ist so eine Sache:
Die Skins sind unterschiedlich groß und auch die Farbtiefe kann unterschiedlich sein. Gerade mit dem Customchipsatz sollte man immer denn passenden Screen auswählen. Außerdem kann man denn ausgewählten Screenmod dem jeweiligen Skin zuweisen, bzw. wird das dann in die entsprechende .dat-Datei des Skins geschrieben.
Ich verstehe das Problem und die Konfigurationsmöglichkeit ist gut. Mit einer Grafikkarte ist es aber lästig, wenn ohne vorherige Konfiguration bei jedem Skin-Wechsel auf Interlace geschaltet wird (was bei mir passiert). Vielleicht kannst Du ja abfragen, ob ein Grafikkarten-Screen eingestellt wurde und in diesem Fall den Screen-Mode beibehalten.
Geb bitte mal in denn ToolTypes folgendes ein:
code:
ONLYCGX=1
Dann dürften nur noch CGX-Screens verwendet werden.
Aber eigentlich ist das der falsche Name, denn dann werden alle Screens genommen die nicht Nativ sind, bzw. nicht von den Customchips generiert werden. Ist auch noch eine Notlösung.

Danke, das funktioniert

Ich fände es eine gute Idee, diese Einstellung noch ins Optionen-Menü aufzunehmen.
Den Namen des Tooltypes finde ich nicht so schlimm. Es soll ja kurz sein, nehme ich an

Ansonsten könntest Du es NoAmigaGfx nennen. Im Menü wäre "Nur auf Grafikarte" eine Möglichkeit.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

03.02.2008, 14:28 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von NoImag:

Zitat:
Dann dürften nur noch CGX-Screens verwendet werden.
Aber eigentlich ist das der falsche Name, denn dann werden alle Screens genommen die nicht Nativ sind, bzw. nicht von den Customchips generiert werden. Ist auch noch eine Notlösung.
...
Den Namen des Tooltypes finde ich nicht so schlimm. Es soll ja kurz sein, nehme ich an Ansonsten könntest Du es NoAmigaGfx nennen. Im Menü wäre "Nur auf Grafikarte" eine Möglichkeit.

Wenn man weder CGX, noch P96 explizit meint, wäre der übliche Name RTG. OnlyRTG wäre als Name genauso kurz.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.02.2008, 14:37 Uhr

Holger
Posts: 8116
Nutzer

Ach so, NoAGA oder NoOCS wäre noch kürzer (wobei OCS dann nicht für Old Chipset, sondern für Original Chipset stehen würde).

[ - Antworten - Zitieren - Direktlink - ]

03.02.2008, 19:53 Uhr

Ralf27
Posts: 2779
Nutzer

Ich hab eben die Möglichkeit der Grafikauswahl vom ToolType ins Menu übertragen. Außerdem das Menu mit nm_BARLABEL etwas struktuiert. Desweiteren bau ich jetzt noch beim Update ein Fenster mit Fortschrittsanzeige ein.
So langsam bekommt das ganze eine Form.

Also als her mit weiteren Kritikpunkten, Anregungen, etc.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

03.02.2008, 21:03 Uhr

Ralf27
Posts: 2779
Nutzer

Kann leider nicht die aktuelle Version hochladen, da ich die Datei einfach nicht komplett auf den Server von http://home.pages.at bekomme. Hm...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

04.02.2008, 06:34 Uhr

ArminHuebner
Posts: 1349
Nutzer

@Ralf27:

> da ich die Datei einfach nicht komplett auf den Server von http://home.pages.at bekomme. Hm...

Schon mal darüber nachgedacht, ob dein max. Webspace von 25Mb dafür
ausreicht?
--
Gruß, Armin.
--
'Auch wenn alle einer Meinung sind, können alle Unrecht haben.'
'Viele kaufen mit dem Geld, das sie nicht haben, Dinge, die sie nicht brauchen, um denen zu imponieren, die sie nicht ausstehen können.'

[ - Antworten - Zitieren - Direktlink - ]

04.02.2008, 08:18 Uhr

Ralf27
Posts: 2779
Nutzer

@ArminHuebner:

Klar, das war quasi mein erster Gedanke, aber meine Homepage ist nur einige MB groß, sie ist weit unter 25MB. Auch ist mein EMailfach bei home.pages.at leer. Insofern dürfte das nicht das Problem sein.

Es ist ja auch so das ich einige Versuche unternehmen muß bis ich die Datei auf den Server bekomme.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

04.02.2008, 23:21 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Ralf27:
Ich hab eben die Möglichkeit der Grafikauswahl vom ToolType ins Menu übertragen. Außerdem das Menu mit nm_BARLABEL etwas struktuiert. Desweiteren bau ich jetzt noch beim Update ein Fenster mit Fortschrittsanzeige ein.
So langsam bekommt das ganze eine Form.

Sehr schön!

Mit dieser Version habe ich bisher auch keine zerschossenen Menüs mehr gehabt.

Zitat:
Also als her mit weiteren Kritikpunkten, Anregungen, etc.

Du könntest nach "nur Grafikkarte" noch eine Trennlinie einfügen. Ansonsten kennst Du meine Vorschläge ja schon.

Tschüß

PS: Da ich diese Version herunterladen konnte, scheint das Hochladen ja geklappt zu haben.

[ - Antworten - Zitieren - Direktlink - ]

1 -2-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Amiga, AmigaOS 4 > Programm testen

[ - Suche - Neue Beiträge - Registrieren - Login - ]