|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Designtips (GUI, Messagehandling etc.) | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
01.02.2010, 20:26 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, knoble gerade an einigen grundsätzlichen Dingen, die mir die "klassische" Intuition-Programmierung (Stand AOS3.x) in C++ leichter machen sollen. Weiss nicht, ob es da schon Frameworks/Libraries für gibt. Habe das Ganze selbst angefangen, um mir mehr Kenntnisse über C++ und die Amiga-Programmierung anzueignen. Bisher habe ich mir dazu ein paar Klassen geschrieben, die mir den Umgang beim Anlegen, Öffnen, Schließen und Freigeben von Screens und Fenstern (mit einigen Dingen, die dazugehören) erleichtern. Nun brüte ich gerade über ein einfaches Konzept für das Message-Handling. Mein bisheriger Ansatz sah vor, dass es eine abstrakte Klasse für die Verarbeitung von IDCMP-Messages gibt. Der Einfachheit halber habe ich das Message-Handling noch in der Fensterklasse belassen. Dort wird bisher nur nach einigen Fällen unterschieden und die dafür vorgesehenen Empfänger werden gerufen wenn vorhanden (ähnlich wie bei Java). Als Empfänger habe ich bisher einen für GadgetMessages, einen für IntuiTickMessages und einen für MausMessages. Alle leiten von der o.g. abstrakten Klasse ab. Nun bin ich mir nicht ganz schlüssig, wie ich am besten die Ereignisse an die Endverbraucher (der eigentlich bei Eintreffen einer entspr. Nachricht tätig werden sollte) weitergebe. Die Idee war bisher, dass diese sich z.B. für IntuiTickEreignisse bei dem Empfänger für die IntuiTickMessages registrieren und bei jedem Eintreffen einer solchen Nachricht aktiviert werden. Die Endverbraucher verfügen bisher alle über dieselbe parameterlose Schnittstelle. So weit so gut. Allerdings bekomme ich dann bei Endverbrauchern für MausMessages ein Problem, da dort ja z.B. auch die Mauskoordinaten benötigt werden. Eine Möglichkeit wäre eine Art Ereignisweitergabe wie in Java zu machen und für alles entsprechende Ereignissklassen zu gestalten. Aber dazu neige ich gerade weniger. Eine andere Möglichkeit bestünde darin die kopierte MessageStruktur an alle Endverbraucher weiterzugeben (die Empfänger erhalten sie bereits). Die dritte Möglichkeit wäre für jeden Endverbraucher eine eigene Empfängerklasse zu schreiben (ähnlich den Listenern/Adaptern in Java) und die eigentlichen Aufgaben darin abzuarbeiten. Puh! Ich hoffe, dass ist nicht zu verwirrend beschrieben! Falls Fragen offen sind, immer heraus damit! Welche Möglichkeiten seht ihr denn noch so bzw. zu welcher würdet ihr tendieren? Und gibt es denn gute Webseiten oder Bücher wo man sich über genau solche Themen aufschlauen kann (keine Designpattern-Beschreibungen, die kenne ich schon bzw. finde sie im Web)?! Bei der Google-Suche nach GUI Design Prinzipien oder Event Handling Design bin ich nämlich noch nicht auf so viel Verwertbares gestoßen! Vielen Dank schon mal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2010, 21:05 Uhr Kaesebroetchen Posts: 643 Nutzer |
@Reth: Ich weiß nicht ob es dir was nützt, aber du kannst ja mal einen Blick auf den Quellcode von Murks!IDE werfen. Deadwood hat da ziemlich abstrakte C++ Sachen eingebaut und auch das Message Handling in eine C++ Klasse gebaut. Alle Vertreter der reinen Lehre (MUI nur in C) sagen zwar das wäre Pfui, aber auf jeden Fall funktionierts und ist ziemlich Portabel. -- http://amidevcpp.amiga-world.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
03.02.2010, 11:15 Uhr Holger Posts: 8116 Nutzer |
@Reth: C++ unterstützt templates. Somit ist es nicht notwendig, dass alle "Endverbraucher" eine parameterlose Schnittstelle unterstützen. Man kann also je nach Art der Nachricht eine andere Parameterliste unterstützen. Andernfalls verstehe ich auch nicht, warum die "Empfänger", deren Aufgabe offenbar nur darin besteht, die "Endverbraucher" zu informieren, Unterklassen einer abstrakten Klasse sein müssen, wenn sie doch alle dasselbe machen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
03.02.2010, 19:33 Uhr Reth Posts: 1858 Nutzer |
@Kaesebroetchen: Hab mir das mal angeschaut. Auch ein interessantes Konzept, wo man das auslösende Objekt zusammen mit dem Handler registrieren kann. Allerdings hat es mir bisher noch nicht so zugesagt (oder ich habs noch nicht ganz durchdrungen), da ja der Handler keine Infos vom auslösenden Objekt bekommt, sondern die Instanz, bei der er sich mit diesem Objekt registriert hat (und muss deren Typ fürs Casten kennen). Die Idee eine Aktion zu machen, die durch verschiedene Auslöser getriggert werden kann (Menu oder Button) hab ich bei mir auch. Allerdings sind diese Aktionen (noch) parameterlos. Eine Frage noch: Was ist denn das DoMethod() in diesen Klassen? Was MUI-Internes oder AOS-internes? @Holger: Zitat: Mal sehen ob ich das richtig verstehe: Du würdest also die aufzurufende Methode eines Endverbrauchers mit einem Template-Typ als Parameter versehen und dann für die spezifischen Typen die jeweiligen Strukturen/Klassen schreiben, die dort zu übergeben sind? Mir geht es weniger um unterschiedliche Typen eines Übergabeparameters für die Endverbraucher-Aufrufe sondern mehr darum unterschiedlich viele Parameter für die verschiedenen Endverbraucher zu übergeben (z.B. beim Endverbraucher für IntuiTicks sind für den Aufruf keine spezifischen Message-Parameter nötig, beim Endverbraucher für MausMessages werden die Koordinaten des Mauszeigers benötigt). Damit ist dann aber keine einheitliche Schnittstelle mehr möglich! Oder meinst Du was anderes? Die Idee war Aktionen zu schaffen, die durch verschiedene Auslöser aufgerugen werden können und immer dasselbe machen (wie bei Murks). Die erste Version dieser Klassen hat eine parameterlose Methode, welche die Aktion auslöst. Diese Aktionen habe ich z.B. beim Empfänger für IntuiTicks registriert. Weitere Aktionen (die andere Dinge tun) sind z.B. bei Gadgets fürs Drücken und Loslassen registriert. Nun möchte ich eine Aktion für Mausbewegungen registrieren, die ein Neuzeichnen eines Cursors veranlasst. Dazu benötige ich allerdings die aktuellen Mauskoordinaten. Denke mal, dass ich hier eine speziellere Aktion ableite, virtuell mache und dann für meine Cursorzwecke implementiere. Zitat: Der Gedanke war, die Empfänger Message-spezifisch zu gestalten, so dass z.B. beim Auswerten der Messages im Window alles was mit Gadget-Messages zu tun hat an den entsprechenden Empfänger weitergegeben wird. Dieser kann dann unterscheiden, ob ein Gadget gedrückt oder losgelassen wurde und entsprechend reagieren (hab den Source gerade nicht zugreifbar). Daher auch die Problematik. Aktuell habe ich das Thema, dass mein Empfänger für Mausmessages einen Verbraucher bekommen soll, der sich bei Bewegung der Maus neu an den Mauskoordinaten zeichnen soll. Mit meinem bisherigen Konstrukt kann ich zwar Verbraucher für Mausbewegungsmessages registrieren, aber diese haben ja noch die parameterlose Schnittstellen, also noch keine Möglichkeit, die neuen Koordinaten zu übergeben. Da ist der Template-Ansatz schon sehr interessant (versteh ihn wohl bloss noch nicht)! Ciao [ Dieser Beitrag wurde von Reth am 06.02.2010 um 21:07 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Designtips (GUI, Messagehandling etc.) | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|