Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 13
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Für mich ist es einfacher, ein Produktentwicklungsteam zu gründen, dessen Mitglieder zu einem vereinbarten Grad einen Gewinn aus dem Produktverkauf erhalten (vielleicht ist jemand der Projektideologe, jemand finanziert einen Anteil, jemand ist der Programmierer).
Und da jeder finanziell motiviert ist, auch die notwendigen Bibliotheken für die Schnittstelle als Teil des Projekts zu implementieren.
Für mich ist es einfacher, ein Produktentwicklungsteam zu bilden, dessen Mitglieder in einem vereinbarten Umfang einen Gewinn aus dem Produktverkauf erhalten (vielleicht ist jemand der Projektideologe, jemand finanziert einen Anteil, jemand ist der Programmierer).
Und da alle finanziell motiviert sind - im Rahmen des Projekts die notwendigen Bibliotheken für die Schnittstelle zu implementieren.
Ich habe den Thread gelesen und verstehe immer noch nicht, warum es notwendig ist, eine Schaltfläche auf Canvas von Grund auf zu zeichnen. Können Sie das ohne Emotionen erklären?
weil MT-Entwickler nicht allmächtig sind und es zeitaufwendig ist, sie mit belanglosen Anfragen zu belästigen
Warum das nützlich sein könnte:
1. die Schnittstelle auf der Bitmap ist schnell. Sie ist so schnell, dass sie vom System kaum zu unterscheiden ist. Ich habe zum Beispiel halbtransparente Elemente mit Farbverläufen implementiert, undselbst wenn sie sich bewegen, werden sie ohne sichtbare Verzögerung gerendert, wobei die Farbmischung und die Alphakanalberechnung bei anderen Objekten mit halbtransparenten Farbverläufen berücksichtigt werden.
2. Die Schnittstelle ist skalierbar. Sie können die Anwendung komplexer gestalten und sie wird nicht durch das Löschen und Erstellen einer großen Anzahl von Diagrammobjekten verlangsamt. Die Kosten für das Neuzeichnen sind minimal, es handelt sich lediglich um den Austausch eines Bildes in einer Tausendstelsekunde.
3. Es können sowohl vorgefertigte Steuerelemente als auch neue Steuerelemente erstellt werden, da Sie z. B. Ihren eigenen Ereignispool bereitstellen können:
OnMouseDown - drückt die LKM
OnMouseUp - drückt die LKM
OnMouseHoverOn - Bewegt den Mauszeiger über ein Objekt
OnMouseHoverOut - bewegt den Mauszeiger vom Objekt weg
OnMouseClick - Drücken und Klicken innerhalb der Objektgrenzen
OnMouseDblClick - doppelter Mausklick innerhalb der Grenzen des Objekts
OnDragStart - Ereignis, das einmal zu Beginn der Bewegung mit gedrückter linker Maustaste auftritt
OnDragMove - Ereignis, das bei der Bewegung mit der linken Maustaste erzeugt wird
OnDragEnd - Ereignis, das nach dem Verschieben mit LKM erzeugt wird
OnPut - Objekt wird in ein anderes Objekt umgewandelt
OnGet - das Objekt wird in ein anderes Objekt umgewandelt
OnFocus - Objekt hat den Fokus erhalten
OnBlur - Objekt verliert den Fokus
OnResize - Objekt hat Größe geändert
OnParentResize - das übergeordnete Objekt hat seine Größe geändert
OnKeyPress - eine gedrückte Taste
OnChange - Wert eines Feldes geändert
usw.
Warum das nützlich sein könnte:
1. die Schnittstelle auf der Bitmap ist schnell. Sie ist so schnell, dass sie von der Systemschnittstelle praktisch nicht zu unterscheiden ist. Ich habe zum Beispiel halbtransparente Elemente mit Farbverläufen implementiert, undselbst wenn sie sich bewegen, werden sie ohne sichtbare Verzögerung gerendert, wobei die Farbmischung und die Alphakanalberechnung bei anderen Objekten mit halbtransparenten Farbverläufen berücksichtigt werden.
2. Die Schnittstelle ist skalierbar. Sie können die Anwendung komplexer gestalten und sie wird nicht durch das Löschen und Erstellen einer großen Anzahl von Diagrammobjekten verlangsamt. Die Kosten für das Neuzeichnen sind minimal, es handelt sich nur um einen Austausch des Bildes in einer Tausendstelsekunde.
3. Es können sowohl vorgefertigte Steuerelemente als auch neue Steuerelemente erstellt werden, da Sie z. B. Ihren eigenen Ereignispool bereitstellen können:
OnMouseDown - drückt die LKM
OnMouseUp - drückt die LKM
OnMouseHoverOn - Bewegt den Mauszeiger über ein Objekt
OnMouseHoverOut - bewegt den Mauszeiger vom Objekt weg
OnMouseClick - Drücken und Klicken innerhalb der Objektgrenzen
OnMouseDblClick - doppelter Mausklick innerhalb der Grenzen des Objekts
OnDragStart - Ereignis, das einmal zu Beginn der Bewegung mit gedrückter linker Maustaste auftritt
OnDragMove - Ereignis, das bei der Bewegung mit der linken Maustaste erzeugt wird
OnDragEnd - Ereignis, das nach dem Verschieben mit LKM erzeugt wird
OnPut - Objekt wird in ein anderes Objekt umgewandelt
OnGet - das Objekt wird in ein anderes Objekt umgewandelt
OnFocus - Objekt hat den Fokus erhalten
OnBlur - Objekt verliert den Fokus
OnResize - Objekt hat Größe geändert
OnParentResize - das übergeordnete Objekt hat seine Größe geändert
OnKeyPress - eine gedrückte Taste
OnChange - Wert eines Feldes geändert
usw.
Ausführlich, danke!
@Igor Volodin, @Combinator, @Anatoli Kazharski
Ich beginne mit dem wunden Punkt.)
Die Frage, die mich am meisten beschäftigt, ist eine Art Universalität/Abstraktion für die Speicherung von Rendering-Parametern.
----
Soweit wir wissen, verwenden alle Steuerelemente die gleiche Schriftart, Hintergrundfarbe und Textfarbe, usw.
Wenn alle diese Parameter für alle Steuerelemente gleich sind, dann hat die Schnittstelle ein gemeinsames Aussehen mit einem einzigen Konzept.
Aber wie speichert man sie? Denn die Kontrollen verwenden nicht immer alle Parameter.
+ Das System wird durch die Tatsache kompliziert, dass Elemente verschiedene Zustände haben, die Schrift- und Hintergrundfarben unterschiedlich verwenden sollten. Sie lauten Aktiv, Deaktivieren, Über, Auswählen, usw.
+ Es gibt Gruppen von Controllern - Reliefs (wie Button) und Eingabefelder (wie Edit, List), und wann ist der Hintergrund, um sie zu rendern
----
In der aktuellen Arbeitsidee habe ich ein minimales Attributelement der Klasse GAttribBase, das 5 grundlegende Parameter enthält (Schriftart/Größe, Hintergrund-/Rahmenfarbe, Rahmengröße)
Diese Basiselemente werden verwendet, um ein Array für die Zustände der Klasse GAttribut zu bilden (Aktiv/Disabvle/Over/Select, usw.).
Und dann wird GAttribut für die verschiedenen Elementtypen - Relief, bearbeitbar usw. - ausgefüllt.
Wir geben also die Rendering-Parameter einmal ein (wir speichern sie in xml), sie können bearbeitet werden, um verschiedene Designs zu erstellen, und wir verwenden sie global, ohne sie für jeden Controller zu definieren.
Wenn für einen Controller eigene Rendering-Parameter definiert werden müssen, erstellen Sie einfach ein eigenes GAttribut-Objekt in dem Steuerelement und geben Sie die gewünschten Farben an.
----
Dieses Modell funktioniert, das einheitliche Design ist im Handumdrehen erreicht, alle Bedienelemente nehmen die Farben aus dem gemeinsamen Feld.
Aber meiner Meinung nach ist das nicht universell. Der Benutzer versteht nicht, welche Parameter aus der GAttribBase-Basis für das Rendering dieses oder jenes Steuerelements verwendet werden.
Damit der Programmierer genau weiß, welche Farbe er ändern muss, müsste er sich die Rendering-Funktion des Steuerelements ansehen, was wirklich lästig ist.
-----
Wie auch immer, gibt es Ideen für den Programmierer, sich vom Farbmanagement zu befreien (vordefinierte Farben sofort zu verwenden und sich anfangs nicht mit ihnen zu beschäftigen).
Wenn er andererseits einige der Steuerelemente auf dem Bildschirm neu einfärben möchte, muss er nicht nachforschen, welche GAttribBase verwendet wird und in welchem Fall.
@Igor Volodin, @Combinator, @Anatoli Kazharski
Generell - welche Ideen haben Sie, damit der Coder einerseits von der Farbarbeit befreit wird (so dass er die angelegten Farben gleich verwendet und sich nicht am Anfang mit ihnen herumschlägt)
Und wenn sie andererseits einige der Steuerelemente auf dem Bildschirm neu einfärben wollen, können sie dies tun, ohne sich in das Labyrinth der Zeichenfunktionen zu begeben und zu suchen, welche GAttribBase in welchem Fall verwendet wird.
Ok, Themen.
Zum Beispiel ist das Hauptobjekt unserer Anwendung, nennen wir es App, mit dem ConcreteTheme-Objekt verbunden.
Was ist ein Themenobjekt:
Farben (Hintergrund, Vordergrund, deaktivieren, aktiv usw.), Grundgrößen, Schriftgrößen für Standardfälle: titlesize, commonsize usw. Sprites für: Felder, Schaltflächen, Kontrollkästchen usw.
Ein neues Thema ist eine neue Klasse/Struktur mit geänderten Werten. Aber es ist besser, dass Themen vererbt werden können, indem nur bestimmte Parameter überschrieben werden.
Der Rest - die Hierarchie der Steuerelemente, in der jeder Controller einen der erforderlichen Werte des Objektthemas standardmäßig verwendet. Wenn es diese überschreiben muss, rufen wir eine Methode auf, die mit dieser Eigenschaft arbeitet und den neuen Wert angibt.
Zum Beispiel SetBgColor(XRGB(255,0,128));
CView - eine Basisklasse, die grundlegende ereignisbasierte Interaktion ermöglicht
- CRect - Koordinaten
- Cpanel hat eine bgcolor
- CButton hat ein Statusobjekt, jeder Status hat bg
- CText hat eine Textfarbe und Schrifteigenschaften
- CCircle
Und so weiter.
Wenn Sie xml zur Beschreibung der Elemente verwenden möchten,
dann müssen wir für jedes Steuerelement oder Primitiv eine generierende Klasse erstellen, nennen wir sie "build-container", die Attribute (bgcolor="(255,0,128)") den entsprechenden Methoden (SetBgColor(attrValue)) der Klasse zuordnet. Solche Build-Container werden von einem XML-Parser geparst, die Ausgabe ist ein Objekt, das mit den benötigten Werten initialisiert wird, oder mit Standardwerten, wenn keine Werte angegeben wurden.
Hier ist das Thema dasselbe wie bei mir - eine Reihe von GAttributoren für verschiedene Arten von Steuerelementen und deren Status.
aber Sie schlagen bereits den ersten Schritt auf dem Weg zur Transparenz für Programmierer vor - fügen Sie Funktionen zu bestimmten Steuerelementen hinzu, um deren Rendering-Eigenschaften zu ändern (SetBgColor usw.)
Grundsätzlich stimme ich zu, dass es klar sein wird, welche Farben es hat und was geändert werden kann.
eine solche Frage - impliziert das Thema eine Redundanz der nicht verwendeten Parameter?
Nehmen wir an, dass in meinem grundlegenden GAttribBase für einige Steuerelement (z. B. Schaltfläche) verwenden wir nur Hintergrundfarbe und Größe, und andere Parameter - Randdicke, etc. sind nicht in diesem Steuerelement verwendet.
Das heißt - haben Sie ein Basiselement für alle Kontrollen? wo ist die Information "für alle Fälle" gespeichert, oder haben alle Kontrollen nur ihre Parameter ohne den Universalitäts-Overhead?
...
Im Allgemeinen - was sind einige Ideen für den Programmierer zu sein frei von der Handhabung von Farben (so dass es Standard-Farben verwenden würde und nicht mit ihnen am Anfang stören)
Und auf der anderen Seite - damit er, wenn er einen Controller auf dem Bildschirm neu einfärben will, nicht in die Wildnis der Rendering-Funktionen eintauchen und herausfinden muss, welche GAttribBase in welchem Fall verwendet wird.
Legen Sie für jedes Element Standardwerte fest. Wenn der Benutzer etwas ändern muss, sollte es für jede Elementeigenschaft eine Methode zum Festlegen eines neuen Wertes geben. So habe ich es jetzt gemacht.
Das habe ich noch nicht:
Aber all dies ist meine Argumentation für mein Schema. Ich schließe nicht aus, dass es sich noch sehr verändern wird, wenn ich mit dem Übergang beginne. Alles, was ich oben geschrieben habe, ist also möglicherweise nicht mehr relevant für das Thema, das hier diskutiert wird. )