Champ de type hypertexte, doc des attributs

On 5 avr, 14:19, Gloops <glo...@zailes.invalid.org> wrote:

Bonjour tout le monde,

Voici environ une semaine, j'ai appris ici l'existence du type de champ
"hypertexte". J'essaie de le créer par code, sous VBA.

Si je crée manuellement un tel champ dans une table, je vois sous VBA
que son type est dbMemo.
Je soupçonne qu'il ne suffit pas de créer un champ de type mémo pou r
qu'il soit de type hypertexte.

Je vois que ce champ a pour attributs 32770, soit 32768 + 2. Les noms de
ses autres propriétés ne me semblent pas avoir un rapport évident a vec
la question.

Alors, je me dis qu'en mettant le curseur sur Attributes et en appuyant
sur F1, je vais avoir une liste des attributs de champs possibles avec
leurs valeurs numériques, intitulés et quelques mots d'explication. A h
oui, mais ça ... c'était il y a un moment.

Quelqu'un a-t-il ça sous la main, et saurait-il éventuellement me dir e
si je fais fausse route ?

Encore que si je crée un champ avec ces attributs, il est bien
hypertexte. Dommage que je ne réussisse pas à mettre à jour le
certificat pendant que j'ai la machine sous la main, enfin ça c'est une
autre question.
Et puis ça serait quand même bien de savoir ce que je fais, et pourqu oi
au juste il faut sélectionner deux attributs pour faire ça.

Là j'ai travaillé sous Access 2007, mais on peut espérer que les
attributs ne sont pas révolutionnés d'une version à l'autre, tout j uste
le champ hypertexte est-il plus récent que les autres.

Bonjour Gloops.
Je ne vois pas trop le rapport entre tes certificats et les liens
hypertexte. Tu trouveras un peu de lecture ici :
http://office.microsoft.com/fr-fr/access-help/a-propos-des-liens-hypertexte -HP005188817.aspx
et il y en a plein d'autres. (Google est ton ami)
Comme je l'ai dis il y a une semaine, je n'aime pas ces champs car ils
ne sont pas manipulables facilement, notamment pour les mettre à jour
ou en extraire une information. J'avais dans une base commencé avec
des adresses e-mail. Déjà un problème : il faut placer un mailto:
devant. Et puis si cela fonctionne au clic, j'ai eu un mal de chien
pour extraire ces adresses pour en faire un mailing (je préviens mes
clients que la matière est arrivée). Donc, j'ai abandonné
l'hypertexte.
La solution que j'avais donné à Alfred Wallace résoud ces problèmes .
Voilà par exemple le contenu d'une table "Doc_Chemin" «
i:/Classeur2.xls
mailto:pascal.censure@gmail.com
http://pascal.cambier.eu
»
Un formulaire basé sur cette table.
L'événement double-clic sur la zone de texte de ce champ et le code
suivant :

En tête du module : «
Private Declare Function ShellExecute Lib "shell32.dll" Alias
"ShellExecuteA" _
(ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile
As String, _
ByVal lpParameters As String, ByVal lpDirectory As String,
ByVal nShowCmd As Long) As Long
»

Et l'événement "Double Clic" sur le champ "Doc_Chemin" : «
Private Sub Doc_Chemin_DblClick(Cancel As Integer)
ShellExecute Me.hwnd, "open", Me.Doc_Chemin.Text, "",
CurrentProject.Path, 1
End Sub
»

Voili Voilà,
Pascal

pascal58 a écrit, le 06/04/2012 15:28 :

Bonjour Gloops.
Je ne vois pas trop le rapport entre tes certificats et les liens
hypertexte.

Ah non pour les certificats il y a un autre fil. Simplement, après avoi r
modifié la base, si elle avait un certificat il n'est plus valable, le
rapport s'arrête là.

Tu trouveras un peu de lecture ici :
http://office.microsoft.com/fr-fr/access-help/a-propos-des-liens-hypert exte-HP005188817.aspx
et il y en a plein d'autres. (Google est ton ami)

Ah je ne connaissais pas la possibilité de placer une infobulle. On en
parle pour Access, il faudra que j'aille voir si la même chose existe
pour HTML.

Pour Google, j'étais allé voir "Attributes Access". Il y a 210 000 00 0
de réponses, et sur la première page aucune ne concerne Access. Mais tu
as raison, il faut préciser un peu plus. Avec "Field Attributes
Ms-Access", on arrive là :
http://msdn.microsoft.com/en-us/library/bb221127%28v=office.12%29.aspx
et c'est effectivement la réponse à ma question.
Donc les deux attributs du champ étaient dbHyperlinkFIeld, et
dbVariableField (the field size is variable). ça parle déjà plus.

Comme je l'ai dis il y a une semaine, je n'aime pas ces champs car ils
ne sont pas manipulables facilement, notamment pour les mettre à jour
ou en extraire une information. J'avais dans une base commencé avec
des adresses e-mail. Déjà un problème : il faut placer un mailto :
devant. Et puis si cela fonctionne au clic, j'ai eu un mal de chien
pour extraire ces adresses pour en faire un mailing (je préviens mes
clients que la matière est arrivée).

Je me rappelle effectivement que tu as proposé le recours à l'API, qu i
est ce que je fais jusque là. Pour la peine que Microsoft a créé un type
de champ exprès pour (en fait, pas un type de champ dédié mais un
attribut qui permet d'obtenir un lien sur une URL), j'ai voulu voir de
plus près.

Ah oui alors là-dedans on met le protocole, en tête, donc on peut y
mettre mailto. C'est vrai qu'il y a du code à écrire pour l'enlever.
Dans les fonctions toutes prêtes pour enlever un mail il ne faut pas
mettre le protocole. Donc, curieusement, pour les mails, si il y a le
protocole devant il va falloir recourir à l'API, donc ... pas une trop
bonne idée on dirait.

Pour une URL j'ai pu créer le champ, maintenant je comprends ce que j'a i
mis comme attributs, il va falloir que je fasse quelques tests, pour voir .

De toute façon, au départ il faut faire attention avant d'utiliser
l'attribut dbHyperlinkField : il faut développer sur une version
d'Access qui en assure le support.

C'est pour ça que ta réponse avait au moins l'intérêt de passer p artout.

Gloops a écrit, le 07/04/2012 12:44 :

pascal58 a écrit, le 06/04/2012 15:28 :

Comme je l'ai dis il y a une semaine, je n'aime pas ces champs car ils
ne sont pas manipulables facilement, notamment pour les mettre à jou r
ou en extraire une information. J'avais dans une base commencé avec
des adresses e-mail. Déjà un problème : il faut placer un mailto :
devant. Et puis si cela fonctionne au clic, j'ai eu un mal de chien
pour extraire ces adresses pour en faire un mailing (je préviens mes
clients que la matière est arrivée).

Public Function ExtraitAdresseMail(strContenu As String)
Dim Spl() As String
Spl = Split(strContenu, "#")
ExtraitAdresseMail = Mid$(Spl(1), Len("mailto: "))
End Function

passer en argument le contenu du champ hypertexte mailto.

Ah oui alors là-dedans on met le protocole, en tête, donc on peut y
mettre mailto. C'est vrai qu'il y a du code à écrire pour l'enlever .
Dans les fonctions toutes prêtes pour /enlever/ un mail il ne faut pa s
mettre le protocole.

Euh, là, c'était envoyer, que je voulais dire.
"Zen", qu'il disait ...

Donc, curieusement, pour les mails, si il y a le
protocole devant il va falloir recourir à l'API, donc ... pas une tro p
bonne idée on dirait.

Ce n'est pas exactement ça. Le champ hypertexte fonctionne pour une
adresse mail, mais à condition que l'utilisateur s'astreigne à taper
"mailto:" au début du champ, ou qu'une procédure événementielle l e fasse
pour lui. On pourrait aussi utiliser "callto:" pour un numéro de
téléphone, mais avec la même réserve (et toujours sous la réser ve que le
logiciel approprié soit installé).

Je me demande si en mettant en place un champ hypertexte on a conscience
de tout ce qui peut être appelé avec. Cela étant je viens de véri fier,
la visionneuse Access vérifie qu'il y a un protocole d'indiqué au dé but.
Si ce n'est pas le cas on demande confirmation à l'utilisateur, et mê me
si il répond oui on lui dit pas possible.
Donc, une bonne partie des failles de sécurité ont été identifié es. Toutes ?
ça serait d'ailleurs intéressant de tester du même point de vue les
différentes versions d'Access qui proposent le champ hypertexte.
Attention d'ailleurs, lors d'un appel à une API, il n'y a pas
nécessairement les mêmes contrôles. Je sais que je ne vérifie pas
toujours si il y a un protocole au début du texte exécuté, attentio n si
un petit malin met des choses bizarres là-dedans.

Pour le lien URL pour ouvrir une page web, le champ hypertexte fait
moins de code à écrire que l'appel à une API, et je viens de
m'apercevoir que ça n'est pas nécessairement le seul avantage, du moi ns
dans la visionneuse (je me demande comment on connaît son numéro de
version, d'ailleurs ; avec les menus déroulants on regardait "à propo s
de", dans le menu aide).

Pour un numéro de téléphone ou une adresse mail, je suppose que c'e st
plus adéquat d'avoir un champ dédié, donc un champ texte qu'on
appellera, soit avec un contrôle lien hypertexte, pas nécessairement
visible, qu'on initialisera le moment venu avec le protocole suivi du
contenu du champ, soit par appel à une procédure adaptée -la deuxiè me
solution n'était pas forcément plus compliquée. Une comparaison des deux
sur le plan de la sécurité pourrait être intéressante.

L'avantage de laisser plusieurs champs hypertexte sans les gérer
spécialement est que l'utilisateur met ce qu'il veut dedans à conditi on
de le préciser, deux numéros de téléphone, deux mails, un télé phone et
une URL ...
Mais je n'affirmerais pas que c'est la meilleure façon de gérer une b ase
de données.

Gloops a écrit, le 07/04/2012 14:31 :

du moins dans la visionneuse

C'est vrai qu'avec Access on parle plutôt de kit d'exécution, puisqu' il
permet d'écrire des données.

Hello Gloops,

J'ai plus l'impression que tu soliloques qu'autre chose.

Si Access peut utiliser des champs hypertexte, c'est aussi pour éviter
aux utilisateurs lambda d'avoir à programmer en VBA. Non ?
Si tu migres vers SQL SERVER, MYSQL ou tout autre base de données, tu
vas avoir un problème. Et je le connais. J'expliquais ma difficulté
en comparant le langage d'Access à un patois comme le Picard (ch'ti)
qui utilise parfois des mots pas toujours appropriés. « on mingeot
eine platélée d'mutieau, eine tarteine au fromache ou bin ein
pistolet. » (si tu recherches la phrase complète sur Goggle, tu auras
une traduction). Imagine le gars qui ne connaisse que cette langue et
qui doit tout à coup porter son "mutieau" en Français.

Access et hypertexte, grand bien lui fasse, mais ce n'est pas une
bonne idée de Micro$oft.

Bien entendu que je connais la méthode du split, bien entendu que je
pouvais faire inclure automatiquement le "mailto:" devant l'adresse
mail.
Mais les utilisateurs sont stupides, c'est un postula à poser. Et
donc quand ils ont une adresse mail à écrire quelque part, ils peuvent
fort bien avoir l'envie stupide de supprimer ou d'écorcher le
"maito:".
Bien entendu je pourrais après validation corriger le tout ...

Mais bon,
Alors je ne me pose plus de questions : une API, un formatage bleu
souligné et le tour est joué ...

Là dessus, j'ai pas mangé et j'y vais de ce pas.

Cdt,
Pascal

pascal58 a écrit, le 08/04/2012 20:30 :

Hello Gloops,

J'ai plus l'impression que tu soliloques qu'autre chose.

Si Access peut utiliser des champs hypertexte, c'est aussi pour évite r
aux utilisateurs lambda d'avoir à programmer en VBA. Non ?
Si tu migres vers SQL SERVER, MYSQL ou tout autre base de données, tu
vas avoir un problème. Et je le connais. J'expliquais ma difficulté
en comparant le langage d'Access à un patois comme le Picard (ch'ti)
qui utilise parfois des mots pas toujours appropriés. « on mingeot
eine platélée d'mutieau, eine tarteine au fromache ou bin ein
pistolet. » (si tu recherches la phrase complète sur Goggle, tu aur as
une traduction). Imagine le gars qui ne connaisse que cette langue et
qui doit tout à coup porter son "mutieau" en Français.

Access et hypertexte, grand bien lui fasse, mais ce n'est pas une
bonne idée de Micro$oft.

Bien entendu que je connais la méthode du split, bien entendu que je
pouvais faire inclure automatiquement le "mailto:" devant l'adresse
mail.
Mais les utilisateurs sont stupides, c'est un postula à poser. Et
donc quand ils ont une adresse mail à écrire quelque part, ils peuv ent
fort bien avoir l'envie stupide de supprimer ou d'écorcher le
"maito:".
Bien entendu je pourrais après validation corriger le tout ...

Mais bon,
Alors je ne me pose plus de questions : une API, un formatage bleu
souligné et le tour est joué ...

Là dessus, j'ai pas mangé et j'y vais de ce pas.

Cdt,
Pascal

Bon, c'est bien mon habitude, il se pourrait bien que je la garde.
Enfin quand même, ce joujou m'a donné un peu de recul, alors je vais
réfléchir un peu sur cet appel à l'API. Je me suis rendu compte que le
champ hypertexte a quand même l'intérêt de contrôler ce qu'on met
dedans. Si on recourt à l'API, on prend la responsabilité de faire ce s
contrôles tout seul comme un grand. Et ça, c'est un point auquel je
n'avais pas pensé jusque là.

C'est vrai qu'il y a quelque chose d'étrange dans ma démarche : pour
l'appel à l'API je ne me suis pas posé de question, quand il y a eu u n
champ hypertexte j'ai testé quelques bêtises qu'on pouvait mettre
dedans. Et c'est ça qui m'a rappelé que c'est l'appel à l'API qui e st le
plus vulnérable de ce point de vue.

C'est vrai que c'est pas mal si on peut en faire un minimum, en matière
de développement VBA. Ce qui ne dispensera pas de la création dynamiq ue
des champs créés après un premier déploiement, sinon on est assur é de
tomber un jour sur une version de la base de données qui ne comporte pa s
le nouveau champ, et donc sur le message "champ inconnu".