flatStructure

Un composant (écrit comme un :pig:) pour lister les objets de structure : tables, champs, relations, index.
http://forums.4d.com/4DBB_Main/x_User/4467/files/24944462.zip

mise à jour (v16)…
http://forums.4d.com/4DBB_Main/x_User/4467/files/26339121.zip
note : ce comp étant écrit en vue d’aider aux (nécessaires ?) renommages pour utiliser ORDA, tout retour ou suggestion d’amélioration est bienvenu.

mise à jour (v16r-je-sais-plus-laquelle)
http://forums.4d.com/4DBB_Main/x_User/4467/files/27794092.zip
Bien que la finalité soit un composant, j’ai ajouté quelques tables, champs et autres liens pour qu’on puisse tester hors base hôte.
Avec les onglets tables, champs et relations, le double clic affiche l’objet visé en structure (je triche un peu pour les relations).

-Bonsoir Arnaud,

le 4DD et non 4DB est dans le zip :wink:

-Bonsoir Arnaud,

le 4DD et non 4DB est dans le zip :wink:

https://forums.4d.com/4DBB_Main/x_User/4467/files/29666318.zip

Vraiment sympa. Y’en a dedans :smiley:

Le composant d’Arnaud me semble indispensable pour examiner les liens. Je me suis permis d’en faire un fork avec les modifications apportées ici :

  • champs affichés sous la forme [table]champ au lieu de table.champ
  • aération du code, renommage divers, ajout de l’extension .json au fichier structure exporté
  • présentation plus esthétique selon mon goût, cases à cocher plus visibles, affichage des numéros combinés tableChamp
  • suppression du code, ressources et méthodes excédentaires
  • tri des listes par tables et champs lors du changement d’onglet
  • modification de l’ordre d’affichage des colonnes pour les liens
  • une autre manière de proposer le nom des liens qui nécessitait l’accès aux champs de départ et d’arrivée ( tableAller et les_tableRetour_TABLEALLER)
  • lancement de plusieurs fenêtres l’une en dessous de l’autre
  • affichage en français
  • correction de quelques bugs sans conséquence comme ligne 433 de la méthode principale _mng , il faut mettre $titre_at{$i_l au lieu de $nomH_t

A rapatrier ici :

https://forums.4d.com/4DBB_Main/x_User/3922/files/31183660.zip

[]31183664;“photo écran”[/]

Intéressant !
Et merci aussi pour le review, Mimosa.

Oui, sympa, j’aime bien quand ça questionne. Par contre je me suis demandé pourquoi avoir enlevé la fonction “afficher en structure sur double clic” () ? Quand je fais du renommage de relations d’une base, c’est un vrai gain de temps pour retrouver le @#$ lien dans le @#$* plat de nouilles qu’est une structure de la vraie vie.
Pour le dire autrement, flatStructure c’est :
1 - regarder la structure autrement (de bêtes listes à plat…)
2 - comme on ne peut guère modifier quoi que ce soit autrement qu’à travers l’éditeur de structure, y accéder lorsque nécessaire par double clic

(*) Ça me chagrine d’autant plus que ça fait des lustres qu’on attend de 4D une commande qui fasse ce que fait le raccourci “cmde+K”, la bricole infâme à laquelle je me suis livré est également là pour montrer à quelles extrémités ils nous réduisent et réveiller leur pitié :wink:

j’ai enlevé le commande+K parce que … j’ai jamais pu le faire fonctionner ! C’était aussi présent dans un autre de tes composants. Je n’ai sans doute rien compris à la manip…

je vois plutôt le renommage des liens comme un “one-shot” : on imprime la liste et on s’y colle durant une heure et basta. D’ailleurs même dans une grosse base, les liens ne sont pas si nombreux que çà en réalité

et comme il fallait de mémoire 4 méthodes rien que pour cela, ben, j’ai guillotiné comme un républicain en 1793, ne faisant pas de quartier entre les femmes et les enfants.

Je pensais plutôt être critiqué pour enlever la programmation défensive mais je n’ai JAMAIS vu dans ma vie une méthode envoyer soudain moins ou plus de paramétres à une sous-méthode. Il faut se protéger de l’utilisateur, pas du logiciel. La programmation défensive se justifie pour un plug-in, jamais pour son propre code quand on est soigneux.

Bon, Thibaut disait que j’étais “un ayatollah du code”, il avait sans doute pas tort. Déjà que les fautes d’orthographe dans les commentaires m’horripilent. Et le code doit s’auto commenter : si ($estInvisible) est plus parlant que si ($flagInvisible_b) // si invisible.

En tout cas, un grand merci pour ce composant. J’ai pas touché au moteur interne orda car c’est vraiment technique et il faut être motivé pour décortiquer un json…

: Herve LE MARCHAND

et comme il fallait de mémoire 4 méthodes rien que pour cela, ben,
j’ai guillotiné comme un républicain en 1793, ne faisant pas de
quartier entre les femmes et les enfants.

Pour 4 méthodes, elles t’irritaient tant que cela ah ah ?

: Herve LE MARCHAND

Je pensais plutôt être critiqué pour enlever la programmation
défensive mais je n’ai JAMAIS vu dans ma vie une méthode envoyer
soudain moins ou plus de paramètres à une sous-méthode. Il faut se
protéger de l’utilisateur, pas du logiciel. La programmation
défensive se justifie pour un plug-in, jamais pour son propre code
quand on est soigneux.

Ca entièrement d’accord.

: Herve LE MARCHAND

Et le code doit s’auto commenter : si ($estInvisible) est plus
parlant que si ($flagInvisible_b) // si invisible.
Là aussi. Bien nommer les variables, ça s’apprend. Quand je revois mes nommages ne serait-ce que d’il y a quelques années ! Jusqu’à ce que je définisse une stratégie, et l’utilise. Déjà, tout en anglais. Et j’aime finalement le mélange “_” et camelCase. Genre “$is_btnInvisible”.

Pour répondre aux deux derniers points.
Dans ogTools, j’ai mis un truc super (c’est un module gratuit à l’usage, mais que je devrais un jour extraire pour en faire un composant gratos et open source) : wog_methods_manager, qui peut se mettre en appel macro aussi.
En fait, le commentaire d’une méthode, souvent, n’est indispensable que pour connaître les paramètres, et s’ils sont facultatifs. Donc, avec une méthode bien nommée, avec tous les $1, $2… affectés à une variable locale, ben mon algo va extraire finalement une doc de l’appel qui pour moi est suffisante ! Donc plus de doc, juste à lancer le traitement. Il y a des options pour afficher uniquement l’appel, les affectations, etc. Je me suis fait chier sur l’algo bien comme il faut :slight_smile:
On peut donc commenter une ou plusieurs méthodes (sélection multiple) d’un clic !!!

Exemple, que qui suit c’est mis dans la partie “Commentaires” de la méthode, et je n’y ai rien retouché :

x_picture_icon($1↝$ptr_picture;$2↝$width;$3↝$heigth;$4↝$coef;$5↝$rx;$6↝$ry;$7↝$stroke;$8↝$shape;$9↝$colors;{$10↝$txt_label};{$11↝$txt_font};{$12↝$txt_coef};{$13↝$txt_color};{$14↝$txt_style};{$15↝$img_picture};{$16↝$img_coef};{$17↝$img_offset_x};{$18↝$img_offset_y};{$19↝$img_brightness};{$20↝$is_grey_scale})

$ptr_picture:=$1
$width:=$2
$heigth:=$3
$coef:=$4
$rx:=$5
$ry:=$6
$stroke:=$7
$shape:=$8
$colors:=$9
$txt_label:={$10}
$txt_font:={$11}
$txt_coef:={$12}
$txt_color:={$13}
$txt_style:={$14}
$img_picture:={$15}
$img_coef:={$16}
$img_offset_x:={$17}
$img_offset_y:={$18}
$img_brightness:={$19}
$is_grey_scale:={$20}

L’interface (la couleur indique les méthodes partagées de celles qui ne le sont pas).

[]31216932;“Your comment here…”[/]

: Herve LE MARCHAND

Bon, Thibaut disait que j’étais “un ayatollah du code”, il avait sans
doute pas tort. Déjà que les fautes d’orthographe dans les
commentaires m’horripilent. Et le code doit s’auto commenter : si
($estInvisible) est plus parlant que si ($flagInvisible_b) // si
invisible.

Personnellement je préfère Code :
Si ($VisiblementInvisible)

D’ailleurs, rien de tel qu’un coup de forum pour améliorer…
Ma ligne d’appel en commentaire était trop longue, et 4D ne la coupe pas de lui même, elle est difficile à lire.

J’ai ajouté un paramètre de “Nombre de paramètres par ligne”. Ici à 5.
La bulle d’aide devient top !

[]31217188;“Comments généré…”[/]

[]31217209;“Bulle d’aide sur la méthode…”[/]

Si je devais faire une méthode maintenant je partirais plutôt sur un seul objet en paramètre avec des propriétés. Et documenter ton objet. :idea:

Mais non !!!
Il faut vraiment faire un atelier sur les objets, qui ont plein de défauts, en plus de toutes leurs qualités !

Les défauts ?

  1. pas compilé. Ce qui est dedans s’accède avec du parsing de properties. C’est donc lent, et gourmand en mémoire - oui pas en absolu, mais comparé avec du vrai objet compilé à la java ou C.
  2. Tu modifies le nom d’une property et c’est très galère pour faire du back update ! Il faut rechercher dans tous les usages.
  3. c’est lent ! Bien sûr, ça fonce sur nos machines, mais intellectuellement parlant…

Bref, c’est génial pour avoir des variables “pate à modeler”, mais pour du vrai dur, je reste en vrai dur.

Dans le cas présent, mon exemple, c’est une méthode justement pour calculer une icône. Imagine au dessus une listbox de boutons 4D, dont chaque ligne est donc composé d’un png de bouton, donc quatre images calculées par cette méthode. Avec 30 lignes, ça met déjà 1/2 seconde, alors avec un objet en paramètre, non !

Mais bien sûr que mon système marche aussi avec un paramètre objet, dans la mesure où j’intègre aussi toutes les lignes de commentaires en début de code (une “vraie” ligne trouvée arrête le truc).

Mais c’est encore un sujet à faire couler de l’encre, ces fichus objets !
Et c’est tant mieux.

Bon, ton exemple est peut-être mal choisi (si c’est un problème d’optimisation) mais il y a également beaucoup d’avantage aux objets.
Tu n’es pas obligé de passer tous les paramètres si tu as besoin que d’un seul par exemple.
Tu peux initialiser simplement dans ta méthode les paramètres non passés.
C’est plus lisible (ton code) car tu peux employer des noms directement sans passer par les variables intermédiaires.
Etc.

Tu as du courage de l’utiliser ainsi, je l’utilise également pour des icônes dans une listbox avec des images en SVG ! mais je me précalcule l’image à afficher dans une variable sinon effectivement c’est beaucoup trop long… :roll:

: Manuel PIQUET

Tu peux initialiser simplement dans ta méthode les paramètres non
passés.

Oui mais imagines !
Tu dois tester si une property existe, puis la lire si elle existe…
Déjà dans ton code, tu viens de mettre deux fois le label .myProperty…

Ca prend de la place en mémoire comme pour une c_text et deux fois.
Si tes variables sont bien nommées, c’est lisible comme avec les properties.

: Manuel PIQUET

Tu as du courage de l’utiliser ainsi
En fait je n’ai pas le choix, car le but de cet outil (ProTools) est justement de gérer des banques d’icônes, elles mêmes rattachées à des projets avec des chemins vers les dossiers de ressources de mes bases. Et de justement calculer les boutons 4D et icônes dont j’ai besoin dans les projets. Je ne peux donc pas précalculer, car le but de l’outil est justement de calculer au moment de l’export :slight_smile: Mais bien sûr, quand tu le peux…

: Herve LE MARCHAND

j’ai enlevé le commande+K parce que … j’ai jamais pu le faire
fonctionner !
C’est un simple hack du raccourci cmde+k dans l’éditeur de code qui ouvre des tas de choses intéressante pour lesquelles 4D ne nous fourni hélas pas de commande idoine (en particulier : ouvrir un formulaire, ouvrir la structure). Donc je contourne :
a) je créé une méthode XXX dont le contenu sera une chaine interprétable par cmde+k
b) quand j’ai besoin d’ouvrir quelque chose, je mets la chaine correspondante dans la méthode XXX, j’ouvre cette méthode XXX (1er plan), je sélectionne la chaine et j’envoie le raccourci cmde+k.
La seule “subtilité” est la gestion du “quelle fenêtre est au 1er plan”, impliquant délais et timeout. Ceux que j’ai mis fonctionnent chez moi (j’ai dû les allonger pour le C/S distant où ça va nettement moins vite). Mais comme tout hack de ce genre, ça a vite fait de merder si l’environnement n’est pas le même, probablement ce qui se passe chez toi.

: Herve LE MARCHAND

Je pensais plutôt être critiqué pour enlever la programmation
défensive mais je n’ai JAMAIS vu dans ma vie une méthode envoyer
soudain moins ou plus de paramétres à une sous-méthode.
Ça se discute, indéfiniment :wink:
Si je suis seul à utiliser mon code et si je me rappelle par cœur des paramètres à envoyer 1 ans après, c’est complètement con. Mais ni l’un ni l’autre ne sont vrais et que j’aime bien qu’une commande 4D me précise mon erreur quand elle me fait les gros yeux (“j’attendais un paramètre de type gna gna gna”), je tente de faire pareil.
Avec des objets en paramètres entrants, ce sera peut-être utile, d’ailleurs :
c_objet($1)
ASSERT($1.laProprieteEntranteIndispensable#Null;"$1 doit posséder la propriété laProprieteEntranteIndispensable")

: Olivier GRIMBERT

Tu dois tester si une property existe, puis la lire si elle existe…
Déjà dans ton code, tu viens de mettre deux fois le label
.myProperty…
Dans le cas d’un paramètre, ça revient à faire des tests avec Nombre de paramètres : c’est réellement plus rapide ?

C’est pas un tantinet défensif, d’ailleurs ? :mrgreen: