Discussion :

[droliprane]

Bonjour à tous,

dans le cadre du développement d'un visuel dans une GPAO, j'étudie la possibilité d'utiliser la notion d'organigramme de windev pour représenter une hiérarchie de références d'articles, enfin j'aimerais surtout profiter de l'algorithme de positionnement prêt à l'emploi, mais je ne suis pas certain qu'il soit adaptable avec le cas de figure que je vais décrire.

Le scénario serait le suivant :

1) l'utilisateur recherche une référence d'article X via une zone de recherche, puis lance le traitement sur cet article.
2) grâce à une table des liens (dans ma bd), une routine va réaliser récursivement une exploration descendante sur les articles liés (les fils), en partant de cet article X.
On obtient une première arborescence décrivant la filiation de X (les noeuds verts).
3) Ensuite, depuis chacun des noeuds enfants visités, je vais en plus exécuter une exploration montante pour connaitre les produits "connectés" qui n'ont absolument rien à voir avec le produit X mais qui pourraient utiliser un de ses fils dans leur arbre de fabrication. Sachant que l'outil servirait pour monitorer les stocks et encours des articles participants à la fabrication de X, il ne faut pas qu'on occulte les besoins de ces produits connexes.
Ce qui fait que mon premier arbre obtenu en 2) va être augmenté d'un certain nombre de noeuds (les noeuds oranges), et donc potentiellement présenter plusieurs "noeuds origine" (les noeuds tout en haut qui n'ont pas de père). Donc au final, ce n'est plus réellement un arbre que j'obtiens, mais un graphe orienté (plusieurs noeuds racine):



Ma question est donc : le champs organigramme windev peut-il servir pour construire un visuel comme le schéma ci-dessus, ou bien chaque élément racine que je vais déclarer aura sa propre hiérarchie, et je n'aura pas un ensemble final qui sera interconnecté ? Je veux dire par là que j'ai l'impression qu'il faut initier un organigramme avec un élément racine, puis descendre sur les fils. Mais dans mon exemple, j'ai 7 racines, qui doivent se rejoindre tôt ou tard sur un des noeuds de l'organigramme...

Voilà, j'espère avoir été clair, si quelqu'un a déjà travaillé sur un sujet approchant, ou peut me donner des axes de solutions, je lui en serait bien reconnaissant ^^

Cordialement,

droliprane

[droliprane]

Je viens de découvrir que peut-être je pourrais gérer ça avec le champs "fil" qui permet de décrire des workflow.

Le problème se trouve dans le positionnement visuel d'éléments dont la quantité et les interconnexions ne sont pas connues à l'avance, ce que je trouvais bien pratique avec le champs organigramme...

Une idée ?

[droliprane]

Bonjour,
allé je reviens partager mes recherches, des fois qu'on pense que j'attends la solution toute cuite ^^

Je progresse gentiment mais je pense que ça va être compliqué d'arriver à ce que je souhaite...
J'ai donc dans une classe Arbre un tableau de noeuds, avec pour chaque noeud un tableau de ses suivants, et des méthodes d'exploration descendante et montante.
J'avais fait cette classe il y a très longtemps quand j'avais mis au point mon algo de calcul de besoin net, qui fonctionne très bien.

Bref, passons aux choses sérieuses, la mise en visuel !
J'utilise finalement un champs modèle (une fenêtre interne qui aura des champs que je renseignerai plus tard) que je clone à mesure que je déclare les noeuds de mon graphe, et pour relier mes noeuds j'utilise le champs fil.
Le problème c'est maintenant le positionnement, et le drag'n drop.
Pour l'instant, quand je lance ma routine de création de mes "noeuds", ça me sort un truc tout pas beau, normal vu que je positionne de façon séquentielle, au stade où j'en suis j'y vais step by step.
Surtout je me suis aperçu que si je laissais les fils en mode routage par angles droits, alors c'était impossible de réorganiser le diagramme. J'ai donc naturellement limité le routage à un seul segment.



Après réorganisation via un drag'n'drop pas très au point (si je drag trop vite ça décroche, et s'il y a trop de fils dans la zone, le noeud est "imbougeable" il faut faire de la place en commençant par écarter les noeuds périphériques, enfin c'est pas du tout pratique ^^), j'obtiens ça :



Pas si mal en si peu de temps, mais le plus dur reste à faire. Comment obtenir directement une vue relativement dégagée et lisible.... Je fais donc appel à votre expérience, aux spécialistes des algo de positionnement.
En dernier recours, j'envisagerai de laisser ce boulot à l'utilisateur et de proposer de sauvegarder la config de positionnement des noeuds...

bonne journée à tous !

[frenchsting]

Je n'y connais rien en positionnement. Je pense qu'il faut faire un compte par niveau du max d'éléments, et par nombre de niveaux :
- tu vas avoir la largeur par le max d'éléments.
- tu vas avoir la hauteur par le nombre de niveaux.

Après, je ne connais pas les fonctions du champ organigramme.

J'ai également trouvé ceci concernant l'affichage d'arbres : Image_GraphViz

[droliprane]

Ok je vois
Il va falloir identifier les noeuds par niveau, et leur attribuer aussi un "poids" dans le niveau, poids qui serait fonction du père, de sorte qu les fils d'un noeud N se retrouvent bien en dessous (visuellement), et pas à l'autre bout de la fenêtre sous un autre noeud du même niveau, je sais pas si je suis clair
Par exemple commencer par attribuer aux noeuds du 1er niveau les poids 1, 2, 3, ... n
Et pour chaque fils i du noeud N le poids vaudrait = (poids du père x 10) + i
Ce qui permettrait d'ordonner les noeuds à afficher.
Je vais creuser tout ça.

Autre question : je dispose mes noeuds (j'utilise maintenant des boutons plutôt que des fenêtre internes car pas d'événement bouton enfoncé/relâché sur une fenêtre interne pour gérer le déplacement des noeuds...) directement dans une fenêtre.
Mais si j'en ai beaucoup et que j'ai besoin de hauteur, quelle solution me permettrait de les positionner sans me soucier de la hauteur, et d'avoir un ascenseur pour faire scroller le graphe ?

Merci pour votre aide

[frenchsting]

Oui, tu es clair... ou je suis aussi aveugle que toi.

Je n'avais pas pensé à la "possibilité" de croisement des traits. Pour la pondération des noeuds, c'est simple, il "suffit" de trouver combien il a de fils. Nb fils = pondération.

J'essaye de me rappeler la gestion des listes chaînées, mais je ne trouve pas de façon simple de la représenter. Pour l'instant, je modéliserais comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
str_niveau est une Structure
	idnoeud est un entier
	sNomNoeud est une chaîne
	idPère est un entier
	nNiveau est un entier
	tabFils est un tableau d'entiers
FIN
 
MonOrganigramme est un tableau de str_niveau

A creuser, je crois que j'ai un truc qui m"échappe...

[droliprane]

Je crois que je n'ai pas bien compris pourquoi la pondération serait le nombre de fils. Pour moi ça doit être nécessairement fonction du noeud père...

Quoi qu'il en soit, même sans algo de positionnement, mon outil n'est pas stable pour l'instant. Le déplacement des noeuds fait planter aléatoirement windev, sans erreur particulière, juste ça se ferme et revient à l'éditeur. Faut dire que j'ai géré ça par des thread, pas sûr que ce soit ce qu'il y ait de mieux.

Demain je vais isoler mon module dans un projet à part, avec une fonction pour peupler la structure d'arbre en mémoire (sans s'appuyer sur des données en BD), histoire de pouvoir partager plus simplement les choses avec vous.

Avant toute chose, il faut absolument que le déplacement des noeuds ne plante plus sinon le module sera inutilisable.
Ensuite, coder une fonction de pondération des noeuds de l'arbre (en partant des noeuds racines), puis une deuxième fonction qui va sérialiser les noeuds selon cette pondération, et une dernière fonction qui va retourner un tableau de tableau d'entiers représentant les X niveaux de Y noeuds.
Enfin, une fonction de positionnement des noeuds en fonction du dernier tableau obtenu et des dimensions de la fenêtre.

On pourra sûrement faire plus performant et plus élégant, mais l'objectif premier est d'avoir une V1 fonctionnelle, ensuite on optimisera.

Désolé si cette tirade n'apporte rien de bien nouveau, mais ça m'aide pas mal de poser les choses par écrit et d'avoir votre version des choses.

Merci à vous

[frenchsting]

La pondération vient du nombre de fils pour un noeud (un père). Le souci, c'est que pour un noeud, tu dois systématiquement chercher ses fils.

L'utilisation des threads me semble être effectivement une source de problèmes.

Tu as raison de poser tes idées.

Pour rendre ça sexy, je pense qu'il faut passer par de la récursivité. A voir si ça peut être intéressant...

EDIT : Ce qui me chatouillait hier : Je sais ce qui me pose souci dans mon modèle : C'est que je ne sais pas à quel niveau je suis. En fait, j'avais bien mis le niveau.

Une question : est-il possible que les fils d'un noeud soient non pas au niveau n+1, mais au niveau n+2 ?
Une autre : d'après on premier modèle, on peut avoir un fils avec plusieurs pères. C'est le "vrai" modèle ?

[droliprane]

Bon ce sera trop compliqué d'isoler dans un projet, sans avoir la BD avec, tant pi.

Je me suis appuyé sur l'exemple WD Objets Graphiques pour gérer une fenêtre interne avec instanciation à la volée d'objets dans un espace de travail. C'est plus propre que mes ChampsClone et le déplacement de champs est plus fluide, et je n'ai plus de plantages.
Par contre lors d'un déplacement ce n'est pas tout le dessin qui est recalculé en temps réel comme j'aurais aimé (avec les fils qui bougent en même temps), mais uniquement l'objet que je déplace qui prend la forme d'un halo estompé et seulement quand je le lâche le diagramme tout entier se redessine. Donc il y a un petit lag d'une demi-seconde entre le moment où l'on "empoigne" un noeud et le moment où il se "dédouble" avec le halo qui apparaît, signe que l'action de déplacement est en cours. Bon on s'y fera, c'est sûrement aussi pour ça que c'est stable et moins consommateur que si tout était redessiné en même temps que le déplacement.

Concernant la structure de graphe orienté, les fils d'un noeud de niveau N peuvent apparaître dans une autre section du graphe à une profondeur plus grande, et donc pour la lisibilité du graphe, devront être dessinés au niveau le plus profond.
Mais comme c'est utile pour le CBN, j'ai déjà une routine qui numérote les noeuds par exploration descendante, et leur affecte la profondeur la plus importante.

Et oui un fils peut avoir plusieurs pères = un semi-fini peut être partagé par plusieurs produits finis = un ingrédient peut rentrer dans la composition de différentes recettes ^^



Je vais attaquer les bases de l'algo de positionnement, la suite bientôt.

droliprane

[frenchsting]

Excellent retour.

Une idée, dessiner d'abord les noeuds avec des fils en commun. puis les noeuds avec fils, et finalement les noeuds "terminaux" ?

[droliprane]

Pas bête, c'est une autre approche que je n'avais pas envisagée.

Là en fait je pondère les noeuds par exploration descendante, mais sur un même niveau il faudrait déjà pouvoir ordonner les noeuds d'une façon plus intelligente en prédisant l'allure qu'auront les branches inférieures, donc pas évident.
Je ne sais pas encore trop quoi, mais j'ai l'impression qu'il y a quelque chose à faire en faisant une deuxième passe en remontant depuis les feuilles.
En fait l'idéal serait de trouver un peu de littérature sur le sujet, il doit bien exister des modèles d'algo sur lesquels s'appuyer.

Bref je termine la journée avec un premier jet de positionnement plus que perfectible.

C'est satisfaisant sur un graphe simple, un peu moins sur des structures plus complexes :



Excellente soirée.

droliprane

[frenchsting]

C'est pas mal. Même pour l'exemple 2, qui est le plus complexe.

J'ai idée qu'il ne faut pas partir de la racine mais des derniers fils. Regarder ceux qui ont plusieurs pères au niveau supérieur. Les placer au centre et de chaque côté mettre les fils "uniques", puis remonter. Dans un deuxième temps, il faudra reprendre cette analyse pour regarder les pères qui sont avant le niveau supérieur.
Pas simple, ton histoire...

[droliprane]

Bonjour

je mets le positionnement en suspens, le temps d'étoffer un peu les infos affichées dans chaque noeud, et de voir si l'outil "prend" vis-à-vis des utilisateurs ou si je ne vais pas plus loin.

Du coup, me voilà avec la question suivante : existe-t-il un moyen de formater le libellé d'un bouton, de manière à avoir des petits compteurs dans 3 coins qui correspondraient respectivement aux qtés en commande, qté en encours, et qté en stock.

J'aimerais plutôt garder mon bouton et gérer un libellé sur 3 lignes avec des tags pour justifier à gauche ou à droite, les mettre éventuellement en couleur, ... mais je suis pas sûr que ce soit faisable.

Sinon un champs table éventuellement, mais comme je l'instancie par programmation, je me dit que ça va être galère (et je ne sais même pas si c'est possible) de créer par programmation une table de 3 lignes par 2 colonnes, avec la 2ème ligne fusionnée sur toute la largeur...
Sachant que je ne peux pas passer directement par un ChampCrée car je décrit l'objet dans un ObjetChamp, que je passe à mon "Manager d'Espace" (repris de l'exemple Objets Graphiques) qui cette fois va instancier le champs et l'empiler dans sa collection de champs...

Et pour un champs table, il me semble que la table est un champs, la colonne est un champs, etc... donc pas facilement "descriptible" avec un seul ObjetChamp

Ou alors de l'HTML ou RTF comme libellé du bouton ?


Et vous, comment feriez-vous ?

Merci

[droliprane]

Je me réponds à moi-même, à priori le plus élégant serait de passer par un superChamp voire même plutôt un ModeleDeChamp.

J'ai réussi à créer un ModeleDeChamp dans mon arborescence projet, mais pour l'employer et l'instancier par programmation, je sèche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
oChamp est un Champ
stInfoObjet est un ObjetChamp
 
// Décrit l'objet à créer dans un ObjetChamp
stInfoObjet.Nom = "NOEUD_" + id
stInfoObjet.Type = typModèleDeChamp // là il me manque l'instruction pour préciser de quel modèle de champs il s'agit, et ensuite pouvoir accéder aux champs du modèle par indirection je suppose
stInfoObjet.Propriétés["X"] = FI_WORKFLOW_ESPACE..X + posX
stInfoObjet.Propriétés["Y"] = FI_WORKFLOW_ESPACE..Y + posY
 
// Demande au document de créer l'objet
oChamp <- MGRObjetCrée(stInfoObjet)
 
// Autorise l'édition
oChamp..FenEditionAutorisée = Vrai
 
// Ajoute l'objet au document
MGRObjetAjoute(oChamp)

J'indique que l'objet est de type typModèleDeChamp, mais je n'indique pas de quel modèle de champ il s'agit.
De manière à pouvoir ensuite faire appel à ses propriétés, ou invoquer une méthode du modèle...

[frenchsting]

Pour les textes sur le bouton, j'aurais utilisé un superchamp avec un bouton et 3 libellés "bien positionnés".
Après, tu peux cloner tes superchamps.

[droliprane]

Alors je suis passé par un modèle de champs que j'ai importé dans ma fenêtre (ce que je ne voulais pas) du coup ça revient à faire un superchamp à priori.

J'aurais vraiment préféré pour instancier par programmation sans avoir un champ modèle invisible qui traîne dans ma fenêtre.

Quoi qu'il en soit, le problème qui en résulte doit être le même, quand un noeud est sélectionné, aucun événement souris ne peut être intercepté par le "superchamp" qui représente le noeud.

Le double-clic ne fonctionne pas, pas plus que le clic simple, certainement parce que la fenêtre est en mode édition pour permettre le drag'ndrop des objets graphiques... Là je câle...

[frenchsting]

Avec un événement WM_MouseUp, si tu as les coordonnées de tes noeuds, tu devrais pouvoir t'en sortir. Après, je sais que ça va être lourd...

[droliprane]

Avec un événement WM_MouseUp, si tu as les coordonnées de tes noeuds, tu devrais pouvoir t'en sortir. Après, je sais que ça va être lourd...

Bonjour et merci de suivre mon sujet

Alors non je n'ai pas les coordonnées du noeud.

Mais est-ce qu'à l'endroit où on clic, avec un champsSurvol par exemple, on pourrait choper le nom du champs ?

EDIT :
je viens de tester, ça ne fonctionne pas.
En fait, à partir du moment où je suis en mode FenEdActive(maFenetre, Vrai) alors c'est mort pour intercepter un événement. Et c'est justement ce mode d'édition des objets qui me permet d'avoir un drag'n drop bien fluide !
Donc si je veux pouvoir double-cliquer sur un noeud et avoir une fenêtre de détails, je dois utiliser un autre système de déplacement des noeuds...
Ou alors intercepter le double-clic avec une api plus "bas niveau" que les événements windev, mais là il me faudra les coordonnées d'un noeud (ça y est, je viens de comprendre ton idée frenchsting, mais malheureusement je ne vois pas comment garder les coordonnées des noeuds !)
Un vrai sac de noeuds ^^

[droliprane]

Bon alors finalement j'ai du repenser tout le système de drag'n drop, et ne plus m'appuyer sur l'exemple "Objets Graphiques" car il intercale un "manager" d'objets, et des espaces occupés dans la fenêtre interne.

C'était pratique pour le coup de profiter de la fonction de déplacement d'objet qui s'active automatiquement dès lors qu'on place une fenêtre en mode édition, mais ce mode précisément rend très compliquée la capture d'événements. J'ai essayé d'ajouter un gestionnaire d'événements via l'api windows, mais ça ne cohabite pas bien et ça crash...

Finalement, je gère directement le déplacement des objets au travers de l'api windows (je me suis inspiré du super travail de bastiencb ici => https://www.developpez.net/forums/d9...indows-souris/ qui reste valable 10 ans plus tard) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// déclarations globales
 
strPOINT est une Structure
	x est un entier
	y est un entier
FIN
 
CONSTANTE
	WH_MOUSE_LL = 14
	WM_LBUTTONDOWN = 513
	WM_LBUTTONUP = 514
	WM_RBUTTONDOWN = 516
	WM_RBUTTONUP = 517
	WM_MOUSEMOVE = 512
	WM_MOUSEWHEEL = 522
FIN
 
iHook est un entier système = 0
 
noeud_sélectionné est une chaîne
 
posX est un entier = 0
posY est un entier = 0
enfoncé est un booléen = Faux
memo_ts_enfoncé est une DateHeure = Maintenant()
ts_enfoncé est une DateHeure = memo_ts_enfoncé
relaché est un booléen = Faux

La procédure qui réceptionne les événements, gère le déplacement, et détecte un double-clic (si moins de 25ms entre 2 enfoncé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
PROCEDURE MouseEvent(nIIdHook est un entier,wParam est un entier,nILParam est un entier)
 
dh est une DateHeure = Maintenant()
diff est une Durée
 
stPoint est une strPOINT
stPoint.x = PoidsFaible(CurseurPos(cpFenêtre))
stPoint.y = PoidsFort(CurseurPos(cpFenêtre))
 
SELON wParam
 
	//Bouton gauche enfoncé
	CAS WM_LBUTTONDOWN	//513
 
	//trace("enfoncé")
 
		enfoncé = Vrai
		memo_ts_enfoncé = ts_enfoncé
		ts_enfoncé = dh
 
		// recherche du champs sur lequel on a cliqué
		noeud_sélectionné = getNoeudSélectionné(stPoint.x, stPoint.y)
 
		SI noeud_sélectionné <> "" ALORS
			posX = stPoint.x
			posY = stPoint.y
 
			// test si double-clic
			diff = DateHeureDifférence(memo_ts_enfoncé, ts_enfoncé)
 
			SI diff..EnMillisecondes < 25  ALORS
				chargeDETAILS({noeud_sélectionné,indChamp}..Note)  // j'ai caché l'id de mon noeud dans la propriété ..Note
			FIN
 
 
		FIN
 
 
	//Bouton gauche relaché
	CAS WM_LBUTTONUP	//514
 
		//Trace("relâché")
		enfoncé = Faux
 
	//Déplacement souris
	CAS WM_MOUSEMOVE	//512
 
		SI enfoncé ALORS
 
			SI noeud_sélectionné <> "" ALORS
 
				{noeud_sélectionné,indChamp}..X = stPoint.x - ({noeud_sélectionné,indChamp}..Largeur / 2)
				{noeud_sélectionné,indChamp}..Y = stPoint.y - ({noeud_sélectionné,indChamp}..Hauteur / 2) - 23   // -23 car j'ai un ascenceur horizontal en bas qui se met systématiquement sur ma fenêtre interne
 
			FIN
 
		FIN
 
		//Trace("Déplacement souris")
 
FIN

La détection du noeud sur lequel on clique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
PROCEDURE getNoeudSélectionné(LOCAL x est un entier, LOCAL y est un entier)
 
ResChamp est une chaîne
i est un entier = 1
ResChamp = EnumèreChamp(CFI_WORKFLOW, i)
WHILE ResChamp<>""
 
	SI Contient(ResChamp, "NOEUD_") ALORS
 
		SI {ResChamp,indChamp}..X <= x <= ({ResChamp,indChamp}..X + {ResChamp,indChamp}..Largeur) ET
			({ResChamp,indChamp}..Y + 23) <= y <= ({ResChamp,indChamp}..Y + {ResChamp,indChamp}..Hauteur + 23) ALORS
 
			RENVOYER ResChamp
 
		FIN
 
		//Trace(ResChamp + " aid = " + {ResChamp,indChamp}..Note + ", poxX = " + {ResChamp,indChamp}..X + ", posY = " + {ResChamp,indChamp}..Y)
	FIN
 
	i++
	ResChamp = EnumèreChamp(CFI_WORKFLOW, i)
END
 
RENVOYER ""

Ne pas oublier de tuer le "hook" sur fermeture de la fenêtre, sinon ça fait planter windev !

C'est légèrement moins fluide au niveau du déplacement que si la fenêtre est en mode édition, mais ça me permet d'avoir un outil plus complet...

[frenchsting]

C'est ce je pensais quand je t'en ai parlé. C'est clair que derrière y'a du taf pour sortir ça !

Note :Tu peux mettre un Externe Keyconst.wl pour avoir toutes les constantes système Windows.

Pour chipouiller : plutôt que d'utiliser une structure pour la position de la souris, si tu utilises SourisPosX() et SourisPosY(), ça te renvoie des entiers. Mais comme dirait qqn sur le forum : "Y a peut-être plus simple, mais ça fonctionne !"