Documentation 4D sur le Glisser-Déposer

C’est moi où https://doc.4d.com/4Dv17R6/4D/17-R6/Drop-position.301-4310966.fe.htmlles exemples sur le glisser-déposer> sont particulièrement mal écrit et incompréhensibles :?: :-?

Pourquoi lire une information directement et ensuite vérifier que le presse-papier contient bien cette même information ? :doubt:

Dans l’exemple sur l’événement On drag over, a quoi sert de lire le presse-papier ?

: Manuel PIQUET

Pourquoi lire une information directement et ensuite vérifier que le
presse-papier contient bien cette même information ? :doubt:
Oui, on pourrait tester le conteneur d’abord et ne lire les données que si c’est positif.

: Manuel PIQUET

Dans l’exemple sur l’événement On drag over, a quoi sert de lire le
presse-papier ?
Les noms des commandes sont mieux choisis en français pour le coup.
En français, on parle de conteneur, pas de presse-papiers (pasteboard).

Le conteneur sert dans deux contextes distincts, le presse-papiers et le glisser-déposer. Modifier le conteneur dans le contexte du glisser-déposer ne modifie pas le presse-papiers.

Lire le conteneur sur glisser (On drag over) sert à déterminer si le conteneur contient des données acceptables pour la zone où on glisse. Si ce n’est pas le cas, on fait $0:=-1 et le pointeur affiche un sens interdit pour en informer l’utilisateur.

J’ai bien compris justement, mais dans l’exemple on lit le conteneur mais la lecture n’est pas utilisée, donc dans l’exemple cette ligne
<code 4D>
GET PASTEBOARD DATA(“mydrag”;$toGet) //lire les données

</code 4D>
ne sert à rien !

C’est suffisamment obscure à défricher sans qu’on nous donne des exemples qui sont mal construits et qui ne servent à rien… :frowning:

Cela donne l’impression que la personne n’a rien compris aux commandes qu’elle utilise :roll:

Il serait nettement préférable de nous donner un exemple concret qui permet de remplacer l’ancien système _o_DRAG AND DROP PROPERTIES
Car nul part il est expliqué comment combler le manque les infos que remontait cette commande (le n° du process appelant, et la référence à l’objet source)

La doc se permet en plus de référencer une commande devenue obsolète !
Code :
Sur glisser
L’événement On Drag Over est envoyé de manière répétée à l’objet de destination lorsque le pointeur de la souris est placé sur l’objet. Généralement, en réponse à cet événement, vous effectuez les actions suivantes :
Vous appelez la commande _o_DRAG AND DROP PROPERTIES qui vous renseigne sur l’objet source.
En fonction de la nature et du type de l’objet de destination (celui duquel la méthode est en cours d’exécution) et de l’objet source, vous acceptez ou refusez le glisser.

Oui, mais comment on connait l’objet source ?

Un cas concret: j’ai besoin de glisser-déposer une ligne de listbox sur la même listbox comment je restreins et/ou je teste la provenance du glisser ?

Pour le n° de process ok, on peut le passer dans le blob, mais l’objet source ? on passe quoi ?

En fait c’est pire que ça :

la doc pour la commande n’est pas juste en https://doc.4d.com/4Dv17R5/4D/17-R5/Presentation-du-Glisser-Deposer.300-4127813.fe.htmlfe (franglais)>
on a ça:
Code :
Sur glisser
L’événement On Drag Over est envoyé de manière répétée à l’objet de destination lorsque le pointeur de la souris est placé sur l’objet. Généralement, en réponse à cet événement, vous effectuez les actions suivantes :
Vous appelez la commande _o_DRAG AND DROP PROPERTIES qui vous renseigne sur l’objet source.
En fonction de la nature et du type de l’objet de destination (celui duquel la méthode est en cours d’exécution) et de l’objet source, vous acceptez ou refusez le glisser.

alors qu’en https://doc.4d.com/4Dv17R5/4D/17-R5/Presentation-du-Glisser-Deposer.300-4127813.fr.htmlfrançais (fr)>
on a ça:
Code :
Sur glisser
L’événement Sur glisser est envoyé de manière répétée à l’objet de destination lorsque le pointeur de la souris est placé sur l’objet. Généralement, en réponse à cet événement, vous effectuez les actions suivantes :
Vous lisez les données et les signatures renseignées dans le conteneur (via la commande LIRE DONNEES CONTENEUR).
En fonction de la nature et du type de données renseignées dans le conteneur, vous acceptez ou refusez le glisser-déposer.

:roll:

Mais bon, cela ne nous explique toujours pas comment combler les manques…

Je n’ai jamais plus eu besoin de l’objet source ou du process appelant depuis l’avènement du conteneur pour le glisser/déposer. Le glisser peut même venir d’une autre application alors ça n’aurait pas de sens.

Avant c’était utile car on ne pouvait pas associer de données à l’action donc il fallait bien savoir où aller les chercher. Mais maintenant, on associe toutes les données qu’on veut et ça permet de tout faire.

Il ne faut plus raisonner de la même façon. Tu types les données que tu es en train de glisser et tu les traites dans la zone d’arrivée. Que ce soit la même zone au départ et à l’arrivée ne change rien.

Je pense que tu n’as pas compris mon besoin. :cry:

J’ai besoin de restreindre le déposer uniquement aux elements
provenant d’un certains objet et d’un certain process.

Je ne peux pas me baser sur la nature de l’element en l’occurence je
suis obligé de passer un blob contenant toutes les infos dont j’ai
besoin.

Je vais avoir besoin du n° du process appelant, de l’information ici
un (ID ou une position) et enfin de pouvoir determiner l’objet
appelant.

et pour determiner l’objet appelant je sèche un peu, je pense passer
le nom de l’objet :doubt:

Ce n’est pas un simple glisser-deposer d’une info c’est un cas de
gestion d’interface (ici un réordonnement d’une listbox (non tableau
!).

: Stanislas CARON

Que ce soit la même zone au départ et à l’arrivée ne change rien.
Dans mon cas si, cela n’est pas possible de glisser un truc qui ne provient pas de la listbox elle meme (et pire du même process uniquement !)

Et pour finir, je dois avoir un code générique qui fait cela (pour info, cela fonctionnait bien avec l’ancienne méthode pour la nouvelle cela va demander un peu plus d’effort… :roll:)

Non non, c’est toi qui n’a pas bien compris :slight_smile:

Si le type de données passé au conteneur n’est pas suffisant, tu peux lire ces données pour savoir si leur nature est bien celle attendue.
Pour te simplifier la tâche, il suffit de passer des données structurées, xml ou json par exemple. Là, tu as toute latitude pour qualifier les données glissées. C’est ce que je fais et je n’ai jamais eu à m’en plaindre.

C’est une autre façon de faire mais c’est beaucoup plus puissant.

Dans mon cas, ce n’est pas la donnée qui importe (ni sa nature) mais d’où elle vient.

Je m’en suis sorti relativement simplement en donnant un nom construit à la volé aux données (dans mon cas la position de depart) que je place dans le conteneur.

<code 4D>
$NomGlisser:=“mydrag”+$NomLB+"-PID"+chaine(Numéro du process courant)

</code 4D>

Je pense que c’est suffisant pour restreindre à ce que j’ai besoin de gérer. :mrgreen:

Mais bon, je persiste à dire que la doc (outre d’être corrigé) manque vraiment d’exemples plus construits. Surtout pour le cas plus complexe qu’un simple glisser d’un texte.

Même si ça peut fonctionner comme ça, tu te trompes dans ta façon de procéder.
Tu cherches à reproduire l’ancienne méthode avec la nouvelle.

Ce sont bien des données que tu glisses in fine.

Je ne sais pas exactement quel est le besoin mais en passant une donnée de type xml, tu pouvais facilement déterminer dans la structure xml toutes les infos utiles. C’est plus propre que de passer un type qui est lui-même la donnée.

Je me suis mal exprimé (ou pas assez expliqué) en faite le code n’est pas la donnée que je passe mais la clé (unique :pray:) de la donnée dans le conteneur.

Il manque cette partie de code pour bien comprendre ce que je fais:

<code 4D>
AJOUTER DONNÉES AU CONTENEUR($NomGlisser;$tomove) //utilise une clé personnalisée

</code 4D>
Dans le blob $tomove je n’ai que la position de la ligne de depart

Je pourrais effectivement passer ces infos en même temps que ma donnée principale mais bon, ces données de géolocalisation de la provenance de ma donnée ne sont ici utiles QUE pour determiner si oui ou non on accepte le drop.

Encore une fois, ce n’est pas un vrai glisser-deposer que je fais, mais une gestion d’interface. Je tri un listbox (non tableau) en permettant à l’utilisateur de le faire en faisant du glisser-deposer de ligne dans cette même listbox.

Je ne sais pas si cela peut t’aider, mais pour ma part j’ai pris le parti d’utiliser des types de données personnalisés.

Dans le glisser/copier :

<code 4D>
FIXER TEXTE DANS CONTENEUR($acopier) // si on veut aussi autoriser le coller dans tableur/éditeur de texte
TEXTE VERS BLOB($acopier;$madonnee;UTF8 texte sans longueur)
AJOUTER DONNÉES AU CONTENEUR(“com.4d.private.montype.monsoustype”;$madonnee)

</code 4D>

Et à l’arrivée :
<code 4D>
si(Tester conteneur(“com.4d.private.montype.monsoustype”)>0)
// exploiter les données
fin de si

</code 4D>

Comme ça, j’ai pu identifier d’autres écrans affichant des données compatibles avec mes listbox de réception et permettre de faire des copier/coller et glisser/déposer entre eux sans me soucier de pointeurs ou noms d’objets.

Merci mais c’est exactement ce que je fais sauf qu’en plus je me sers du nom du type de donnée pour déterminer et limiter le déposer à ce que je veux uniquement.

Comme j’expliquais ce que je fais dans mon cas ce n’est pas un vrai glisser-déposer car je ne dépose(copie) pas d’information précise. C’est juste un mécanisme d’interface qui utilise le glisser-déposer pour réordonner les lignes d’une listbox.

Le glisser que je fais n’a aucun intérêt d’être déposé en dehors de la listbox et uniquement celle de son propre process ! Inversement on ne doit pas pouvoir déposer quelque chose d’autre sur cette même listbox.

Dans ce cas-là, j’utilise un type unique à cette listbox-là genre “…monmodule.monecran”, de sorte que le traitement du glisser/déposer pourra tester et n’accepter que ces données-là. Sachant que les données contiendront le numéro de ligne sélectionnée ?

La petite subtilité dans mon cas c’est que c’est également un code générique donc il faut adapter le type unique au contexte pour pouvoir gérer les bonnes exclusions…