30

50 heures de calcul ? j'ai juste dit (./19) que c'était trop couteux pour être une solution acceptable dans mon cas, puisque je compte accéder très souvent aux propriétés, et que donc rééxécuter sans cesse le même calcul était inadapté.

pour le [] c'est pas con, mais je risque d'avoir besoin de cet opérateur pour des cas bien plus adaptées à cette syntaxe (accéder aux éléments d'une ListBox, par exemple), donc je préfère le laisser libre.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

31

Zephyr (./30) :
50 heures de calcul ? j'ai juste dit (./19) que c'était trop couteux pour être une solution acceptable dans mon cas, puisque je compte accéder très souvent aux propriétés, et que donc rééxécuter sans cesse le même calcul était inadapté.

Mauvaise nouvelle: tu peux pas trouver mieux que O(1).
Zephyr (./30) :
pour le [] c'est pas con, mais je risque d'avoir besoin de cet opérateur pour des cas bien plus adaptées à cette syntaxe (accéder aux éléments d'une ListBox, par exemple), donc je préfère le laisser libre.

Ok.
Tout ce qui passe pas par le port 80, c'est de la triche.

32

Alors toi quand t'as décidé de pas comprendre un truc... bref, fin du HS.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

33

t0: "C'est trop pas performant."
après: "Au mieux c'est linéaire."
après: "C'est pas linéaire mais de tte façon, la syntaxe deviendra trop complexe"
après: "Ouais mais [] je vais utiliser ailleurs".
Fin du HS mais fin de la mauvaise foi aussi j'espère :-/
Tout ce qui passe pas par le port 80, c'est de la triche.

34

Pour finir sur les propriétés, je suis tombé sur une proposition assez sympa d'un type qui n'utilise pas de conteneur, juste des templates et un pointeur intelligent (de LA STL)
http://bytes.com/groups/cpp/559912-designing-property-system
A voir wink

35

onur > la problématique du départ n'a jamais été un problème de performance, relis le topic. J'ai dit dès le début que je voulais une syntaxe légère, et tu me proposes un truc à la fois plus lent qu'un accès direct (O(1) ou autre je m'en tape, ça reste plus lent qu'un accesseur simple) et plus lourd au niveau de la syntaxe, je suis censé répondre quoi à part que ça ne m'intéresse pas ?

noisette > l'astuce est sympa, mais au final il faut quand même mettre un attribut public dans la classe :/
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

36

C'est exactement ce que j'ai proposé dans le ./17, hein...

On peut éviter l'attribut public en faisant prendre un pointeur au constructeur de la classe Property, qui peut être passé par le constructeur de la classe qui contient la propriété. Ça fait qu'on a juste un attribut privé dans cette classe et un pointeur privé dans Property.

Et pour faire plus intéressant, on peut aussi passer des pointeurs vers des méthodes de la classe conteneur à la propriété. Comme ça s'il y a du code d'accès à rajouter, ce n'est plus à Property qu'il faut le rajouter (beurk!), mais la propriété appellera automatiquement la fonction voulue de la classe conteneur.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

37

Ah désolé, j'avais mal compris ton post. Par contre je n'ai pas toujours pas compris comment on évitait l'attribut public ? (pour avoir un accès au final qui se fasse via une syntaxe aussi simple et lisible que "myObject.Property = value;")
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

38

Ah, c'est l'attribut public Property<X> x qui te dérange? Et ben, ce n'est pas un vrai attribut public, les opérations d'assignation et de récupération sont surchargées, l'objet de type X est parfaitement encapsulé.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

39

C'est pas faux, je vais partir sur cette solution. Merci smile
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

40

Gros retour au sujet avec une nouvelle question : jusqu'à maintenant, je n'avais pas envisagé faire de transmission d'évènements autrement que de père en fils. Par exemple, quand on appuie sur une touche du clavier, la fenêtre active transmet à l'onglet du TabControl actif, qui transmet à la TextBox active, qui traite l'évènement.

D'emblée, ça pose un petit problème qui n'est pas bien compliqué à résoudre mais que je ne trouve quand même pas très naturel : on connait le contrôle actif mais pas le parent du contrôle actif, et encore moins le parent du parent du contrôle actif, etc. Il faut donc en permanence conserver non pas le contrôle actif, mais toute la chaine qui permet d'y arriver en partant du contrôle racine ("Desktop", dans mon cas).

Autre soucis : quand on clique sur un bouton dans une fenêtre inactive, ça doit activer la fenêtre (pour la faire passer au premier plan, entre autres). Mais même s'il est possible de gérer ça avec une transmission de père en fils (la fenêtre va intercepter l'évènement "au passage", s'activer, et transmettre à ses fils), une transmission inverse m'aurait semblé plus logique (la fenêtre s'active parceque l'un de ses fils a reçu un évènement, et non l'inverse).

Bref, est-ce vraiment la bonne technique ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

41

Hmmm, je dirais qu'il faut distinguer le focus de fenetre et celui de composant.
D'autre part, je pense qu'une solution pour le focus de composant est que la fenetre garde une liste de tous les éléments qui ont le focus (en gros la chaine entre la fenetre et le bouton pour un cas classique) et leur envoie un onblur lorsqu'un des composants dans la fenetre lui envoie une notification de focus.
Pour obtenir la liste, je dirais que tu as deux solution : soit chaque composant connait son père et l'orsqu'un décide lors d'un clic de prendre le focus il transmet l'info de proche en proche jusqu'à la fenetre lui meme, soit ton dispatch du click renvoie une fonction (enfin un objet avec un callback je suppose en C++), ce qui est un moyen assez générique de remonter dans l'arbre sans stocker directement son parent.

Edit : relu vite fait, je pense que c'est clair comme du mazout tripo
avatar
fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay

42

Je suis pas sûr d'avoir compris ce que tu voulais dire en effet grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

43

Hmm si tes contrôles ne connaissent pas leur parent ça peut effectivement être problématique ^^
Sinon pour ce qui est de la propagation en sens inverse je te rappelle que les fonctions ont une valeur de retour (et que tu peux utiliser des paramètres de sortie, etc...) donc il n'y a pas forcément besoin de te casser la tête.
Après pour l'activation des forms je serais plutôt d'avis d'intercepter l'évènement avant de le transmettre au contrôle fils (En fait ça revient à faire une séparation entre deux types de propagation de message) car de toutes façons cela doit fonctionner pareil, qu'il y ait ou non un contrôle fils, et que le contrôle fils choisisse de répondre ou non.
Enfin ce que je veux dire c'est que l'activation du parent ne dois, dans ce cas au moins, pas dépendre de l'activation du fils ^^
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

44

je me suis démerdé comme ça pour le moment, reste à voir si ça tiendra la route au fur et à mesure que les fonctions vont se multiplier ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

45

Au fait, sans indiscrétion, tu fais ça pourquoi?
Tout ce qui passe pas par le port 80, c'est de la triche.

46

juste pour voir comment ça marche ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

47

Zephyr (./40) :
Gros retour au sujet avec une nouvelle question : jusqu'à maintenant, je n'avais pas envisagé faire de transmission d'évènements autrement que de père en fils. Par exemple, quand on appuie sur une touche du clavier, la fenêtre active transmet à l'onglet du TabControl actif, qui transmet à la TextBox active, qui traite l'évènement.
D'emblée, ça pose un petit problème qui n'est pas bien compliqué à résoudre mais que je ne trouve quand même pas très naturel : on connait le contrôle actif mais pas le parent du contrôle actif, et encore moins le parent du parent du contrôle actif, etc. Il faut donc en permanence conserver non pas le contrôle actif, mais toute la chaine qui permet d'y arriver en partant du contrôle racine ("Desktop", dans mon cas).
En fait, je dirais que le problème est même plus en amont : pourquoi passer par toute une chaîne de composants (le chemin racine -> fils actif) alors que tu connais déjà le composant actif ? Autant directement soumettre l’évènement au composant actif.

Par contre, si celui-ci ne traite pas l’évènement il peut être intéressant de faire remonter ce dernier vers ses parents, qui seraient plus susceptibles de le traiter.
Autre soucis : quand on clique sur un bouton dans une fenêtre inactive, ça doit activer la fenêtre (pour la faire passer au premier plan, entre autres). Mais même s'il est possible de gérer ça avec une transmission de père en fils (la fenêtre va intercepter l'évènement "au passage", s'activer, et transmettre à ses fils), une transmission inverse m'aurait semblé plus logique (la fenêtre s'active parceque l'un de ses fils a reçu un évènement, et non l'inverse).
Ah bah voilà ^^
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

48

oui, ça me semble bien plus simple en théorie, mais je demande si ça ne va pas bloquer à un moment où à un autre ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

49

Pourquoi ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

50

Je sais pas, j'avais l'impression que les "vraies" GUI fonctionnaient avec une propagation de père en fils donc je suis spontanément parti dans cette direction (et puis c'est ce que semblent suggérer certaines propositions sur ce topic aussi), mais j'avoue que pour l'instant je vois pas d'exemple qui ne puisse pas être géré avec un système inverse.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

51

Pour la souris tu es obligé de traverser toute la chaine (faut bien tester toutes les hitbox, et du coup ça force le sens parent -> fils wink ), et pour le clavier, tu pourrais le faire directement, mais à ce moment là tu n'auras aucun moyen de filtrer les évènements clavier si tu en éprouves le besoin. (Et pour des trucs simples comme le changement de contrôle avec tab ça pourra passer mais pour des trucs plus complexe ce n'est pas garanti)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

52

[nosmile]Ben, la manière de laquelle c'est résolu dans Qt, c'est que tout objet a un parent (c'est géré par QObject, la classe de base de tous les objets touchant aux évènements) consultable par la méthode QObject:tonguearent(). Le parent peut être NULL, mais pour les contrôles (QWidget), c'est forcément le contrôle conteneur, avoir NULL comme parent voulant dire qu'il s'agit d'une fenêtre (qui n'a évidemment pas de conteneur). Il y a également différentes méthodes pour avoir accès aux fils (on peut avoir la liste de tous les objets fils ou faire des recherches selon des critères précis).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

53

GoldenCrystal (./51) :
Pour la souris tu es obligé de traverser toute la chaine (faut bien tester toutes les hitbox, et du coup ça force le sens parent -> fils wink ),
non Pour la souris, c’est juste le moment où tu cherches le composant qui est sous la souris que tu es obligé de parcourir les composants du père vers le fils, mais une fois que tu as trouvé ce composant, c’est uniquement à lui que tu transmets l’évènement souris, et ce composant traite l’évènement ou bien le transmet à son parent, ainsi de suite.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »