Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 6

 
Комбинатор:

Es stellt sich eine grundlegende Frage.

Nehmen wir an, es gibt zwei Anwendungen, Panels, Indikatoren, in einem Diagramm. Soll jeder von ihnen auf eine eigene Leinwand malen oder beide auf eine gemeinsame?

In beiden Fällen gibt es Fragen.

Jetzt schlage ich vor, dass wir einfach eine Leinwand zeichnen. Mit allen Elementen darauf.
Wie auch immer, wir werden nicht in der Lage sein, die Anzahl solcher laufenden Instanzen mit Canvas zu kontrollieren (oder wir werden tief in die OS-Funktionen für "Multi-Window-Interface" auf Canvas einsteigen. Irgendwann wird es so weit sein, aber noch nicht).

Als Konsequenz - Ich schlage vor, nicht zu tun Interaktionen zwischen Kanvas auf der Ebene der Sendung "Fenster-Ereignisse" zwischen ihnen jetzt.

Außerdem kann ich mir im Moment nicht vorstellen, wie mehrere ex5 Daten über den Inhalt eines einzigen gemeinsamen Kanvas austauschen könnten.

 
Vasiliy Sokolov:
Mit der Tastatur ist alles mehr oder weniger klar. Es gibt ein Ereignis, wenn eine Taste gedrückt wird, es gibt einen Code für diese Taste. Was wollen Sie mehr?

Leider ist der Code nicht vollständig. Heutzutage unterscheiden die Diagrammereignisse nicht zwischen A und a

Zu diesem Thema habe ich bereits in der SD geschrieben

 
Комбинатор:
Übrigens denke ich, dass die Einführung des OnMouseDown-Ereignisses das Leben in Bezug auf ein normales DND sehr erleichtern würde.

CHART_MOUSE_MOVE-Ereignis in sparam sendet den Status von Schaltflächen und Tastatur. = links, rechts, Strg, Shift, Alt.

Mit anderen Worten: DND ist jetzt implementiert.

 
Es gibt noch eine weitere Frage. Wer weiß, bitte erklären. Warum ein Eingabefeld mit einer neuen Technologie erstellen, wenn dieses Steuerelement bereits durch ein einziges Objekt dargestellt wird? Welche Vorteile in Bezug auf die Einsparung von Ressourcen oder neue Funktionen kann sie bieten? Kurz gesagt - warum?
 
o_O:

Mit anderen Worten: Wir können DND jetzt implementieren.

Ja, das ist mir bewusst, denn ich habe es in meinem letzten Projekt implementiert. Daher kann DND jetzt nur noch über Arschloch implementiert werden.

Zuallererst ist es für das normale Ziehen und Ablegen notwendig, einige Diagrammeigenschaften zu aktivieren oder zu deaktivieren, da das Diagramm sonst zusammen mit der Leinwand gezogen wird; natürlich sollten wir sie in fast allen Fällen deaktivieren.

Zweitens ist MouseMove nicht an ein Objekt gebunden, wie z.B. Click, d.h. wenn sich zwei Objekte unter der Maus befinden, werden beide gezogen. In der Standardbibliothek ist das übrigens auch so.

Und das wird so sein, wenn es keine interne Logik gibt, die auswählt, welches Objekt gezogen werden soll.

Das zweite Problem des MoseDown-Ereignisses scheint also tatsächlich gelöst zu sein.

Es gibt noch einen dritten Punkt. MouseMove ist ein Spam-Ereignis. Sie sollte zwangsweise aktiviert werden, und wenn sie aktiviert ist, wird sie an alle Codes auf dem Diagramm gesendet und kann aufgrund der Anzahl der Nachrichten die Ursache für gute Bremsen sein, wenn es also eine Möglichkeit gibt, sie nicht zu verwenden, ist es besser, sie nicht zu verwenden.

 
Комбинатор:

Oh, es gibt auch noch einen dritten Punkt. MouseMove ist ein Spam-Ereignis. Sie muss zwangsweise aktiviert werden und wird, wenn sie aktiviert ist, an alle Codes im Diagramm gesendet, was aufgrund der Anzahl der Nachrichten zu erheblichen Verzögerungen führen kann; wenn es also eine Möglichkeit gibt, sie nicht zu verwenden, ist es besser, sie nicht zu verwenden.

Die Verzögerungen sind, wenn überhaupt, mit dem bloßen Auge nicht wahrnehmbar. In meinem Panel auf einmal MouseMove wurde Senden von Tausenden von Elementen, einschließlich unsichtbar, dann machte mehr clevere Senden, aber visuell hat es nicht hinzufügen Geschwindigkeit.
 
Комбинатор:

Ja, das ist mir bewusst, denn ich habe es in meinem letzten Projekt implementiert. Daher kann DND jetzt nur noch über Arschloch implementiert werden.

Erstens müssen wir für das normale Ziehen und Ablegen einige Diagrammeigenschaften deaktivieren und aktivieren, da das Diagramm sonst zusammen mit dem Canvas gezogen wird, was natürlich in fast allen Fällen deaktiviert werden muss.

Zweitens ist MouseMove nicht an ein Objekt gebunden, wie z.B. Click, d.h. wenn sich zwei Objekte unter der Maus befinden, werden beide gezogen. In der Standardbibliothek ist das übrigens auch so.

Und das wird so sein, wenn es keine interne Logik gibt, die auswählt, welches Objekt gezogen werden soll.

Das zweite Problem des MoseDown-Ereignisses scheint also tatsächlich gelöst zu sein.

Es gibt noch einen dritten Punkt. MouseMove ist ein Spam-Ereignis. Sie sollte zwangsweise aktiviert werden, und wenn sie aktiviert ist, wird sie an alle Codes auf dem Diagramm gesendet und kann aufgrund der Anzahl der Nachrichten die Ursache für gute Bremsen sein, wenn es also eine Möglichkeit gibt, sie nicht zu verwenden, ist es besser, sie nicht zu verwenden.

Ihnen ist klar, dass wir auf uns allein gestellt sind, wenn wir in den Kanvas gehen. Es gibt keine hochrangigen Veranstaltungen mehr. Keine mt-Objekte, die sie empfangen können

Wenn nur Mausbewegungen und Tastenzustände. ich würde es nicht ein Arschloch nennen )). es ist nur eine niedrige Ebene Ereignis.

 
Vasiliy Sokolov:
Wenn es eine Verzögerung gibt, ist sie mit dem bloßen Auge nicht zu erkennen. In meinem Panel sendete MouseMove auf einmal Tausende von Elementen, darunter auch unsichtbare, dann habe ich das Senden intelligenter gemacht, aber visuell hat es die Geschwindigkeit nicht erhöht.
Ich bestätige.
Ich kann Ihnen nicht sagen, wie schnell es gehen wird.
 
o_O:
Nad Tausende von Objekten machen keinen Unterschied in der Geschwindigkeit.
Die Frage ist nicht die Anzahl der Objekte, sondern die Anzahl der Codes. Und selbst wenn ein Indikatorcode immer irgendetwas hartes per ChartEvent macht.
o_O:

Sie wissen schon, dass wir auf uns allein gestellt sind, wenn wir in den Wahlkampf ziehen. Es gibt keine hochrangigen Veranstaltungen mehr. Es gibt keine mt-Objekte, die sie empfangen können.

Wenn nur Mausbewegungen und Tastenzustände. ich würde es nicht einen Esel nennen )). es ist nur ein Low-Level-Ereignis.

Hinzu kommt die Interaktion mit anderem Code. Zumindest zwischen mehreren Instanzen eines Indikators, zum Beispiel. Das sollten Sie berücksichtigen.

Aber ja, all dies ist klar.

 
Комбинатор:

Es gibt auch eine Ebene der Interaktion mit anderen Codes. Zum Beispiel zwischen mehreren Instanzen eines Indikators. Das müssen Sie berücksichtigen.

Ehrlich gesagt, habe ich keine Ahnung, von welcher Art von Interaktion Sie sprechen.

Werden mehrere Instanzen eines Indikators auf einer Leinwand ausgegeben?