|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Strukturen, was passiert wenn... | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
02.12.2005, 21:46 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, mich interessiert, was passiert, wenn man z.B. den Inhalt einer Image-Struktur ändert, die bereits in Verwendung ist, ihr z.B. neue Maße und/oder neue Daten gibt? Bei einigen anderen Strukturen wie Fenster und Menü kann man sichs ja vorstellen, aber was ist mit Image, Bitmap und Screen z.B.? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
02.12.2005, 23:32 Uhr geit Posts: 332 [Ex-Mitglied] |
Erstmal passiert gar nichts und beim nächsten Rendern wird es falsch dargestellt, weil z.B. Gadgets die Position und Größe dem alten Image angepaßt haben. Das Image wird größer, aber die Gadgets und Fenstergrößen bleiben so wie vorher. Generell ist das böse und sollte auf keinen Fall gemacht werden, wenn das System darauf zugriff hat. Erst wieder entfernen und dann veröndert hinzufügen. Geit [ - Antworten - Zitieren - Direktlink - ] |
|
02.12.2005, 23:37 Uhr Reth Posts: 1858 Nutzer |
Also wenn man die Imagestruktur wieder entfernt, kann man sie verändern und wieder einbringen. Aber was passiert z.B. wenn man eine Screenstruktur hat? Die kann man doch nirgends entfernen! Ist die als ReadOnly definiert? Hintergrund ist der, dass ich ein paar C++ Klassen erstelle, die mir den Umgang mit Fenstern, Screens und Buttons etc. erleichtern! [ - Antworten - Zitieren - Direktlink - ] |
|
03.12.2005, 00:31 Uhr geit Posts: 332 [Ex-Mitglied] |
Wenn Du z.B. ein Image hast, daß als Gadget in der Titelzeile erscheint, dann kannst du es nicht ändern, solange es auf dem Schirm ist. Das gilt nicht nur her, sondern eigentlich überall. Wenn es keine Funktion zum Modifizieren gibt, dann mußt Du entfernen, modifizieren und hinzufügen. Beim Screen heißt das dann natürlich Bildschirm schließen. Aber wie gesagt, das gilt nur, wenn du es eingehängt hast und das System es aktualisiert, ohne das das Programm etwas machen mußt. Wenn Du die Images selber zeichnets, wenn ein Refresh kommt, dann kannst du natürlich damit machen, was Du willst. An System-Strukturen patcht man aber generell nicht rum. Wenn es keine Funktion gibt, dann geht es meist auch nicht. Du kannst auch z.B. nicht einfach den Windowtitel durch patchen ändern. Du mußt die entsprechenden Funktionen nehmen. Gut sehen kann man das bei den Window Tags. Tags die CreateOnly sind, kannst du nicht Systemkonform ändern. Ein Fenster mal eben Borderless machen geht z.B. nicht, weil hier viele zusätzliche Systemresourcen allokiert werden, die beim Ändern des entsprechenden Flags eventuell dazu führen, das diese nicht mehr freigegeben werden. Für den Screen und Windowtitel gibt es z.B. eigene Funktionen. Gleiches gilt für die Fenstergröße. Ein Sizeing Gadget kann man nicht einfach wegpatchen oder entfernen, da das Fenster darauf ausgerichtet ist und z.B. die Rahmen entsprechend eingerechnet und verbreitert hat. Du kannst z.B die Gadgetliste mit den entsprechenden Funktionen entfernen, nach belieben ändern und wieder hinzufügen. Das Funktioniert und ist erlaubt. Geit [ - Antworten - Zitieren - Direktlink - ] |
|
03.12.2005, 10:58 Uhr Holger Posts: 8116 Nutzer |
Zitat:Definiert ist sie nicht so, aber besser wäre es. Man kann zwar theoretisch bestimmte Änderungen vornehmen, aber es wäre Zeitverschwendung sich die entsprechenden Grundlagen anzueignen, weil es sich um genau die Dinge handelt, die in Zukunft wohl verworfen werden. Also stell Dir die Strukur (im Zweifelsfall am besten alle Strukturen) als Read-Only vor. Zitat: Ah, das Projekt lebt also noch. Wie bist Du denn dabei vorangekommen? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2005, 23:08 Uhr Reth Posts: 1858 Nutzer |
@geit: @Holger: Danke erst mal! Na klar lebt das Projekt noch! Komme leider viel zu wenig dazu, daran weiterzuarbeiten! Zu wenig Zeit! Bin gerade dabei, alles auf GCC zu portieren. Wenn das mal abgeschlossen ist, gehts an die Performance bei vielen Animationen, danach an neue Features. Dachte mir das bei Image (brauch ich z.B. für Buttons mit Bildern) evtl. so: class ImageC { public: setX() throws InUseException; setY() throws InUseException; setWidth(); ... getX(); ... private: struct Image image; }; Das Ganze ist halt sehr javalastig, dort gibts für alles mögliche Getter und Setter. Zudem wollte ich eine abstrakte Klasse machen, welche X und Y (und evtl. width und height) setzt. Bei den Methoden, welche die InUseException werfen, wird auf ein BOOL geprüft, welches auf TRUE gesetzt wird, sobald das Objekt in Benutzung ist. Das Ganze wird auch in ne abstrakte Klasse gelegt (in Java würde ich ein Interface nehmen, weiss nicht, was in C++ gut dafür ist?). Da ein Image auch eingebettet (z.B. in meiner Klasse ImageButtonC) verwendet werden kann, brauch ich noch ne gute Idee, wie ich das inUse-Flag setze. In Java würde ich in der ImageButtonC-Klasse alle enthaltenen Objekte durchlaufen, prüfen ob sie instanceof <hier Interface für InUse> sind, dann das Flag auf TRUE setzen. Bei ImageButtonC und ButtonC ists ziemlich einfach, wenn ich die in WindowC hänge, werd ich sie in ne Liste oder nen Vector hängen, der dann durchlaufen wird, wenn die Buttons aktiviert werden. Jeder Button bekommt das InUse gesetzt und muss es dann an seine Inhalte (z.B. ImageC) weitergeben. Wie gesagt, alles eher javalike. Wenn ich da gg. C++ Konventionen verstoße oder es dort andere/bessere Wege gibt, immer heraus damit, wills schließlich lernen! Ach ja: Gibts eigentlich ne Faustregel, wann man in C++ eine Klasse komplett im Header implementiert? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2005, 13:17 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das macht nicht allzuviel Sinn. Wie oft kommt es in einer realen Anwendung vor, daß man ein einzelnes Attribut eines Bilds, wie z.B. Breite, ändern will? Meist will man doch eher das ganze Bild als Eigenschaft eines anderen Objekts setzen. Bilder, die nicht "inUse" sind, sind sowieso die Ausnahme. Und es schadet nicht, sie genauso wie alle anderen zu behandeln. Zitat:In C++ benutzt Du entweder abstrakte Klassen (gibt ja Mehrfachvererbung) oder templates. Es gibt auch ein paar sehr elegante delegation-Mechanismen. Zitat:Da Bilder auch in mehr als einem Objekt stecken können, bräuchtest Du schon einen counter. Aber wie schon gesagt, ich habe so meine Zweifel an der Sinnhaftigkeit dieses Trackings. Zitat:Das glaube ich nicht. Ob eine Klasse ein bestimmtes interface erfüllt, wird zur compile-Zeit festgelegt. Welche relevante Information soll Dir das zur Laufzeit bringen? Zitat:Um Himmels Willen. So viel Aufwand, wo Du noch nichtmal weißt, ob das Programm überhaupt jemals ein Image ändern will. Zitat: In Java trägt sich die Komponente entweder als image-consumer ein und erfährt, wenn sich etwas ändert, oder sie geht von immutable images aus, und der Anwendungsprogrammierer muß sich selbst um Thread-Synchronisation kümmern. Ähnlichkeiten sehe ich da nicht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2005, 19:03 Uhr Reth Posts: 1858 Nutzer |
Zitat: Stimmt, hab Image auch als Beispiel genommen, meinte eigentlich mehr die Gadgetklassen, dort könnte man zur Laufzeit z.B. Position und Größe ändern, was ja nicht gewünscht ist, so lang ein Gadget aktiv ist. Zitat: Das Runtime Type Checking von Java finde ich enorm gut und wichtig! Es ist z.B. denkbar, dass eine Klasse mehr als ein Interface implementiert, wenn ich dann zur Laufzeit wissen will, ob sie die Bedingungen eines dieser Interfaces erfüllt, prüfe ich das mit instanceof. Noch wichtiger ist es z.B. in Methoden, die als Parameter speziellere Klassen bekommen, aber innerhalb der Methode in ihrer Verarbeitung anhand abgeleiteter Klassen unterscheiden. So hab ich das z.B. bei nem Comparatorobjekt in Java gemacht, welches Inhalte von Vectorobjekten anhand bestimmter (jeweils unterschiedlicher) Kriterien sortieren soll, aber immer nur nach einem. Da gibt es nur eine Methode compare vom Typ Objekt (war noch unter Java1.3.1, jetzt gibts ja auch Templates), darin wurde dann mittels instanceof unterschieden, welcher spezieller Typ das ist (u.a. durch Implementation von Interfaces). Evtl. hätte ich auch für jedes Attribut ne eigene compare-Methode schreiben können, bin mir aber nicht sicher, ob die dann auf Vectorobjekte anwendbar gewesen wäre. (Hab Vector verwendet, Comparator geht glaub ich bei allen Collection Objekten) Zitat: Stimmt ja. Wie gesagt, hab ich dummerweise Image genommen, denke aber insgesamt mehr über Layoutkomponenten nach (in Java z.B. JButton). Also wenn man bei Gadgets zur Laufzeit Position oder Größe oder Flags ändert, was passiert dann? Darf man das in AmigaOS. Soweit ich mich noch erinnere geht das unter Java, man muss aber nen Refresh auf die beinhaltende Komponente machen! Überlege mir also gerade, ob ich meiner abstrakten Klasse Gadget immer erlaube über Setter ihre Attribute zu ändern. Von dieser Klasse sollen dann Buttons, Checkboxen, ImageButtons etc. erben. Gibts da in C++ andere Wege als Setter und Getter für alle Attribute? In Java wird man damit ja überhäuft (braucht sich nur mal die Hierarchie von JButton anzusehen, was da an Settern und Gettern rumfliegt)! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2005, 13:57 Uhr Holger Posts: 8116 Nutzer |
Zitat:Solange Du die korrekte SetGadgetAttr... Funktion des OS benutzt, spricht überhaupt nichts dagegen. Aber normalerweise überläßt man so etwas dem übergeordneten Container, vergleichbar mit LayoutManager. Zitat:Natürlich, aber darum geht es ja gar nicht. Du wolltest die Tatsache, daß ein Objekt in einem anderen enthalten is, bzw. den InUse-Zustand als interface umsetzen. Das ist aber technisch unmöglich. Die containment und inUse-Eigenschaften ändern sich zur Laufzeit. Das Objekt, bzw. die zugehörige Klasse kann aber nicht plötzlich die implementierten interfaces ändern, weder in Java, noch in C++. Zitat:instanceof sollte nur der letzte Ausweg sein, wenn andere Mechanismen nicht mehr anwendbar sind. Zitat:Ich glaube Du solltest mal Deinen Wissenstand in Sachen Delegation und Design-Patterns, wie z.B. Visitor-Pattern erweitern. Fallunterscheidungen innerhalb einer Methode anhand von Laufzeit-Klassenüberprüfung zeugt nicht von gutem Design. Zitat:Dafür benutzt man normalerweise unterschiedliche Comparator-implementierungen für die verschiedene Attribute. Daß die Objekte vom richtigen Typ sein müssen, sprich das entsprechende Attribut auch besitzen müssen, gehört zu den Vorbedingungen. Dafür braucht man auch kein instanceof hinterher. Zitat:Templates und Generics sind völlig unterschiedliche Dinge. Sollte man auf keinen Fall in einen Topf werfen. Zitat:Den Refresh mußt Du unter AmigaOS machen. In Java wird der Refresh automatisch durchgeführt. Es sei denn, Du meinst validate(). Das muß bei einigen AWT-Komponenten manuell aufgerufen werden, bei Swing nicht mehr. Zitat: Es gibt mehrere Wege. Zum einen gilt die Weisheit (die auch bei Swing gut getan hätte): weniger ist mehr. Man braucht nicht für jedes Attribut die Möglichkeit der Manipulation. Zum Beispiel die bounds, die normalerweise vom LayoutManager kontrolliert werden, werden als x, y, width, height, location, size, bounds in gleich 7 Attributen abgebildet, deren set-Methoden für verschiedene Datentypen überladen sind. Auf die Art bläht man das API unnötig auf und verschwendet Entwicklungszeit mit Dingen, die im Endeffekt in der Praxis gar nicht benutzt werden. Und dann sollte man Delegation konsequent einsetzen. In Swing werden z.B. nach dem MVC-Prinzip Operationen an das Datenmodell und dem L&Feel View delegiert. Allerdings hätte man genau aus diesem Grund auch eine Menge Methoden einsparen können, weil man sie sowieso eher direkt auf dem Model oder View aufruft, wenn man sie doch braucht. In C++ kann man das noch mit dem Operator-Overloading vereinfachen. Wenn die Attribute Klassen mit angepaßtem Zuweisungsoperator sind, kann man sie als public-Instanzvariablen anlegen, auf die eine einfache Zuweisung statt Methodenaufruf durchgeführt werden kann. In der Form: class Button { public: Attr<String> label; } //... button.label="Hallo"; Wenn der Attr-Zuweisungsoperator dann die SetGagetAttr-Funktion aufruft... Ich glaube, so etwas in der Form hatten wir schon in der Mailkorrespondenz. Müßte ich mal nachschauen. Ich habe damit mal im Zusammenhang mit MUI rumgespielt, weiß jetzt gerade nicht, wie der Stand der sourcen war. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 06.12.2005 um 14:01 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2005, 15:32 Uhr Reth Posts: 1858 Nutzer |
Hi Holger,Zitat: Das ist schon richtig, habe eher auf die Typisierung angespielt, die ja nun auch für z.B. Vectorobjekte möglich ist. Zitat: Wenn das die Mails sind, die ich auch gerad im Kopf hab, da gings um die Typisierung von TAGITEMS, danke nochmal dafür! Obiges bedeutet, ich muss den Zuweisungsoperator der Klasse Attr für unterschiedliche Typen unterschiedlich gestalten?! Also ein Attr<String>...="Hallo"; wird anders behandelt als ein Attr<int>...=10; ? Mit Operatorenüberladung hab ich mich bisher noch nicht beschäftigt, davor schrecke ich zurück, das liegt mir gar nicht. Da weiss man nicht mehr, was ein = macht und ein + ! Also wenn ich Dich recht verstanden habe, muss ich bei den Wrappern für struct Gadget und den daraus resultierenden Klassen darauf achten, dass die setGadgetAttr-funktionen verwendet werden, v.a. wenn die Gadgets schon Verwendung finden. Die Wrapperklassen für struct screen und struct window müssen wiederum andere Dinge berücksichtigen, wenn sie Setter für Attribute (oder überladene Operatoren) anbieten. Denke mal z.B., dass wenn man in C ne Imagestruktur mit Dimensionen füllt, die nicht zu den Bilddaten passen wird Müll dargestellt. So was will ich nach Möglichkeit verhindern! BTW: Gibst Du auch Kurse in C++, operator overloading, Delegation, Patterns (Letztere beiden kenne ich zwar, hab sie aber seltenst verwendet)?  [ Dieser Beitrag wurde von Reth am 06.12.2005 um 16:11 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2005, 16:02 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, das war der Ausgangspunkt. Wichtig dabei ist, daß es ja für die unterschiedlichen Attribute trotzdem nur eine set... Funktion im AmigaOS gibt, weil das Attribut durch den TagKey, also einer compile-time integer Konstante bestimmt wird. Zitat:Nein, wenn TagItem-basierte Funktionen dahinter stecken, reicht eine generische Funktion, solange die korrekte Umwandlung in ULONG für TagValue möglich ist. Im Falle von String wird stattdessen ein Funktionsaufruf mit dem Typ (char*) benutzt, die Konvertierung von String nach char* macht der C++ compiler automatisch (auch via überladenen Operator). Der reinterprete_cast<ULONG> macht dann im nächsten Schritt das richtige. Zitat:Man sollte es auf keinen Fall übertreiben. Operatoren zu überladen macht nur dort Sinn, wo die Auswirkung des Operators intuitiv erfaßt werden kann. Was der überladene Operator bei button.label="Click Me"; machen soll, dürfte erfaßbar sein. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2005, 16:22 Uhr Reth Posts: 1858 Nutzer |
@Holger: Huch, da war ich mit meiner Änderung wohl zu lahm! Wie kann ich denn in ner Template-Klasse wie Attr<T> nen Operator überladen, so dass er für String mit char * arbeitet und dann nen reinterpret-Cast macht, für int aber normal funktioniert (also mit ULONG)? [ - Antworten - Zitieren - Direktlink - ] |
|
07.12.2005, 22:22 Uhr Reth Posts: 1858 Nutzer |
Also konkreter gefragt: Wenn ich nun ne Reihe von Button-/Gadgetklassen zum Eigengebrauch machen will, welche alle im Prinzip ne Gadgetstruktur wrappen, dann würde ich ne abstrakte Basisklasse mit der Struktur und den notwendigen, immer vorhandenen Settern machen (Position und Größe). Die Setter könnte man so implementieren, dass ein Wert nur einmal gesetzt werden kann, was ich nicht gut finde. Oder die Setter rufen setGadgetAttr() auf und sind somit systemkonform, auch wenn die Struktur schon eingebunden ist. Man könnte das Setzen dieser immer wieder auftretenden Werte auch im Konstruktor übernehmen und die Setter weglassen, womit man verhindert, dass Programme, welche die Klassen dann benutzen diese Werte ändern, wenn die Gadgetstruktur in Verwendung ist. Ist es dann in C++ besser man arbeitet mit Templates und Operatoroverloading oder man nimmt den von mir sogenannten Java.Approach, indem man einen Setter für jedes Attribut bereitstellt und dazu dann noch Convenience-Setter mit der Möglichkeit Dimension-Objekte als Ganzes zu setzen? Bleibt nur ein Problem: Wie die ganzen möglichen Kombinationen aus Flags abdecken? Wenn das aufrufende Programm keine Ahnung von den Interna des AmigaOS hat, wäre eine Schnittstelle, welche die ganzen Mögkichen Flags kapselt ideal, dann muss man sich nicht erst einlesen, was welches Flag tut (wenn man z.B. nur nen Setter setFlags() anbieten würde), sondern die Schnittstelle ist so intuitiv, dass man sie direkt programmieren kann! Hm, das ist tricky. Selbst wenn man das mit Templates á la TAGITEMS realisiert, muss man bei der Verwendung die Flags und ihre Wirkung kennen. Bei "sprechenden Settern" entfällt das wenigstens zum Teil. Ciao [ Dieser Beitrag wurde von Reth am 07.12.2005 um 23:34 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 01:19 Uhr Holger Posts: 8116 Nutzer |
Zitat:Also SetGadgetAttr dient zur Manipulation von BOOPSI-Objekten, einschließlich Datatypes und ReAction. Für "GadgetStrukturen" dienen sie nicht. Also entweder Du benutzt immer BOOPSI, dann wrapst Du nur einen Pointer und darfst nie etwas anderes benutzen als SetGadgetAttr(...), oder Du wrapst eine GadgetStruktur im OS1.x-OS3.x Sinn, dann darfst Du SetGadgetAttrs gar nicht benutzen. Ich habe es vielleicht noch nicht deutlich genug gesagt, meine Empfehlung lautet für Position und Größe, sie überhaupt nicht manipulierbar zu machen. Die sollten über einen Layout-Mechanismus kontrolliert werden, der im Endeffekt nur von der Fenstergröße abhängt. Das erwartet man eigentlich seit OS2.0 von ordentliche Programmen. Zitat:Von essentiellen Attributen vielleicht, aber welche Attribute sind das? Im Praxisfall oft verdammt wenig. Also ja, aber sorgfältig auswählen. Zitat:Weder noch. Der Ansatz, bestimmte Attribute nur im Konstruktor anzugeben, ist schon sehr gut. Zum Beispiel ist es in der Praxis kaum sinnvoll, einen Slider zwischen horizontal und vertikal umschalten zu können. Bounds braucht man eigentlich überhaupt nicht, nur intern in der Implementation und die funktioniert eh ganz anders. Und die Attribute für die relevante Daten sollten nach dem MVC-Pattern an ein Datenmodell-Objekt delegiert werden, das könntest Du vielleicht von Swing kennen. Nur die ganzen convenience-Methoden/Attribute laß einfach weg. Zitat:Mhh, also button.setRelverify(true); oder button.setFlags(button.getFlags()|RELVERIFY); oder button.flags|=RELVERIFY; Mit gefällt schon die letztere Variante besser. Der Name des Flags taucht trotzdem in allen Varianten auf. Zitat: "Sprechende" Flag-Klassen bieten das auch. Lieber mehrere kleine Klassen als eine Mammut-Klasse. JComponent sollte doch ein gutes abschreckendes Negativ-Beispiel sein. (Von einigen seiner Unterklassen gar nicht zu reden) mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 08.12.2005 um 01:26 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 01:23 Uhr Holger Posts: 8116 Nutzer |
Zitat: Im Falle eines Gadget-Attributs kann es ruhig vom Typ Attr<char*> sein, weil das Attribute im AmigaOS auch so verarbeitet wird. Der Anwendungprogrammierer kann dann trotzdem String benutzen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 09:03 Uhr Reth Posts: 1858 Nutzer |
@Holger: Aber wie sieht dann die Implementierung des überladenen Operators = aus? Funktioniert die für char * genauso wie für int, so dass ich sowas machen kann: button.xPos=10; button.label="OK"; Wenn Button Attr<int> xPos; Attr<String> label; hat? Oder versteh ich da was grundsätzlich falsch? [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 09:50 Uhr Reth Posts: 1858 Nutzer |
Hi Holger, danke für Deine Hilfen! [quote] Original von Holger: Zitat: Wo kann man den sowas nachlesen (also das man das seit 2.0 so erwartet)? Einige Hinweise stehen ja in den Includes selber, aber im Amiga Intern und Profi Know How bin ich bisher über sowas noch nicht gestolpert, vielleicht übersehen? Boopsi nehm ich momentan nicht, sondern nur Gadgets. Für ne Fensterimplementierung müsste ich mir ja dann noch nen Layoutmechanismus einfallen lassen, der solche Aufgaben übernimmt. Uff, den vertag ich wohl erst mal und mach absolute Positionierung (hab ich bisher ja auch). Zitat: Bei sprechenden Flag-Klassen müsste man aber für jedes Flag bei jeder Struktur (Gadget, Window, ...) ne eigene Klasse machen. Ziemlich aufwendig. Der generische Ansatz von Dir mit den typisierten TAGITEMS wäre hier hilfreicher, dabei müsste aber der verwendende Programmierer wieder alle möglichen Flags kennen. Das wollte ich gerad vermeiden, da ich aus eigener Erfahrung weiss, wie aufwändig es ist, die ganzen Flags nachzulesen in den Includes (obwohl Studio AIX mit Refernzen hier schon sehr hilft). Dein setRelverify(tru); ist ja so ein sprechender Setter, und stimmt, man müsste dann auch für jedes Attribut so einen Setter anlegen (und nen Getter), wobei man dann in den Bereich der von Dir zitierten Component kommt. Alternativ könnte man noch Attributklassen machen, eine/mehrere für Gadget, eine/mehrere für Window etc. Diese könnte man dann der Komponente übergeben. Wenn Du magst, kann ich Dir ja mal die Hierarchie schicken, sobald sie angelegt ist. Mache erst einmal nur die Komponenten, welche ich brauche. Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 13:36 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das steht nicht in den Programmierhandbüchern, allenfalls im Style-Guide. Aber vor allem die Anwender erwarten font-sensitive Oberflächen. Commodore selber hat damals auch bei vielen mitgelieferten Programmen damit auf sich warten lassen. Was daran liegt, daß es nicht ganz einfach ist, und sowohl die gadtools.library, als auch die einfachen BOOPSI Klassen keinerlei Hilfestellung liefern. Deshalb benutzen die meisten Programmierer ja MUI oder ReAction. Spätestens wenn ein Programm verschiedene Sprachen unterstützen soll, verbieten sich hardcodierte Größen/Positionen. Zitat:Überleg Dir gut, ob sich der Aufwand mit plain Gadgets überhaupt lohnt. Am Ende nutzt es vielleicht eh keiner, weil man doch lieber MUI oder ReAction nutzen will. Zitat:Richtig gemacht, ist der Aufwand nicht höher als die Definition einer enum, spricht im Endeffekt eine Zeile pro Konstante plus einem konstanten Aufwand für den Rahmen. Zitat:Aber beides ließe sich bestimmt kombinieren. Ich habe, wie gesagt, schon mal mit MUI und einem solchen Ansatz herumgespielt. Hauptproblem war, daß ein Objekt, wie z.B. ein deklariertes Attribut immer mindestens 1 byte Platz verbraucht, auch dann, wenn es eigentlich keine Eigenschaften besitzt, sondern nur an die set-Methode delegieren soll. Bei n Attributen werden also n bytes pro Objekt verschwendet. Dafür wollte ich noch eine Lösung finden. Zitat:Das geht ja dann in die Delegation-Richtung. Eine solche Attributklasse für bestimmte Flags entspricht der Flags-Klasse, wie ich sie meinte. Und ausgelagerte Attributklassen für den eigentlichen Inhalt einer Komponente, dem Text eines Label oder eines StringGadgets, Range und Position eines ScrollBars entsprechen den Datenmodellen. Zitat:Gerne. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 08.12.2005 um 13:39 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 16:49 Uhr Reth Posts: 1858 Nutzer |
Hi Holger,Zitat: Wie würde sich das denn gestalten? In einer Hierarchie abgeleitetr Klassen oder eher über Templates (wie ich vermute)? Zitat: Hm, wenn man das aber amigaseitig bei nem Gadget (um bei meinem Bsp. zu bleiben) machen würde und eine Trennung von Darstellung und Datenmodell anstrebt und Gadgets dann in Wrapperklassen wie z.B. Button versteckt, dann bleibt ja für die Darstellung nix mehr, da alles im Datenmodell steckt: Flags, Dimension, Position,... Oder würdest Du dann Dimension, Position und ggf. Texte und Bilder von Buttons nicht ins Datenmodell nehmen?! Zitat:Zitat: Mach ich gern, wird aber noch ne ganze Weile dauern, da ich nur selten zum Programmieren komme. Dann wirds auch nur die Klassen enthalten, welche ich z.Z. selber benötige. Das Framework soll ja eigentlich kein öffentliches werden, sondern nur mir jetzt und in Zukunft die Programmierung das Amiga API erleichtern und mir C++ näher bringen. Letzteres scheint gar nicht so gut zu klappen, mach glaub immer noch eher Java-Stil!  Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 17:48 Uhr Holger Posts: 8116 Nutzer |
Zitat:Da müßte ich ers mal selber nachschauen, was in den C++ Büchern empfohlen wird. Ich könnte mir zwar ad-hoch jetzt etwas ausdenken, aber wenn das dann zu weit von gängiger bzw. empfohlener C++-Praxis entfernt ist, wäre das kontraproduktiv. Zitat:Du denkst zu sehr in den alten AmigaOS-Strukturen, mit denen man sich eigentlich lieber nicht beschäftigen sollte. Was zeichnet denn in der Praxis z.B. einen Button aus? Einen Label-String und/oder ein Icon und im Falle des Label-Strings evtl. ein markierter Buchstabe für den Short-Cut. Dimension und Position sind Sache des Layouts, interessiert mich als Anwendungsprogrammierer überhaupt nicht und Flags bei einem Button? Kenne ich keine. Sicher, in den Gadget-Strukturen gibt es allgemeine Flags für Intuition, aber der Wert ist für jeden Button identisch. Rahmen und Füllfarbe sollten nur im absoluten Ausnahmefall von denen einer normalen Buttons abweichen... Ähnliches bei einer Checkbox, gleiche Attribute, plus einem boolschen Selected-Attribut. Versuch Dich an der Praxis desjenigen, der die Komponenten hinterher benutzt zu orientieren. Was braucht er wirklich: Button erzeugen, Text/Icon setzen eindeutige ID zuordnen für die auszuführende Aktion, übersetzte String im locale-catalog, Hilfethemen. Ein Gadget besteht von der Logik her wirklich aus fast nichts. Seiner Identität, Position in der Gadget-Hierarchie, den View-Optionen und dem Datenmodell. Man beachte, daß mehrere Gagdets sich ein View-Setup und/oder ein Datenmodell teilen können. Im Gadget direkt sind nur die nicht gemeinsam nutzbaren Eigenschaften enthalten. Zitat: Der Stil ist nicht so sehr von einer Programmiersprache geprägt. Es hängt mehr von der Herangehensweise bei der Problemlösung ab, eben den Design-Patterns, die man (er)kennt und auch anwenden kann. Klassen und Objekte alleine sind kein Allheilmittel. Falsch benutzt können sie die Produktivität auch bremsen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2005, 22:33 Uhr Reth Posts: 1858 Nutzer |
@Holger: Hm, so kompliziert wollte ich es mir eigentlich nicht machen, von wegen Datenmodell für mehrere Gadgets. Die Trennung ist eh sehr schwer, ein reines MVC wurde bei Java auch nicht geschafft. Man kann auch einen Button innerhalb einer Komponente mit setLocation umbewegen, egal ob in der umgebenden Komponente ein Layout definiert ist oder nicht. Wie soll man denn GUI-Klassen anlegen, denen man keine Position und Größe geben kann, da muss man ja einen Layoutmechanismus bauen, dem man sagen kann, hier haste ne Komponente, mach sie mal in der und der Größe da und da hin, oder? Das ist ganz schön aufwendig. V.a. was macht man mit Buttons, die ein Bild bekommen sollen und deren Größe man nicht angeben kann? Wenn man das Bild nicht skalieren will, wird der Rand größer oder das Bild zu klein, wenn man diese Buttons in ihrer View nur durch LAyoutmanager bestimmen lässt?! Ich wollte mir zunächst einmal einfache Wrapperklassen schreiben, die es mir erlauben relativ leicht eine Oberfläche zu basteln. Ein GUI-Builder würde evtl. auch gehen, habe aber schon ewig keinen mehr probiert und mit dem ReActor bin ich beim letzten Versuch nicht so klar gekommen. Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 01:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist nicht kompliziert. Der erste Schritt besteht in der Aufteilung von Attributen in mehrere Objekte, wie Du sie selbst schon angedeutet hast. Zitat:"rein" gibt es in der Praxis sowieso nicht. Aber es gibt in Swing einen brauchbaren Ansatz, der in der Praxis funktioniert. Zitat:Ja, es geht auch nicht darum, jegliche ungewünschte Aktion zu verhindern, sondern hauptsächlich darum, daß Du keine Arbeit und Zeit darin investierst, mehrere überladene Attribute-Setter zu implementieren, die man in der Praxis gar nicht braucht. 99% aller Layout-Manager benutzen setBounds(...) und der Rest ließe sich auch ohne großen Mehraufwand so umschreiben, daß er setBounds(...) benutzt. setX(), setY(), setWidth(), setHeight(), setLocation(), setSize() kann man sich also eigentlich sparen. Zitat:Das gibts dann schon, aber wie gesagt, man kann an den überladenen Methoden sparen. Und da das Programm weiß, wann es layouten muß, könnten die Layout-Manager auch direkt in die bounds schreiben und danach die zugehörigen set() Methoden auf den Gadgets aufgerufen werden (für Boopsi). Im Falle von OS1.x-gadget-Strukturen werden die Gadgets einfach komplett während des Layouts-Prozeß ausgehängt und danach wieder eingehängt. Das ist fast das einzige Mal, daß man das überhaupt braucht. Zitat:Normalerweise kennen Bilder selbst schon ihre Größe. Und dann gibt es minimum, preferred und maximum size (i.A. read-only). Zitat: Ja, aber auf plain Gadgets zu setzen, bedeutet schon Mehraufwand für Dich. ReAction und MUI bieten von Hause aus schon eine Menge, das Du noch implementieren müßtest. Es sollte eigentlich auch gar nicht so schwer sein, die Klassen so zu entwerfen, daß ein Wechsel zwischen MUI und ReAction möglich ist. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 08:44 Uhr Reth Posts: 1858 Nutzer |
[quote] Original von Holger: Zitat: Könnte aufgrund von Mehrfachvererbung schon gut gehen, wenn man v.a. wirklich das Modell von der View trennen will. Denn dann gibts für die View erstmal nur die Bounds, Texte und Bilder für Knöpfe etc. gehören dann ja zum Model. Zitat:Zitat:Das gibts dann schon, aber wie gesagt, man kann an den überladenen Methoden sparen. Und da das Programm weiß, wann es layouten muß, könnten die Layout-Manager auch direkt in die bounds schreiben und danach die zugehörigen set() Methoden auf den Gadgets aufgerufen werden (für Boopsi). Im Falle von OS1.x-gadget-Strukturen werden die Gadgets einfach komplett während des Layouts-Prozeß ausgehängt und danach wieder eingehängt. Das ist fast das einzige Mal, daß man das überhaupt braucht. Hm dann könnte man die Bounds private und über friends-Kontruktionen nur dem Layoutmanager zugänglich machen, dem Anwendungsprogrammierer erlaubt man dann die Angabe nur über den Konstruktor. Wenn er dann aber die Komponente aus dem Layout entfernen, ändern und wieder einfügen möchte (bzw. die Komponente nur ändern möchte und der Layoutmanager kümmert sich um die korrekte Wiederintegration), dann würde das nicht gehen, sondern ein neues Komponentenobjekt müsste her. Zitat: Das stimmt, wenn der Button bzw. der Layoutmanager aber ne Änderung des Bildes mitbekommen soll, muss er ne Benachrichtigung bekommen. Zitat: Das stimmt auch wieder, nur habe ich bisher noch nie mit MUI und ReAction gearbeitet, da ich möglichst ohne 3rd Party Software auskommen wollte und das Framework auch nur für den heimgebrauch sein soll (wobei ich dann schon ne möglichst flexible Sache machen wollt, die auch vom Design her stimmt ).Wo bzw. wie kann man denn gutes Design usw. lernen? Denn damit hab ich immer wieder Probleme, trotz jahrelanger Programmiererfahrung! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 09:08 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Geh mal in eine Uni-Bibliothek Deiner Wahl und leih Dir dort ein gutes Buch über Softwaretechnik.  Alternativ kann ich mal nachschauen, was für Skripte (als Pdf) ich zu diesem Thema noch Zuhause habe und sie Dir per email schicken. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 09:32 Uhr Reth Posts: 1858 Nutzer |
@Mad_Dog: Danke, wäre klasse! Tja Softwaretechnik hab ich leider nie gehört, das Angebot an Vorlesungen und Themen war zu groß, als das man alles, was interessant ist hätte hören können! [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 13:32 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Ich geb Dir mal den Link zu den entsprechenden Vorlesungsskripten: http://www.it.fht-esslingen.de/~asbeck/inf2/skript.html Hoffe, Du kannst was damit anfangen. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 14:27 Uhr Reth Posts: 1858 Nutzer |
@Mad_Dog: Danke, werd mal reinlesen in das Skript. Hehe, bin hier in Stuttgart, dachte nicht, dass Du gleich "nebenan" sitzt! [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 14:54 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Im Moment sitze ich hier im Backnang bei der Arbeit (Praxissemester), aber wohnen tue ich in Bad Cannstatt...-- http://www.norman-interactive.com [ Dieser Beitrag wurde von Mad_Dog am 09.12.2005 um 14:54 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 19:12 Uhr Holger Posts: 8116 Nutzer |
Zitat: Hab's mal überflogen, scheint ziemlich allgemein gehalten und eher von der Art, die einen Hobby-Programmierer abschrecken wird. Ich glaube, für Reth wären Sachen mit mehr Praxisbezug besser. Ich kann jetzt auch erstmal nichts online-mäßiges nennen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2005, 19:41 Uhr Holger Posts: 8116 Nutzer |
@Reth: Vielleicht hilft das ein bißchen: http://www.gdv.uni-hannover.de/doc/cpp/TIC2Vtwo-distribution/html/Chapter10.html die kompletten Bücher gibt's u.a. hier http://java.freeq.de/eckel/index.html aber googlen hilft, es müßte z.B. auch pdf-Versionen davon geben. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Strukturen, was passiert wenn... | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|