ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Holger
Nutzer
05.08.2011, 17:34 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Ja, je nachdem, wo der brennende Rechner steht, würde ich auch nicht mehr unter den Schreibtisch krabbeln. Da hilft nur der Weg zum Sicherungskasten, falls der nicht zu weit weg ist. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
05.08.2011, 17:25 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Da musst Du es aber von Hand programmieren. Der in dem Beispiel gezeigte Fall, dass man die SuperBitMap von Hand anlegt, sollte der Sonderfall sein. Was Dir SuperBitMap-Fenster außerdem abnehmen, ist das Nachdenken über systemseitigen Damage, da die entsprechenden Regionen automatisch wiederhergestellt werden. Was ich nicht genau weiß, ist, wie das System die programmseitigen Updates handhabt. Zitat:SuperBitMap Fenster sind keine Screens. Dein Scrollen einer SuperBitMap ist nichts anderes, als ein Blit von der SuperBitMap in die Screen-BitMap. Wenn Du Fenster verwendest, kannst Du keine Pointer-Updates oder ähnlich gelagerte Buffer-Techniken einsetzen. Zitat:Aber unter Verwendung der ClipRects? Theoretisch sollte die Größe der sowieso nicht geblitteten Bereiche überhaupt keine Rolle spielen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
05.08.2011, 12:12 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Aber auch kein guter Zeitpunkt, ihn an zu lassen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
05.08.2011, 12:02 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Na ja, nach meinem Verständnis wäre das gar nicht nötig, wenn man zuerst alles in die Offscreen-BitMap rendert und diese dann in das Fenster blittet. Übergroße BitMaps brächte man dazu gar nicht. Zitat:Ich dachte, das wäre sowieso der Fall? -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
04.08.2011, 13:42 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Nein, ich meinte, schau Dir mal SuperBitMap-Refresh an. Das ist letztendlich ein Art von Double-Buffering, nur weiß ich nicht, ob sie für Deine Zwecke brauchbar ist. (Diese Methode wird halt selten benutzt). Zitat:Das ist doch exakt die von Thore beschriebene Holzhammer-Methode. Wie gesagt, seit AOS3.0 gibt es bessere Methoden. RethinkDisplay berechnet übrigens die Strukturen aller Screens neu und ist somit nur bedingt als systemkonform zu bezeichnen. Zitat:Nein, double-buffering verträgt sich überhaupt nicht mit Fenstern, Gadgets und vielen anderen System-Features. Zitat:Ich kann nur noch mal davor warnen, zu sehr an den veralteten RKRM-Beispielen zu kleben. Abgesehen davon, dass sie eben vor AOS3.0 oder teilweise auch vor 2.0 entstanden sind, habe ich erst letztens Beispielprogramme in den Fingern gehabt (im Zusammenhang mit diesem Thread übrigens), die schlichtweg deshalb broken waren, weil sie offenbar aus einer gedruckten Fassung eingescannt wurden und dabei ein paar Zeichen falsch waren oder verloren gingen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
03.08.2011, 01:09 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Wie bereits geschrieben, spielt es doch überhaupt keine Rolle, ob Du ein Hintergrundbild oder einen grauen Bereich blittest. Entweder Du bist schnell genug und der Hintergrund (egal ob Bild oder grau) ist wieder verdeckt, bevor der Benutzer es bemerkt, oder Du bist zu langsam und es flackert. Wenn es flackert hilft nur a) beschleunigen oder b) offscreen BitMap resp. double-buffering. Zitat:Auch das habe ich bereits geschrieben. Im selben Beitrag. Zitat:Das ist die Holzhammer-Methode. Dafür gibt es zwei bessere Alternativen. Die systemfreundlichste wäre es, die extra dafür vorgesehenen Funktion der intuition.library namens AllocScreenBuffer, ChangeScreenBuffer und FreeScreenBuffer zu benutzen. Da diese in der Anfangszeit von RTG Probleme auf RTG-Systemen bereiteten, hat es sich zu dieser Zeit eingebürgert, stattdessen einen doppelt hohen Screen zu verwenden und diesen über Änderungen des Offsets in ViewPort->RasInfo gefolgt von ScrollVPort zwischen der oberen und unteren Hälfte umzuschalten. Letzteres ist auch die Methode, die auf Systemen vor AOS3.0 funktioniert. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
03.08.2011, 00:22 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:http://aminet.net/package/pix/picon/kens_icons_v4 -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
03.08.2011, 00:17 Uhr [ - Direktlink - ] |
Thema: Amiga 500 Kuriositäten
Brett: Amiga, AmigaOS 4 Lieber spät als nie. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 19:29 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Nun ja, es kann immer passieren, dass für einen Refreshvorgang die gesamte BitMap benötigt wird. Ein in dieser Hinsicht schwankender Speicherverbrauch bietet keinen wirklich Vorteil, es sei denn, man will wirklich riskieren, dass mittendrin nicht mehr genug Speicher frei ist. Dann kann man zwar immer noch auf die flackernde Variante zurückfallen, aber ein Spielvergnügen wird das dann nicht. Dann lieber eine konsequente Mindestanforderung definieren, bei der das Spiel dann aber auch wirklich läuft. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 19:08 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Das ist Dir gelungen. Ist mir nämlich auch ins Auge gesprungen, dachte allerdings, dass da einfach mehrmals dieselbe Aktion als Dummy steht. Zitat:So sollte es sein. Hatte allerdings die Amiga-Workbench-Icons oder klassische Icon-Sammlungen, wie eben AISS im Hinterkopf. Zitat:Ja, es ist äußerst selten, das runterskalierte Bilder deutlich schlechter als speziell für die Auflösung designte aussehen. Da müsste sich der Designer schon sehr viel Mühe bei den niedrigen Auflösungen geben, wobei 24px ja noch relativ groß ist. Zitat:Sofern man unter einem Skin grundsätzlich 24/32Bit Grafiken versteht. Effizient kodierte Vektorgrafiken könnten durch ihre Anpassungsfähigkeit auch auf Systemen mit niedriger Auflösung, CLUT und wenig CPU-Kapazität etwas reißen. Aber wer optimiert heutzutage noch für diese Systeme… Zitat:Man muss eine Library nicht beim letzten Schließen freigeben. Exec ruft Expunge automatisch auf, sobald der Speicher benötigt wird. Man kann also durchaus die Library (und auch die Bilder) länger im Speicher halten. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 10:49 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung @Der_Wanderer: PS: Der Screenshot sieht ganz nett aus. Allerdings leidet er an der sehr verbreiteten Krankheit der Rahmen-Inflation. Zur Entschärfung empfiehlt sich, wenigstens den überflüssigen senkrechten Divider in der Mitte zu entfernen und vielleicht den Rahmen der Statuszeile unten zu entfernen und stattdessen eine einfache Trennlinie zwischen Statuszeile und Toolbar einzuführen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 10:46 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Da musst Du Dir jetzt die Frage stellen, wo drückt das Gehäuse beim zumachen womöglich gegen? Oder klemmt es vielleicht ein lose rumliegendes Kabel ab? -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 10:41 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Und warum verändert er sich? Weil die Implementierung davon ausgeht, dass alle Elemente gleich hoch sind (was sie offenbar nicht sind). Also kein Widerspruch zu dem von mir gesagten. Was ich dagegen von sich verändernden Scrollern halte, habe ich bereits gesagt. Ich bezweifle auch einfach mal, dass der Performancegewinn durch diese Technik real ist. Ich habe einfach schon zu viel Programmcode gesehen, der mit exakt dieser Technik exakt null Einsparung erzielt, weil der Overhead der Verwaltung solcher Strukturen höher als die mögliche Einsparung ist. Zitat:Sofern der Entwickler des ListViews wusste, was er tut. Der Adressat meines Beitrags waren nicht die Android Entwickler. Zitat:Nur braucht man dazu kein solch komplexes Konzept. Solche Datei-Listen sehen mit unterschiedlichen Höhen sowieso bescheiden aus, weshalb man i.A. das Layout auf eine bestimmte, angenommene Icon-Höhe fixiert und evtl. vorhandene größere Icons bei Bedarf skaliert. D.h. man braucht die Icons gar nicht, um das Layout zu berechnen. Insofern können die Elemente der Liste die Icons problemlos on-demand laden, ohne dass der ListView spezielle Algorithmen benötigt. Btw. schon mal bewusst wahrgenommen, was im Windows-Explorer bei hoher Systemlast oder wenig freiem Speicher passiert? Der lädt nämlich Icons auch bei Bedarf, bzw. asynchron ohne das GUI zu blockieren. Und wirft sie auch weg, falls der Speicher für andere Dinge benötigt wird. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
02.08.2011, 10:19 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Ich gehe mal davon aus, dass eine permanente BitMap in Komplettgröße in den meisten Fällen am effizientesten ist. Vielleicht lohnt es sich an dieser Stelle, sich doch mal das Verhalten der selten genutzen SuperBitmap-Refresh Fenster anzuschauen. Möglicherweise liefern sie schon das gewünschte frei Haus. Zitat:Ob der Hintergrund grau oder eine Umgebungsgrafik ist, spielt eigentlich keine Rolle. Der Unterschied wäre ja nur, dass es nicht mehr grau aufblitzt, sondern die Umgebungsgrafik durchblitzt, wenn man die Bereiche nicht trennt. Zitat:Wie bereits gesagt, alles neu zeichnen plus double-buffering, ohne mit dem System zu interagieren, ist der am häufigsten anzutreffende Algorithmus. Flüssig ist übrigens eher das Gegenteil von Ruckeln. Ob dabei etwas aufblitzt oder nicht, ist eine andere Frage. Oder ruckelt Deine Grafik? -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
01.08.2011, 20:27 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Nein, Zeichenoperationen gehen trotzdem direkt und sofort in die Zielbitmap, es wird lediglich geclippt. Das mag vielleicht im Falle von SuperBitmap-Fenstern anders sein, aber von denen war hier nicht die Rede. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
01.08.2011, 18:31 Uhr [ - Direktlink - ] |
Thema: Anfänger: DOS-Programm auf den Classic portieren
Brett: Programmierung Routinen zum Lesen und Schreiben von Dateiformaten bezügl. der Endianess zu fixen, setzt schon sehr viel Detailwissen zum Dateiformat und der Routinen voraus. Das wird alles andere als eine schnelle Portierung. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
01.08.2011, 18:24 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Die beschriebene Technik zielt auf folgendes ab: Statt von vornherein 3000 Objekte für 3000 Listenelemente zu haben, hast Du evtl. nur ein großen Plain-Text Objekt, von dem Du aber schon weißt, dass es 3000 Zeilen besitzt. Der List-View würde so implementiert sein, dass er ausschließlich für sichtbare Elemente ein Objekt anlegt. Diese Objekte würden dann on-the-fly auf dem Plain-Text generiert werden. Um daraus einen Nutzen zu ziehen, muss der Code aber einige Anforderungen erfüllen. So darf z.B. niemand auf die Idee kommen, durch die Liste zu gehen und für sämtliche Elemente das Layout berechnen zu wollen. Diese spezielle Implementierung muss davon ausgehen, dass alle Elemente dieselbe Höhe haben und eine bestimmte Breite erzwungen wird. Das entbindet Dich dann aber auch nicht davon, Pixelpositionen in 32 Bit zu berechnen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
01.08.2011, 18:14 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Ich glaube, Du hast eine völlig falsche Vorstellung davon, was BeginRefresh und EndRefresh machen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
01.08.2011, 18:12 Uhr [ - Direktlink - ] |
Thema: Neue Frage zu Überdeckungen
Brett: Programmierung Zitat:Erst einmal eine Verständnisfrage: der graue Hintergrund flimmert nur innerhalb des durch die ClipRects festgelegten Bereiches, oder? Zitat:Wenn Du obige Frage mit ja beantwortet hast, kannst Du versuchen, die die Zeit zwischen den Zeichenvorgängen zu verringern, d.h. den gesamten Prozess zu beschleunigen, oder Du brauchst eine Offscreen-BitMap. Natürlich kann man auch das EraseRect so begrenzen, dass Bereiche, die definitiv immer vom Spielfeld verdeckt sind, nicht extra gelöscht werden. Das reduziert mögliches Flimmern, löst das Problem aber nicht grundsätzlich. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
29.07.2011, 18:31 Uhr [ - Direktlink - ] |
Thema: Die Lügenbande, Teil zwo ! ;-)
Brett: Get a Life Zitat:Auf so etwas makroskopisches wie das Gehirn haben zufällige Quanteneffekte keinerlei Einfluss. Zitat:Die Physik funktioniert nicht, um Dir zu gefallen. Ob Du deterministisch denkst oder nicht, merkst Du selbst gar nicht. Wobei Du ja, selbst wenn die Prozesse nichtdeterministisch wären, Zeit Deines Lebens damit beschäftigt bist, Deine Gedanken in eine deterministische Form zu bringen. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
29.07.2011, 15:03 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Dein Scroller hat laut Deiner Aussage einen Range von 0-0xffff, also ohne Vorzeichen. Dass Du auch für Deine Gadget Koordinaten 16Bit-Zahlen benutzt, wusste ich nicht. Jetzt wird es für Dich wirklich mal Zeit, über Deine Konzepte nachzudenken. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
29.07.2011, 12:10 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Trotzdem gibt es niemanden, der Dich daran hindert, hier und heute das vergessene (oder auch das nie erlernte) zu erlernen. Es gibt genügend Möglichkeiten. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
29.07.2011, 11:54 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Das musst Du doch wissen. Also selbst mit Deinem Gewürge mit 0xffff als Maximum, sprich 16Bit-Arithmetik wären bei 16 Pixel hohen Zeilen 4096 Elemente ohne Probleme möglich, bzw. bei 20 Pixel pro Element immer noch deutlich über 3000. Wenn Du bei weniger Elementen Probleme hast, hast Du irgendwo Mist gebaut. Wenn Dir dagegen diese maximale Anzahl Elemente nicht reicht, musst Du ordentliche 32 Bit-Arithmetik verwenden (bzw. deren Bugs beheben, falls Du schon in 32 Bit gerechnet hast). -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
28.07.2011, 17:42 Uhr [ - Direktlink - ] |
Thema: Anfänger: DOS-Programm auf den Classic portieren
Brett: Programmierung @Dr_Chaotica: Halte Dich lieber an das von thomas geschriebene: vc programm.c -o programm Wenn Du es brauchst, dann gib -c99 an und in Hinblick auf die Fehlermeldung wäre -lm zu empfehlen. Aber den Rest, den solltest Du nicht brauchen, sonst wäre das ein Zeichen für eine fehlerhafte Compiler-Installation (und das sollte man immer als erstes beheben). Also: vc -c99 programm.c -lm -o programm sollte es eigentlich tun. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
27.07.2011, 11:43 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Genau das meinte ich mit: „es verführt zu ineffizientem Code“. Der wird einerseits geschrieben, weil der effiziente mit Assembler schwieriger zu machen ist oder nicht mit der damit verbundenen Denkweise zusammenpasst, andererseits ist ein ineffizienter Assemblercode oftmals bis zu einem gewissen Grad trotzdem noch schnell genug, um dann gerne in Situationen, die der Programmierer nicht getestet hat, einzubrechen. Zitat:Mir scheint, Du verwechselst gerade das Allgemeine mit dem Besonderen. Der allgemeine Fall lautet: Größe hat sich geändert ⇒ Layout muss neuberechnet werden. Das Besondere ist Deine Implementierung, die etwas tut, ohne dass es einen Grund dafür gibt. Defragmentiert Dein Programm auch beim Start die Festplatte? Oder ist es da doch naheliegend, Dinge nur dann zu tun, wenn es auch einen Grund dafür gibt? -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
27.07.2011, 11:36 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:So sollte es sein. Zitat:http://de.wikipedia.org/wiki/Interpolationssuche Richtig auf das konkrete Problem zugeschnitten implementiert, wirst Du keinerlei Performance-Unterschied zu Elementen fester Größe feststellen. Ein Scroller, der seine Knob-Größe während des scrollens verändert, ist für mich ein Armutszeugnis. Egal, welche große Firma das so macht… Zitat:Man sollte generell die Koordinaten der Kinder relativ zum Elternelement halten. Die Mehrkosten sind praktisch nicht existent: alle Zeichenoperationen eines Gadgets sind eh in der Anwendung relativ zu ihrer eigenen Position implementiert, die wiederum vom OS relativ zum Fenster ausgeführt wird. Die Relation zwischen Kind und Elternelement wird dagegen vor dem Beginn des Zeichnen vorberechnet und hat auf die Zeichenoperationen gar keinen Einfluss. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
27.07.2011, 11:10 Uhr [ - Direktlink - ] |
Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4 Zitat:Solange Du es genausowenig schaffst, seine Probleme zu lösen, solltest Du das Maul nicht so weit aufreißen. Selbstverständlich gibt es hier Classic-User. Aber der Anteil derer, die dafür auch noch AOS4 gekauft haben, dürfte wesentlich geringer sein. Und unter denen dann auch noch jemanden zu finden, der Lust hat, andererleute selbstgemachte Probleme zu beheben, ist wahrscheinlich aussichtslos. Du gehörst ja offensichtlich auch nicht dazu. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
27.07.2011, 10:43 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Das ist zwar ineffizient, dürfte aber kaum zum Problem werden. Zitat:Das ist schon ein anderes Kaliber. Gibt es denn irgendeinen sinnvollen Grund, warum Du das Layout neuberechnest, obwohl definitiv kein Objekt seine Größe geändert hat? Zitat:Viel mehr noch, es verführt zu ineffizientem Code. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
Holger
Nutzer
26.07.2011, 16:53 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Typischerweise, ja. Wenn man objekt-orientiert programmiert, hat ein Aktion-Objekt eine Methode, die diejenige ist, die vom Dispatcher beim Empfang eines Action-Events auch aufgerufen wird. Das Action-Event ist bereits ein abstrakter Ereignistyp, nicht mehr das auslösende Maus- oder Tastatur-Event. Zitat:„Das machen alle so“ ist keine sinnvolle Begründung. Es ist nunmal so, dass die Anwendungslogik die gültigen Werte vorgibt. Wenn der Amiga nunmal nur einen Lautstärke-Bereich von 0 bis 63 besitzt, ergibt es einfach keinen Sinn, dass der GUI-Designer etwas anderes festlegen kann. Und wenn das Programm AHI unterstützt und sich deshalb der erlaubte Range ändert, soll die Anwendung eine spezielle GUI-XML bekommen müssen? Bzw. muss man dann zwischen zwei unterschiedlichen GUIs wechseln, je nachdem, ob man jetzt AHI oder Paula benutzt? Zitat:Das geht alles von einem Workflow aus, bei dem der GUI-Designer letztendlich der Programmierer ist, bzw. eng an dessen Entwicklungszyklus gebunden ist. Nur brauche ich dann kein XML. Dann kann ich das Ergebnis gleich direkt in das Programm kompilieren. Der Vorteil einer XML-GUI ist aber eigentlich, dass man sie austauschen kann, ohne die Anwendung neu übersetzen zu müssen. Und dann ist eigentlich klar, wer den Rahmen vorgibt. Nämlich derjenige, der sich nicht ändern kann. Die kompilierte Anwendung. -- Good coders do not comment. What was hard to write should be hard to read too. |
|||||
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. |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |