PureBoard

Verfasst: **10.12.2006 22:20**

@Dieter
mach dir keinen kopp.

es ist bestimmt schön, das zu können, aber für deine belange nicht unbedingt notwendig.

keine frage, eine eigene fensterklasse für ein sudoku, das wäre TOP,
ganz besonders wenn die drunterliegenden erzeugungs- und lösungs-algorithmen schon top sind.

aber als nächste GUI-Version nach einer Consolen-Oberfläche ist ein 9x9-Image-Feld absolut ausreichend.

natürlich wäre es gut, wenn du diesen gedanken - eigene fensterklasse - weiterverfolgst,
besonders im hinblick auf eine Finale Version, die für ein offizielles (kommerzielles) Release geeignet ist.

aber für den ersten umstieg auf eine Win-GUI reicht ein Image-Feld...

Verfasst: **10.12.2006 22:54**

danke Kaeru Gaman für die Wiederaufrichtarbeit.

Meinste wirklich für ein Sudoku Lösungsprogramm möchte jemand Geld ausgeben?

Verfasst: **10.12.2006 23:13**

grundsätzlich kommt es immer auf die vermarktung drauf an.
ein erstlingswerk kann man auch auf ne Heft-CD bringen.
damit verdient man noch kein Geld, aber manchmal ein bisschen bekanntheit...

wenn du nen Vertrag mit ner Budget-Firma schließen kannst, warum nicht?
Koch-Media, Franzis, DataBecker...
auch außerhalb deutschald gibt es Budget-Firmen, wie z.b. Pepper-Games...

wenn du es selbst vermarkten willst, könntest du auch ne Demo für umsonst
und ne Vollversion für 5,- per PayPal oder Telefonzahlung auf ne Website setzen...

die möglichkeiten sind vielfältig, und ich kenn mich nicht so detailliert aus.

grundsätzlich wäre es besser, wenn das Prog nicht nur Sudokus lösen kann,
sondern auch in unterschiedlichen Schwierigkeitsgraden erzeugen kann,
und eine bequem bespielbare Oberfläche bietet.
letzteres ist besonders wichtig, viele besonders spielalgorithmisch-lastigen
programme haben keine bequeme oberfläche, die "die Massen" anspricht.

also, ein lösungs-programm alleine könnte schick sein, aber ist nicht so der kommerzielle hit,
denn es wird nicht so viel publikum erreichen, als wenn es auch eine spielbare oberfläche bietet.

ein reines lösungsprogramm wird sich nur schwer vermarkten lassen...

aber es wird bestimmt seine liebhaber finden, auch mit image-grid-oberfläche.

ein spielbares programm hat kommerzielles potential, auch mit image-grid-oberfläche,
aber noch mehr mit dem, was mit einer eigenen fensterklasse möglich wäre.

also, verrenn dich nicht in der idee des kommerziellen...

du müsstest ein programm mit lösungsalgos und spielbarer oberfläche
und am besten mit eigener fensterklasse schreiben,
und das möglichst, bevor die sudoku-modewelle endet.

entschuldige die umfangreiche antwort zu
> Meinste wirklich für ein Sudoku Lösungsprogramm möchte jemand Geld ausgeben?
eine kürzere antwort schien mir nicht angemessen....

Verfasst: **11.12.2006 18:17**

Ich hab sowas mal gemacht... Ich hab dazu StringGadgets (nur Zahlen) genommen, (man kann ja auch (wenn man will) die Farben ändern) mit #ES_LIMITTEXT die Anzahl möglicher Ziffern auf 1 reduziert und dann mit WindowOutput() in die Zwischenräume der StringGadgets Linien gezeichnet...

Verfasst: **11.12.2006 20:31**

>Ich hab dazu StringGadgets (nur Zahlen) genommen.
Hallo Marvin.
das geht?
Ich muß die Gadgets ja zwischendurch malipulieren. Weil sich ja die Restlichen Felder "rechnerisch" ergeben.

Ich meine das SetGadgetText(#Gadget, Text$) schonmal in einer anderen Geschichte gemacht zu haben. Da hatte ich dann merkwürdige erscheinungen.

Versuch macht klug.

Dieter

Verfasst: **11.12.2006 20:52**

> Ich meine das SetGadgetText(#Gadget, Text$) schonmal in einer anderen Geschichte gemacht zu haben. Da hatte ich dann merkwürdige erscheinungen.

das könnte der effekt gewesen sein, den ich meinte.

auch ein SetGadgetText löst ein event aus.
du musst also für jedes SetGadgetText einen Eventschleifen-durchlauf haben,
während dessen du nichts änderst/settest/etc.

wenn du also in einer zuweisung ALLE sudoku-gadgets aktualisierst
(egal ob stringgadgets oder imagegadgets)
dann brauchst du danach 81 eventschleifen-durchläufe, wo nichts geändert wird.

Verfasst: **11.12.2006 21:05**

>das könnte der effekt gewesen sein, den ich meinte.

>auch ein SetGadgetText löst ein event aus.
>du musst also für jedes SetGadgetText einen Eventschleifen-durchlauf >haben,
>während dessen du nichts änderst/settest/etc.

Ach guck. Kannst Du Dich noch an mein CAD errinnern? (vor 6Monaten)
Da wollte ich die eigenschaften von Geometrien anzeigen/ändern.
Ging mit StringGadgets garnicht.

Verfasst: **11.12.2006 21:20**

Hallo Dieter.

Ich würde es so machen:

Ein Bild in einem ImageGadget anzeigen das du im Programm erstellt hast.
Z.b. Wenn die Zahlen 32 x 32 Pixel groß sein sollen muss das bild:
32 x 32 * 9 x 9 = 288 x 288 pix.

Das erscheint mir groß genug für ein Sudoku.
Dann malst du in das Bild ein Raster.

Die zahlen kann man entweder schon mit dem Programm als Bilder mitleifern oder (die Edelversion) direkt beim ändern auf Bild malen.

Ich arbeite im moment an ähnlichem so dass ich mir schon einige gedanken gemacht hab.

Wen du weitere Hilfe brauchst kannste einfach fragen dann stell ich ein bisschen Code rein.

Mfg mknjc

Verfasst: **11.12.2006 21:34**

wow. scheint mir ne einfache Idee zu sein.
das könnt was werden.

Verfasst: **25.05.2007 21:55**

Code: Alles auswählen

OpenWindow(0,200,200,200,200,"SoDingsda")
CreateGadgetList(WindowID(0))
For y=0 To 2
  For x=0 To 2
    StringGadget(y*3+x+1,20+30*x,20+30*y,30,30,Str(y*3+x+1)) 
  Next 
Next


Repeat
  Event = WaitWindowEvent()  
  
Until Event=16 ; CloseWindow

Vielleicht etwas spät, aber hier Stand ja nicht die Antwort von dir

PureBoard

Das Richtige Gadget für ein Sudoku ?