scrollen wie iPad ...?

[Kiffi]

Nun meine Frage an diejenigen die's kennen: Findet Ihr dieses Verhalten intuitiv und meint, dass es die Mühe wert wäre das so auch zu implementieren?

Vollkommen...

... überbewertet
... systembelastend
... unverhältnismäßiger Programmieraufwand
...

Aber auch verdammt cool!

büdde büdde einbauen!

Grüße ... Kiffi

[PureLust]

Oki-doki, ...

hab mich also mal wieder an's Touch-Control gesetzt (und werde auch die angesprochene, "vollkommen überbewertete und systembelastende" Funktion mit dem Gummibandeffekt, trotz eines "unverhältnismäßig hohen Programmieraufwands" einbauen).
Hauptsache, es ist dann nachher verdammt coooooool !!!

Nun aber noch mal 'ne kurze Frage bezüglich der Namensgebung der Funktionen:
Den Prozeduren (und auch den Variablen) in meinen Libs setze ich eigentlich immer allen einen Präfix voran (also z.B. WinFX_... , ezPrint_..., ezTAPI_..., ezDebug_..., usw.).
Bei diesem Touch-Control bin ich aber momentan noch mit mir am hadern welchen Präfix ich dafür nehmen soll.

Momentan schwanke ich zwischen folgenden:
TLC_... (TouchListControl - mein derzeitiger Präfix)
TCL_... (TouchControlList)
ITC_... (IntelliTouchControl - ITC klingt meiner Meinung nach am besten )

Welche würdet Ihr sagen wäre der sinnvollste Präfix? (Weitere Vorschläge sind natürlich sehr willkommen.)

Bislang habe ich noch keine Libs gemacht, die neue Gadgets zur Verfügung stellen.
Und da man in PB ja leider keine eigenen Gadgets sauber einbinden kann, werde ich wohl nicht umhin kommen für das Touch-Control eigene Funktionen zur Verfügung zu stellen.
Um jedoch möglichst konsistent zu den Gadget-Befehlen von PB zu sein, versuche ich mich bei den Prozedurnamen, deren Parameter und deren Funktion weitestgehend an den bereits für Gadgets bestehenden PB-Derivaten anzulehnen.
In meiner derzeitige Planung würden die Prozeduren wir folgt aussehen:

Code: Alles auswählen

TLC_CreateGadget(#Gadget, x, y, Breite, Hoehe [, Flags [, @TCL_DefaultValues]])
TLC_RemoveGadget(#Gadget)
TLC_AddGadgetItem(#Gadget, Position, Text$ [, ImageID [, Flags]])
TLC_RemoveGadgetItem(#Gadget, Position)
TLC_ResizeGadget(#Gadget, x, y, Breite, Hoehe)

TLC_SetGadgetAttribute(#Gadget, Attribut, Wert)
TLC_GetGadgetAttribute(#Gadget, Attribut)
TLC_SetGadgetColor(#Gadget, FarbTyp, Farbe)
TLC_GetGadgetColor(#Gadget, FarbTyp)
TLC_SetGadgetData(#Gadget, Wert)
TLC_GetGadgetData(#Gadget)
TLC_SetGadgetFont(#Gadget, FontID)
TLC_GetGadgetFont(#Gadget)
TLC_SetGadgetState(#Gadget, Status)
TLC_GetGadgetState(#Gadget)
TLC_SetGadgetText(#Gadget, Text$)
TLC_GetGadgetText(#Gadget)

TLC_SetGadgetItemAttribute(#Gadget, Eintrag, Attribut, Wert)
TLC_GetGadgetItemAttribute(#Gadget, Eintrag, Attribut)
TLC_SetGadgetItemColor(#Gadget, Eintrag, FarbTyp, Farbe)
TLC_GetGadgetItemColor(#Gadget, Eintrag, FarbTyp)
TLC_SetGadgetItemData(#Gadget, Eintrag, Wert)
TLC_GetGadgetItemData(#Gadget, Eintrag)
TLC_SetGadgetItemFont(#Gadget, Eintrag, FontID)
TLC_GetGadgetItemFont(#Gadget, Eintrag)
TLC_SetGadgetItemState(#Gadget, Eintrag, Status)
TLC_GetGadgetItemState(#Gadget, Eintrag)
TLC_SetGadgetItemText(#Gadget, Eintrag, Text$)
TLC_GetGadgetItemText(#Gadget, Eintrag)

TLC_SetDefaultValues(#Gadget, @TCL_DefaultValues)        ; könnte evtl. auch heißen:  TLC_SetDefaultAttributes(#Gadget, @TCL_DefaultAttributes)
TLC_GetDefaultValues(#Gadget, @TCL_DefaultValues)        ; könnte evtl. auch heißen:  TLC_GetDefaultAttributes(#Gadget, @TCL_DefaultAttributes)

TCL_DisableGadgetRedraw(#Gadget, Status)

TLC_WaitWindowEvent([Timeout])
TLC_ExecuteTLCEvent()

Eigentlich könnte man sich ja auch die diversen SetGadget/GetGadget-Funktionen sparen, weil man ja im Grunde durch Angabe der richtigen Attribute bei SetGadgetAttribute() und GetGadgetAttribute() alle anderen Dinge (wie Color, Data, Font & State) setzen bzw. auslesen könnte.
Was würdet Ihr sagen ... aus Kompatibilitätsgründen alle Sets/Gets implementieren, oder der Einfachheit halber alles per SetGadgetAttribute/GetGadgetAttribute und eben den entsprechenden Attributen machen?

Wenn jemand Lust hat kann er ja mal kurz über oben stehende Funktionen drüber fliegen, ob ggfl. noch irgendwelche Funktionen fehlen oder ob man was anders machen bzw. anders benennen könnte.
Ansonsten wäre ein kurzes Feedback willkommen, ob das so in der Art benutzerfreundlich genug umgesetzt wäre.

Grüße, PL.

[Syntacks_Error]

Sieht wirklich sehr schick aus. Zu den Namen kann ich nichts sagen, aber wäre es vielleicht möglich, so ein Abfedern auch noch (alternativ) für das Scrollrad einzubauen? Eigentlich wäre das ja vielleicht sogar näherliegend als eine Fingergestik über den Mauszeiger zu simulieren. Für "Auf & Ab" gibt gibt es das Rad ja, und es ist intuitiver und einfacher zu bedienen als MaustasteDruecken - MausBewegen- MausTasteLoslassen? Wie auch immer, es ist im jedem Fall eine tolle Erweiterung.

[Kiffi]

Für "Auf & Ab" gibt gibt es das Rad ja, und es ist intuitiver und einfacher zu bedienen als MaustasteDruecken - MausBewegen- MausTasteLoslassen?

primär soll das Teil ja auch für Touchscreens sein. Und da ist der Finger das intuitivste Eingabegerät

@PureLust:

Code: Alles auswählen

TLC_AddGadgetItem(#Gadget, Position, Text$ [, ImageID [, Flags]])

nur so als Gedankenanregung:

wie groß wäre der Programmieraufwand für Dich, wenn man Deinem
Touch-Control anstelle eines 'Text-Items' einen Container übergibt?

Dann wäre man in der Gestaltung der Scroll-Items ein wenig flexibler.

Grüße ... Kiffi

[Syntacks_Error]

Isch abe ab ga kein Touchscreen - finde aber den Effekt auch auf einem, öhm, richtigen Rechner sehr nett, sofern er dezent genug bleibt.

[PureLust]

wie groß wäre der Programmieraufwand für Dich, wenn man Deinem
Touch-Control anstelle eines 'Text-Items' einen Container übergibt?

Dann wäre man in der Gestaltung der Scroll-Items ein wenig flexibler.

Diverse andere Gadgets in das Touch-Control noch mit zu integrieren stand auch schon auf meiner ToDo-Liste.
In Anbetracht des erhebliche höheren Verwaltungsaufwandes hatte ich das jedoch erst mal weit nach hinten auf meiner Liste verschoben.
Ein "einfaches" ContainerGadget zu integrieren und dem User somit die freie Wahl über die darin platzierten Gadgets zu lassen (wobei er diese dann auch komplett selber kontrollieren kann/muss und somit auch den Aufwand für die Verwaltung hat) wäre hingegen sehr einfach umzusetzen.
Die Einbindung eines ContainerGadgets ist also gebongt.

Es könnte jedoch (je nach Gadgets innerhalb des Containers) sein, dass dann die Touch-Funktionalität etwa gestört wird, da mir diese Gadgets dann u.U. die benötigten Events klauen.
Aber ... mal schauen was ich da hinbekomme.

@Syntacks_Error (aua, die Schreibweise tut mir ja in der Seele weh):
Scrollrad-Unterstützung ist in PB so eine Sache. Nativ werde ich da wohl nicht an die benötigten Events kommen.
Ich hab zwar schon mal einen Scrollrad-Support für meinen Bildbetrachter in nativem PB getrickst (musste auch unter Mac OSX funktionieren) - für das Touch-Control wäre dieser Trick jedoch leider nicht anwendbar.
Somit fällt Scrollrad-Support (zumindest vorerst) wohl leider flach - sorry.

Grüße, PL.

[mk-soft]

@Purelust

Freue mich schon auf das Ergebnis

[Then]

wird es nur vertikales scrollen geben, oder gehts auch horizontal ? Oder sogar diagonal ???

[NicTheQuick]

@Then: Mein Code ging in alle Richtungen und funktioniert bei mir auch immer noch besser als die neuste Version von PureLust. Und jetzt kommt nicht wieder mit dem Argument, dass eine Structure schon unter Windows existiert oder sowas... Blabla...

[TomS]

@Then: Mein Code ging in alle Richtungen und funktioniert bei mir auch immer noch besser als die neuste Version von PureLust. Und jetzt kommt nicht wieder mit dem Argument, dass eine Structure schon unter Windows existiert oder sowas... Blabla...

Dein Code hängt sich nach dem dritten Klick auf.
Ich hab nur die Struktur umbenannt und den Pfad zum Bild angepasst.
Win7 Home Premium 32bit
Kann das wer bestätigen?