Réaliser un projet de crowdsourcing sur Canvas - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Il y a une question fondamentale.
Disons qu'il y a deux applications, des panneaux, des indicateurs, sur un même graphique. Chacun d'eux doit-il dessiner sur sa propre toile ou les deux sur une toile commune ?
Il y a des questions dans les deux cas.
Maintenant, je suggère que nous dessinions simplement une toile. Avec tous les éléments qui s'y trouvent.
Quoi qu'il en soit, nous ne serons pas en mesure de contrôler le nombre de ces instances en cours d'exécution avec canvas (ou nous nous plongerons dans les fonctions de l'OS pour "l'interface multi-fenêtre" sur canvas. On y viendra peut-être un jour, mais pas encore).
En conséquence - je propose de ne pas faire d'interactions entre les kanvas au niveau de l'envoi d'"événements de fenêtre" entre eux pour le moment.
De plus, je ne peux pas imaginer pour l'instant comment plusieurs ex5 pourraient échanger des données sur le contenu d'un seul canevas partagé.
Avec le clavier, tout est plus ou moins clair. Il y a un événement lorsqu'une touche est pressée, il y a un code pour cette touche. Que voulez-vous de plus ?
Malheureusement, le code n'est pas complet. Aujourd'hui, les événements graphiques ne font pas la distinction entre A et a.
J'ai déjà écrit sur ce sujet dans le SD
Au fait, je pense que l'introduction de l'événement OnMouseDown faciliterait grandement la vie d'un DND normal.
L'événement CHART_MOUSE_MOVE de sparam envoie l'état des boutons et du clavier. = gauche, droite, ctrl, shift, alt.
En d'autres termes, le DND est mis en œuvre maintenant.
En d'autres termes, nous pouvons mettre en œuvre le DND maintenant.
Oui, je suis conscient de cela, car je l'ai mis en œuvre dans mon récent projet. Donc maintenant le DND ne peut être mis en place que par le trou du cul.
Tout d'abord, pour le glisser-déposer normal, il est nécessaire d'activer ou de désactiver certaines propriétés du graphique, sinon le graphique est glissé avec le canevas, bien sûr, dans presque tous les cas, nous devons les désactiver.
Deuxièmement, MouseMove n'est pas lié à un objet, comme Click, par exemple, donc s'il y a deux objets sous la souris, les deux seront traînés. Dans la bibliothèque standard, c'est comme ça, d'ailleurs.
Et il en sera ainsi s'il n'y a pas de logique interne pour choisir l'objet à tirer.
Ainsi, le deuxième problème de l'événement MoseDown semble être efficacement résolu.
Il y a aussi un troisième point. MouseMove est un événement de spam. Il devrait être forcé d'être activé et lorsqu'il est activé, il sera envoyé à tous les codes du tableau et peut être la cause de bons freins en raison du nombre de messages, donc s'il y a un moyen de ne pas l'utiliser, il est préférable de ne pas l'utiliser.
Oh, il y a aussi un troisième point. MouseMove est un événement de spam. Il doit être activé de force et, lorsqu'il est activé, il sera envoyé à tous les codes du graphique et peut causer de bons décalages en raison du nombre de messages, donc s'il y a un moyen de ne pas l'utiliser, il est préférable de ne pas l'utiliser.
Oui, je suis conscient de cela, car je l'ai mis en œuvre dans mon récent projet. Donc maintenant le DND ne peut être mis en place que par le trou du cul.
La première, pour un glisser-déposer normal, nous devons désactiver et activer certaines propriétés du graphique, sinon le graphique est glissé avec le canevas, bien sûr, dans presque tous les cas, vous devez les désactiver.
Deuxièmement, MouseMove n'est pas lié à un objet, comme Click, par exemple, donc s'il y a deux objets sous la souris, les deux seront tirés. Dans la bibliothèque standard, c'est comme ça, d'ailleurs.
Et il en sera ainsi s'il n'y a pas de logique interne pour choisir l'objet à tirer.
Ainsi, le deuxième problème de l'événement MoseDown semble être efficacement résolu.
Il y a aussi un troisième point. MouseMove est un événement de spam. Il devrait être forcé d'être activé et lorsqu'il est activé, il sera envoyé à tous les codes du tableau et peut être la cause de bons freins en raison du nombre de messages, donc s'il y a un moyen de ne pas l'utiliser, il est préférable de ne pas l'utiliser.
Tu réalises que si on va sur Kanvas, on est tout seul. Il n'y a plus d'événements de haut niveau. Pas d'objets mt qui peuvent les recevoir
Si seulement les mouvements de la souris et les états des boutons. je ne l'appellerais pas un trou du cul )). c'est juste un événement de bas niveau.
S'il y a un décalage, il est invisible à l'œil nu. Dans mon panneau, à un moment donné, MouseMove envoyait des milliers d'éléments, y compris invisibles, puis j'ai fait des envois plus intelligents, mais visuellement cela n'a pas ajouté de vitesse.
Je ne peux pas vous dire à quelle vitesse ça va être.
Nad milliers d'objets ne font pas de différence en termes de vitesse.
vous réalisez que si nous faisons du porte-à-porte, nous sommes seuls. Il n'y a plus d'événements de haut niveau. Pas d'objets mt pour les recevoir.
Si seulement les mouvements de la souris et les états des boutons. je ne l'appellerais pas un cul )). c'est juste un événement de bas niveau.
Il y a aussi le niveau d'interaction avec les autres codes. Du moins, entre plusieurs instances d'un même indicateur, par exemple. Vous devriez en tenir compte.
Mais oui, tout cela est clair.
Il existe également un niveau d'interaction avec d'autres codes. Par exemple, entre plusieurs instances d'un même indicateur. Vous devez en tenir compte.
Honnêtement, je n'ai aucune idée du genre d'interaction dont vous parlez.
Plusieurs instances d'un indicateur peuvent-elles être produites sur un seul canevas ?