ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Holger
Nutzer
26.07.2011, 15:27 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Gerne. Eine Action ist mehr als nur ein Notify-Mechanismus. Es ist die Abstraktion einer auslösbaren Aktion, die sowohl den Empfänger eines Action-Events als auch das Datenmodell enthält. Wenn ein GUI-Element, gleich welcher Art, an eine Aktion gebunden wird, entsteht eine Zwei-Wege Kommunikation. Die Aktion teilt mit, wenn sich Eigenschaften der Aktion ändern (am Wichtigsten: enabled-Status, dann Default-Werte für Beschriftung und Icons, im Falle von Toggles der aktuelle Auswahlstatus), während die GUI-Elemente ein auslösendes Ereignis an die Aktion melden. Zitat:Nein, Du bist nur nicht in der Lage, das, was Du machst, mit formellen Begriffen zu erklären. Das ist, wenn es ums Programmieren geht, bedenklich. Zitat:Ganz genau. Deshalb ist es von Vorteil, die korrekten Begrifflichkeiten zu kennen und benutzen zu können. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
26.07.2011, 00:40 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Die ClipRegion ist NULL, solange Du keine gesetzt hast, d.h. Du rufst OrRegionRegion mit einem NULL-Pointer auf. Vielleicht mag das System das nicht so sehr. Zitat:Natürlich macht es einen Unterschied, das eine ergibt einen Sinn, das andere nicht. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
25.07.2011, 14:36 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Spielt keine Rolle. Zitat:In meinem Code wird aber erst nach EndRefresh() gezeichnet, deshalb findet die VerUNDung nicht statt. Zitat:Nein. Nur die ODER-Operation muss zwischen BeginRefresh und EndRefresh stattfinden, um sicherzustellen, dass der Layer gelockt ist. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
24.07.2011, 00:58 Uhr [ - Direktlink - ] |
Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren Zitat:Es ist vollkommen egal, ob er einen A4000 hat oder nicht. Niemand hat vor, ihm Ärger zu machen. Falls er doch welchen bekäme, wärst Du der einzig Schuldige, weil Du es einfach nicht gebacken bekommst, über Dinge, die nicht in die Öffentlichkeit gehören, die Klappe zu halten. Du hast es also geschafft, ihm ein ROM zu schicken? Wieso schaffst Du es dann nicht, ihm auch Deine guten Ratschläge direkt zu schicken? Abgesehen davon scheinst Du immer noch nicht mitbekommen zu haben, dass die Hauptperson dieses Threads nicht zum ersten Mal einen Thread mit einer Problembeschreibung startet, in dem er dann diverse einfache Lösungen ignoriert, um sich ewig mit der, die ihm am meisten Probleme bereitet, zu beschäftigen. Dein ROM zu benutzen, gehört offensichtlich zu den einfachen Lösungen. Allerdings nach allen Beobachtungen wahrscheinlich nur solange er sie nicht ausprobiert. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
24.07.2011, 00:47 Uhr [ - Direktlink - ] |
Thema: WiFi µA1/OS4 hängt sich auf !
Brett: Amiga, AmigaOS 4 Zitat:Wenn es sich wirklich so verhält, dass das Setzen von "RUN <>NIL: " vor einen Befehl dessen Funktionsweise verbessert, wäre das möglicherweise ein Indiz dafür, dass seine Position im Startskript zu früh ist, da irgendetwas, dass beim synchronen Ausführen erst danach kommt, die Verbesserung bewirkt. Gibt natürlich noch ein paar andere Möglichkeiten. Vielleicht haben von RUN erzeugte Prozesse eine andere Default-Stackgröße als die Boot-Shell. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
24.07.2011, 00:34 Uhr [ - Direktlink - ] |
Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren Zitat:Gut, dass Du es nochmal erwähnst. |
|||||
Holger
Nutzer
24.07.2011, 00:30 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Ich hoffe, er hoppelt nicht, wenn er mit der Maus gezogen wird, denn dann machst Du etwas grundsätzlich falsch. Wenn dagegen ein Slider von einer anderen Quelle aus gesetzt wird und größer als sein Wertebereich ist, ist das vollkommen normal, dass er nicht jede Pixelposition annehmen kann. Das wäre selbst dann so, wenn er intern alles auf 0-0xffff Bereich umrechnen würde. ListViews, deren Scroller gleich hoch sind, die aber nur zeilenweise scrollen, wären ein typisches Beispiel. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
24.07.2011, 00:26 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Zwischen action und onclick besteht ein semantischer Unterschied. Gemeinsam ist, dass der Bezeichner "ping!" von der Anwendung definiert sein muss und der erzeugte Button diese Aktion auslöst. Aber das Verhaltens eines Buttons wird vom System bestimmt. Ich will gar nicht, dass der Schreiber eines Skins die Möglichkeit bekommt, Buttons zu definieren, die sich völlig anders verhalten, auch wenn das auf anderen Systemen hipp ist. Das Binden einer Aktion führt dazu, das ein Auslösen des Button, egal ob das ein Klick oder ein bestimmter Tastendruck ist, die Aktion auslöst. Wenn also beispielsweise das System definiert, dass Buttons ausgelöst werden können, wenn er den Fokus hat und die Leertaste gedrückt wird, dann soll der GUI-Designer nicht bei jedem Button onClick="foo" onKeyPress="foo" schreiben müssen. Außerdem liefert eine Aktion den Standardtext, den die Anwendung über dem systemspezifischen Locale-Mechanismus ermittelt als Beschriftung und, wie bereits gesagt, auch den logischen Zustand bezügliche der Frage, ob die Aktion überhaupt ausgelöst wird. Bei einem Button mit einem Dutzend unterschiedlichen EventHandler weiß man nicht, wann der nun disabled sein soll und wann nicht. Und das den GUI-Designer innerhalb der XML-Datei schreiben zu lassen, halt ich für den falschen Weg. Zitat:Was natürlich eine Vortäuschung falscher Zuständigkeit ist. Es sieht so aus, als ob die XML-Datei die ID definiert. Aber da die Anwendung nur auf IDs zugreifen kann, die sie kennt, definiert in Wahrheit die Anwendung die Liste gültiger IDs und durch das, was sie mit diesen Elementen machen will, auch ihre Bedeutung. Dass der GUI-Designer auch noch bestimmt, welchen Range der Slider haben kann, setzt dem Ganzen die Krone auf. Zitat:Yep. Das tut der ListView und der ist Teil des Toolkits und somit der Anwendung, nicht der XML-Datei. So etwas will man auch nicht jedes Mal kompliziert mit XML-Code beschreiben. Zitat:Das sind, mit Ausnahme des TabViews, alles Gegenbeispiele. Alle diese Beispiele funktionieren, wenn man, wie von mir beschrieben die GUI-Elemente an ein anwendungsspezifisches Model bindet, womit die Bindung der GUI-Elemente untereinander unnötig wird. Nur im Falle der Tabs, von denen die Anwendung meistens in der Tat nichts wissen muss, würde man reine GUI-Elemente aneinander binden. Aber dieses Beispiel hinkt doch stark. Zitat:Iwo. So etwas will man im GUI-Code gar nicht machen. Allenfalls, in dem der Scroller ein Attribut arrows="true" bekommt. Aber wenn man es manuell machen will, gut, dann bindet man die Arrows an exakt dasselbe Datenmodell wie den Scroller, der ja nicht zum Selbstzweck existiert, sondern an irgendein anwendungsspezifisches Feature gebunden ist. Zitat:Mal abgesehen von Arexx, von dem ich nun wirklich nicht glaube, dass das in die Hände eines GUI-Designers gehört, sieht das ja alles fast so aus, wie ich es meine. Nur, dass diese Buttons und Menüpunkte keine Beschriftung haben, keinen Hilfetext und ihr korrektes Disablen bei nicht-Verfügbarkeit durch obigen XML-Code nicht gegeben ist. Es sei denn, es würde auch die etwas "magische" Definition existieren, dass der onClick-Handler auch den Zustand des Buttons bestimmt. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 23:40 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Die Sache, wie die Verknüpfung zwischen den zwei Clips im AmigaOS implementiert ist, wusste ich nicht, sonst hätte ich nicht gefragt, was das Setzen des Clips vor BeginRefresh bewirkt. Das war nicht rethorisch gemeint. Zitat:Einiges geht unter, wenn so viel auf einmal kommt. In diesen Punkten dachte ich eher, dass Du es schon verstanden hättest. Zitat:Die Verknüpung war (und ist) das Konzept. Wenn ich Beispielcode für eine konkrete Implementierung gehabt hätte, hätte ich ihn auch gepostet. Zitat:Das lässt sich ziemlich leicht überprüfen. ClipRegion hat nach BeginRefresh denselben Wert wie vorher, also NULL, wenn man keine eigene clip-Region gesetzt hat. Auch dann, wenn effektiv geclippt wird. Das habe ich für AOS3.x überprüft.Zitat:Ist das sicher, oder ne starke Vermutung? Aber allein vom Verhalten des Programms war eigentlich auch nichts anderes mehr möglich. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 02:33 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Also so in der Art müsste es gehen. code:BeginRefresh(window); struct Region* r=NewRegion(); OrRegionRegion(window->RPort->Layer->DamageList, r); // Für jedes eigene Objekt, das Refresh benötigt OrRectRegion(r, &rect); EndRefresh(window, TRUE); struct Region* oldR=InstallClipRegion(window->RPort->Layer, r); // Hier kommen die Zeichenbefehle fürs gesamte Spielfeld hin InstallClipRegion(window->RPort->Layer, oldR); DisposeRegion(r); -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 02:15 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Also, jetzt noch mal ganz langsam. Wenn Du BeginRefresh aufrufst, obwohl Du gar keine Refresh-Message bekommen hast, dann gibt es nichts, was neu zu zeichnen wäre, und damit wird auch nichts gezeichnet. Egal, wie Du Deine ClipRegion konstruierst, wird sie zwischen Begin- und EndRefresh mit dem Damage-basierten Clip AND-verknüpft und x AND 0 ist immer 0. Ohne Begin-/EndRefresh und ohne anderes zutun Deinerseits ist die Grundeinstellung kein Clipping. Wenn Du damit eine OR-Verknüpfung durchführst, ist das Ergebnis logischerweise wieder kein Clipping. Deshalb wird dann alles gezeichnet. Und jetzt kommt der Clou: keine der beiden Methoden kann man auf das gewünschte Ergebnis biegen. Denn die Erkenntnis des Tages ist, dass zwischen Begin- und EndRefresh immer eine AND-Verknüpfung zwischen dem System-Clip und dem User-Clip stattfindet, woraus sich schließen lässt, dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird. Das erklärt dann auch, warum es egal ist, ob man diese Region vor oder nach BeginRefresh setzt, sie wird davon gar nicht beeinflusst. Die Lösung wäre dann die am Anfang der Diskussion genannte Alternative, nämlich mit der Damage-Liste zu hantieren. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 01:26 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Warum sollten sie das tun wollen? Die Wertebereiche sind ja gerade deshalb unterschiedlich, weil Du einem bestimmten Gadgettypen den willkürlich gewählten Bereich von 0-0xffff aufzwingst. Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln. @Der_Wanderer: Mir ist ja schon bei Deinen Beispiel-XML aufgefallen, dass da nirgendwo schlüssig erkennbar ist, wie denn eigentlich die Anwendungslogik zum GUI kommt (oder umgekehrt). Da dachte ich noch, es läge an der Vereinfachung des Beispiels, aber jetzt bei der Binding Diskussion fällt es mir wieder auf. Wenn ich GUIs mittels XML erzeuge, dann definiert die Anwendung mögliche Aktionen und Daten und natürlich deren IDs. Diese werden von der XML-Datei referenziert, z.B. code:<vgroup> <hgroup> <button action="back"/> <button action="forward"/> <button action="home"/> </hgroup> <text-pane content="main-document"/> </vgroup> Da jedes GUI-Element an irgendeine anwendungsspezifische Logik gekoppelt ist, entfällt die Notwendigkeit, GUI-Elemente an andere GUI-Element zu koppeln, komplett. Alle GUI-Elemente, die an dasselbe logische Feature gebunden sind, sind implizit zusammengebunden. Und Regeln, die zwischen unterschiedlichen logischen Elementen bestehen, sind Teil der Anwendung, nicht des GUIs. So kann z.B. die Aktion "back" aus dem Beispiel dazu führen, dass der Status der Aktion "forward" zu <enabled> wechselt. Aber das tut er dann in jedem Fall, egal, wie das GUI aussieht, egal, ob die Aktion an einen Menüpunkt, einen Button oder ein Tastatur-Shortcut oder alles zusammen gebunden ist. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 00:51 Uhr [ - Direktlink - ] |
Thema: Unterschied zw. C und C++: Deklaration in while()?
Brett: Programmierung Zitat:Nein, das ist sogar ziemlich konsistent, wenn man die dahinterstehenden Regeln kennt. while erwartet in den Klammern einen Ausdruck der zu einem logischen Resultat (0 oder nicht 0) evaluiert werden kann. Die Anweisung Typ name=wert; ist kein solcher Ausdruck. (Im Gegensatz zur Zuweisung ohne Deklaration name=wert, das darf man nicht verwechseln) In for dagegen gibt es drei durch Semikolon getrennte Elemente, wobei das erste eine Anweisung (die auch ein Ausdruck sein kann) und das zweite der logische Ausdruck ist. for(;int i=0;) kannst Du genausowenig wie while(int i=0) schreiben. Und das wäre wiederum dasselbe. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
23.07.2011, 00:31 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Der Sinn von Begin/EndRefresh besteht darin, nur dorthin zu zeichnen, wo es aus Sicht das Systems nötig ist. Die hohe Kunst besteht nun darin, die Regionen, die aus Sicht der Anwendung aktualisiert werden müssen, damit zu verknüpfen. Wenn das nicht geht, braucht man zwei getrennte Zeichenvorgänge, mit dem Nachteil, dass Regionen, die aus beider Sicht einen Refresh benötigen, zweimal gezeichnet werden. Zitat:Ich verstehe immer noch nicht das Problem. EraseRect zum Löschen und dann das Sechseck drübergepinselt. Zitat:Das dürfte unter AOS 3.x ebenfalls Probleme bereiten. Um eine Hook-Funktion in C zu implementieren muss der h_Entry auf eine Compiler-spezifische Support-Funktion zeigen, die die Umgebung für die in h_SubEntry stehende C-Funktion einrichtet und sie dann aufruft. Alternativ kann man auch mit viel Magie die C-Funktion selbst dafür vorbereiten, dazu muss man die Registerübergabe deklarieren und das Sichern und Wiederherstellen der Umgebung (z.B. Pointer auf die globalen Variablen) aktivieren.Zitat:Was soll ich tun? Beim Thema MOS bin ich (leider) noch lange nicht (Ziel ist zwar schon, dass die Programme möglichst überall laufen, aber nicht das Primäre)! Wenn das in AOS4 auch ohne dem klappt, gut. Mit anderen Systemen kann man das nicht so machen. Zitat:Wie bereits gesagt, man muss herausfinden, was es bedeutet, wenn man es so macht. Es deutet alles darauf hin, dass eine so installierte eigene Clipping-Region mit der durch BeginRefresh installierten UND-verknüpft wird. Ist natürlich doof, wenn man eigentlich gerne ODER gehabt hätte. Und wenn Du schon dabei bist, Dein Beispiel zu überarbeiten, solltest Du ein wenig Aufmerksamkeit auf den Unterschied zwischen Public-Screen und Custom-Screen legen. Außerdem darüber nachdenken, ob es gut ist, eine Message zurückzuschicken und danach noch darauf zuzugreifen. Und ob es sinnvoll ist, NoCareRefresh anzugeben, wenn man doch eigentlich den Refresh selbst in die Hand nehmen will. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 16:19 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Nun, das & Zeichen muss für konformes XML als & geschrieben werden, ansonsten passt es. Du kannst die Korrektheit übrigens auch selbst überprüfen, in dem Du die Datei in einem Browser öffnest. Jeder aktuelle Browser hat einen XML-Parser. Gegebenenfalls musst Du noch den Prolog <?xml version="1.0"?> voranstellen, um den Parser glücklich zu machen. Zitat:Um Tags automatisch zu schließen, müsste der Parser wissen, welche Tags grundsätzlich keinen Content haben. Also müsstest Du eine DTD oder ein Schema oder ähnliches geschrieben haben, was ich bezweifle. Davon ungeachtet hat man bei XML wiederum den für Parser einfacheren Weg gewählt und verlangt grundsätzlich diesen Slash, der ja nun wirklich nicht weh tut. Stell Dir mal vor, Du müsstest jedesmal <checkbox></checkbox> schreiben. Wenn Du weniger schreiben willst, erlaube dem checkbox-Element, die Eigenschaften des zugehörigen Labels aufzunehmen. Checkboxen ohne Label sind ziemlich selten… Zitat:Na dann… -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 16:04 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Nein, das ist xhtml. Bei html brauchst Du bei diesen Elementen weder einen / im Tag, noch einen schließenden Tag. Diese haben per se keinen Inhalt. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 13:21 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Dann versteh ich das Problem nicht. Der graue Hintergrund wird doch beim Refresh wiederhergestellt. Zitat:Schonmal auf einem AGA-Screen mit hoher Auflösung und voller Farbanzahl einen kompletten Screen geblittet? Klar, dank interleaved BitMaps flimmert das nicht, das ruckelt. Der Ausgangspunkt war der, das Dank Clipping überflüssige Operationen nicht durchgeführt werden, was die Systemlast insgesamt reduziert. Und das ändert sich bei Verwendung einer Offscreen-BitMap nicht, im Gegenteil. Da sich die zu transferierende Datenmenge fast verdoppelt, ist es um so nützlicher, selbige zu reduzieren. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 13:10 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Es verhält sich aber so. Als ob "<vgroup" ein Makro für "<group orientation='vertical'" wäre. Wobei, natürlich nicht ganz, wenn Du es auch via "</vgroup>" schließen kannst. Zitat:Zusammen mit den anderen Dingen, die er toleriert, ist das Erlauben von eigentlich nicht übereinstimmenden Tags eine Zeitbombe. Es wäre gar nicht schwer, ein Beispiel zu konstruieren, bei dem nicht mehr klar ist, wie der Parser das interpretiert. code:Ich denke, Du weißt selbst, dass hier das schlimmste, das passieren kann, wäre, dass es auf den ersten Blick das tut, was der Programmierer wollte.<vgroup/> beliebiger Content <hgroup/> beliebiger Content </group> Wozu brauchst Du überhaupt die Definition von <group orientation=...>, wenn Du es nie benutzt? Definiere doch nur vgroup und hgroup, mit passenden End-Tags natürlich, und fertig. Zitat:Wie oft tippst Du das? Zitat:Die kommen dann zu einem anderen Zeitpunkt. Zitat:Im Rest der Welt wird zwischen dem Parser und der eigentlichen Anwendung unterschieden. Deshalb gibt es auch keine Toleranz im XML-Parser, die bei einer bestimmten Anwendung vielleicht einen Sinn ergeben würde. Deshalb bezog ich mich auch nicht auf die Frage, was der Parser macht, wenn ein Attribut ohne Wertzuweisung auftaucht, sondern darauf, dass die meisten Anwendungen das Ergebnis des Parsers über Funktionen abfragen, die im Falle eines nicht vorhandenen Attributs einen Leerstring zurückgeben, womit keine Unterscheidung zwischen explizit zugewiesenem Leerstring oder nicht vorhandenem Attribut stattfindet. Allerdings setzt ein validierender Parser natürlich für nicht angegebene optionale Attribute den Default-Wert ein, der in der DTD oder im Schema deklariert wurde, wenn es das gibt. Für bool'sche Schalter kann man somit natürlich einen Fall immer weglassen, bei clever gewähltem Default natürlich den häufiger auftretenden. Zitat:Genau. Und die Trennlinie wurde anders gezogen, als Du es gerade bevorzugst. Die halbe Sekunde, die man durch das Weglassen einfacher Anführungszeichen bei der manuellen Eingabe einspart, wurde zugunsten der Stunden Fehlersuche im XML-Parser geopfert. Zitat:Ja, er erzieht Dich zur Bequemlichkeit und zur Produktion von einem Haufen fehlerhaften XML, das, wie gesagt, Dir möglicherweise zu einem anderen Zeitpunkt mächtig auf die Füße fallen wird. Wenn Du es schon bequem haben willst, dann lass Dir von Deinem Parser nach dem toleranten Verarbeitungsprozess das äquivalente korrekte XML ausgeben und kopiere das in Deine Anwendung, auf dass die Fehler ein für alle Mal bereinigt sind. Und implementiere einen nicht-toleranten Modus für die finale Anwendung. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 11:23 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Das hat er doch alles schon haarklein erklärt. |
|||||
Holger
Nutzer
20.07.2011, 01:10 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Das ist auch nur eine hässliche Krücke, die die XML-Erfinder für XHtml eingeführt haben, mit dem unverständlichen Ziel, dass fehlerhafte Html-Parser XHtml lesen und wie eigentlich fehlerhaftes Html behandeln und verarbeiten können. Es dürfte kaum eine andere XML-Anwendung geben, die solche Attribute nutzt. Zitat:Das ist es. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 01:00 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Alles Trockenübung, zwischen Theorie und Praxis klafft ein Unterschied. Zitat:Hast Du es inzwischen unter AOS3.x ausprobiert? Zitat:Ja, wozu gibt es denn die Möglichkeit, mit einer Maske zu blitten? Zitat:Das bezweifle ich. Wie viele Spiele sind systemkonform programmiert und wie viele davon zeichnen nicht einfach alles neu? Zitat:Doublebuffering löst nicht die angesprochenen Probleme. Wenn Du eine Offscreen-BitMap benutzt, kannst Du alles exakt so machen, wie ohne. D.h. Du zeichest mit Clipping in die Offscreen-BitMap und blittest diese dann mit Clipping auf den Bildschirm. Du kannst es natürlich auch ohne Clipping machen, so wie Du es auch ohne Offscreen-BitMap ohne Clipping machen könntest. Die Auswirkungen sind die gleichen. Nur bei Flip-Buffer Strategien muss man ohnehin jedesmal alles neu zeichnen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
20.07.2011, 00:55 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Makro-XML? Das ist schon echt hart. Zitat:In dem er offensichtlich falsches erlaubt? Mir scheint, Du hast einen der wesentlichen Vorteile von XML nicht verstanden.Zitat:Stimmt. Mein Parser ist da etwas großzügig. Zitat:Die Begründung überzeugt mich nicht. Du kannst ja einfache Anführungszeichen verwenden, das ist in XML erlaubt und die müssen normalerweise nicht escaped werden. Warum Du sie jetzt auch noch unbedingt weglassen musst, um zwei Zeichen einzusparen, erschließt sich mir nicht. Das hat ja mit escapen nichts zu tun. Was mich aber noch mehr interessiert, was macht eigentlich </group fixwidth>? Attribute innerhalb eines schließenden Tags? Dein Parser ist wirklich verdammt tolerant, um nicht zu sagen, was auch immer er parst, es ist kein XML. Zitat:Es gibt in XML keine Attribute ohne Wertzuweisung, d.h. es müsste mindestens foo="" da stehen. Wobei die meisten Funktionen des DOM-API oder XPath, etc. bei einer Abfrage eines Attributwertes nicht zwischen einem nicht vorhandenem Attribut und einem Leerstring unterscheiden. Man kann zwischen ihnen unterscheiden, entfernt sich aber von dem, was Standardwerkzeuge als typisch (und damit leicht zu benutzen) erachten. Bedenke bitte, XML wurde dazu design't, maschinenlesbar zu sein, nicht zwangsläufig komfortabel für den Menschen. Deine Optimierungen sind alle eher marginal, es stört kaum, wenn man immer formal korrekt <hgroup></hgroup> <vgroup></vgroup> und Anführungszeichen schreiben würde, aber wenn irgendwann mal jemand neue Features (wie wäre es mit einem GUI-Editor?) entwickelt, schaust Du blöd aus der Wäsche, wenn der scheinbar korrekte Code plötzlich nicht eingelesen werden kann, weil diese neue Software mit Deiner Interpretation von XML nicht klarkommt. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
19.07.2011, 12:23 Uhr [ - Direktlink - ] |
Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren Zitat:Stimmt, Du kommst noch nicht mal bis zur Kopierschutzabfrage. |
|||||
Holger
Nutzer
19.07.2011, 12:17 Uhr [ - Direktlink - ] |
Thema: Test
Brett: Forum und Interna Zitat: http://www.vesalia.de/d_sam460ex[7384].htm Gibt aber einen work-around. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
19.07.2011, 12:12 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung @Reth: Ich seh’ schon, da wird ein Beispielsprogramm benötigt. Allerdings weiß ich nicht, wann ich die Zeit dafür habe… -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
19.07.2011, 12:10 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Nein, jetzt noch mal ganz ausführlich. Du hast eine Klasse x, die eine Funktion f definiert. Und Du hast ein Stück Code, das diese Funktion f aufruft, aber zur Laufzeit auf f' umgebogen wird, weil es sich bei dem Objekt um eine Unterklasse von x handelt, die f überschreibt. Überladen ist eine Funktion, die unterschiedliche Versionen anbietet, die aber typischerweise das gleiche machen, von denen zur Compilezeit aufgrund der Aufrufparameter die richtige ausgewählt wird. code:Das ist überladen.int min(int x, int y) { return x<y? x: y; } long min(long x, long y) { return x<y? x: y; } float min(float x, float y) { return x<y? x: y; } Wenn Du in einem GUI-Tree, deren Elementtypen Du zur Compilezeit gar nicht kennst, für die Elemente die jeweils richtige Funktion aufrufen willst, dann geht das nur, wenn die Elementtypen die entsprechende Funktion des Basistypen überschrieben haben. Oder Du etwas ganz anderes, viel komplizierteres machst. Zitat:In Assembler gibt es gar keine Funktionssignaturen, daher ist die Frage nach dem Überladen sinnlos, in C ist es per se nicht möglich, da Überladen sich ausschließlich auf die Sprachmittel beschränkt. Überschreiben kann man dagegen in beiden Sprachen implementieren. Zitat:Nein, das ist überschreiben. Und in diesem Falle auch im wörtlichsten Sinn, denn Du überschreibst den ursprünglichen Hook-Pointer. Überladen wäre es, wenn es mehr als einen Hook-Pointer für unterschiedliche Parametertypen gäbe. Ich weiß, deutsche OOP-Anleitungen bringen das gerne durcheinander... Zitat:Ja, wie gesagt, das ist der Unterschied zwischen dem Entwickeln einer Anwendung und eines Toolkits. Du kannst gar nicht wissen, wie schnell der Layout-Prozess geht, wenn Du gar nicht weißt, wie komplex das Layout einer späteren Anwendung sein wird. Zitat:Genau so sollte es auch beim Layout sein. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
18.07.2011, 21:47 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Wenn Du die Größe einer Komponente setzt, muss gegebenfalls, das Layout sämtlicher enthaltener Komponenten berechnet werden. Natürlich kann man grundsätzlich das komplette Layout neuberechnen, sobald eine Komponenten ihre Größe ändert, aber... Wenn Du bei einer SplitPane den Divider mit der Maus ziehst, willst Du mit Sicherheit nicht das Layout dieser Komponente und sämtlicher enthaltenen Komponenten neu berechnen, während der Benutzer einen eingefrorenen Mauszeiger sieht. Da Du während der Entwicklung Deines Toolkits nicht weißt, wie komplex das Layout einer konkreten Anwendung (falls es je eine gibt) wird, musst Du eine entsprechende Strategie entwickeln, um Layout-Operationen nicht an Operationen zu koppeln, die eigentlich LowLevel sein sollten. Zitat:Nein, das ist "überschreiben". "überladen" ist es, wenn man mehrere Versionen mit unterschiedlichen Parameter(typen) hat. Zitat:Sehr empfehlenswert. Zitat:Das ist bei BOOPSI ein und dasselbe... Notify ist nur ein spezielles Target für das, was Du beim Binding machst. Die Funktionsweise hängt nur davon ab, wie man die Objekte miteinander verknüpft. Und es heißt einheitlich "notify". -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
15.07.2011, 18:26 Uhr [ - Direktlink - ] |
Thema: Das Forum schneckt!
Brett: Forum und Interna Hatte heute auch ein paar Mal „Internal Server Error“. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
15.07.2011, 18:14 Uhr [ - Direktlink - ] |
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung Zitat:Du verwechselst Größenänderung mit Layouten. Ein Balance-Widget oder eine Split-Pane ändert lediglich die Größen seiner Kinder. Der Layout-Prozess läuft genauso wie das Zeichnen ab: vorhergehende Operationen, wie z.B. eben jenes Größen ändern, markieren Objekte als layouttechnisch dirty, das kann sehr viele Objekte betreffen, und hinterher wird von der Wurzel ausgehend das gesamte Layout aufgefrischt. Wobei Objekte, die nicht dirty sind, je nach Kontext übersprungen werden können. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
15.07.2011, 14:47 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Welcher jetzt? -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |