Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 6
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
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.
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.
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.
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.
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 kann Ihnen nicht sagen, wie schnell es gehen wird.
Nad Tausende von Objekten machen keinen Unterschied in der Geschwindigkeit.
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?