form /memo inactif / barre verticale

Bonjour,

Je souhaiterais insérer dans un form un long texte d'aide pour l'utilisateur. Je vois que le form n'accepte pas la fonction bar_vertical.
J'ai pensé apparenter à ce form un memo qui, lui, accepte le bar_vertical, mais je ne souhaite pas que l'utilisateur intervienne sur le contenu du memo. Alors je pensais le désactiver, mais si je le désactive... plus de barre de défilement ! Bref, je tourne en rond...

Avez-vous une idée pour créer un form agrémenté d'une barre verticale ? ou un memo inactif flanqué tout de même d'une barre de défilement active ? En somme je voudrais le beurre et l'argent du beurre...

Merci.

Bonjour Ambroise,
Je pense que tu peux utiliser un list. Dès que le nombre d'item est important et qu'ils dépassent sa hauteur, il met automatiquement une barre de défilement sur le coté. D'autre part, tu ne peux pas le modifier manuellement, uniquement par programmation. Quand tu cliques sur un de ses items, il se met en surbrillance, mais c'est tout.

Code:

dim i
list 1:width 1,200:height 1,600
for i=1 to 50
item_add 1,str$(i)+": "+str$(i+10)
item_add 1,"ligne "+str$(i+1)
next i

A+

Bonjour,
Est-ce que ceci est une solution?

Code:

label teste
dim a%,a$
memo 1:  bar_both 1
item_add 1,"ceci est un essai pour"
item_add 1,"modifier un texte"
for a%=1 to 100:item_add 1,"a%= "+str$(a%):next a%
on_change 1,teste:on_click 1,teste
end

teste:
set_focus 0:return

MERCI a TOUS DEUX,

@cosmos70

Ton code permet à l'utilisateur de modifier le contenu du memo (on peut effacer des lignes par exemple).

@bignono

Le list pourrait faire l'affaire en effet.

Sinon, tu fais un fichier d'aide avec wordpad que tu enregistres au format rtf en lecture seule, et tu fais une routine dans ton programme comme ceci:

Code:

label aide

main_menu 10
' les sous-menus
sub_menu 11:parent 11,10:caption 11,"Fichier"
sub_menu 12:parent 12,10:caption 12,"Edition"
sub_menu 13:parent 13,10:caption 13,"Commandes"
sub_menu 17:parent 17,10:caption 17,"Aide"          :on_click 17,aide
end

aide:
' Pour Windows 7
if file_exists("c:\monprog\aide_monprog.rtf")=1
  if file_exists("c:\Windows\write.exe")=1
      execute_wait "C:\Windows\write.exe C:\monprog\aide_monprog.rtf"
  end_if
  return
end_if
' Pour Windows XP
if file_exists("c:\monprog\aide_monprog.rtf")=1
  if file_exists("c:\Windows\system32\write.exe")=1
      execute_wait "C:\Windows\system32\write.exe C:\monprog\aide_monprog.rtf"
  end_if
end_if
return

Ou plus simplement (xp ou 7):

Code:

EXECUTE_WAIT write.exe fichier.rtf

Oui, la solution du fichier à exécuter est la solution la plus simple, en particulier pour les modifications ultérieures de l'aide. C'est la solution pour laquelle j'avais opté d'abord. Mais un fichier externe se modifie aisément, l'attribut pouvant être modifié, et il peut être supprimé.

Finalement j'ai opté pour un list. Sa construction a été longue et fastidieuse mais quand c'est fait, ce n'est plus à faire ! Bien sûr, pour une modification éventuelle, il me faudra recompiler le tout... On ne peut pas tout avoir...

Tu peux aussi charger dans ton List (File_load) un fichier annexe dont l'utilisateur ne connaît pas l'existence, donc qu'il ne peut pas modifier, mais que toi tu peux modifier dans un éditeur de textes sans avoir à recompiler.
Inconvénient, comme toujours: avoir à trimballer un fichier annexe avec l'exécutable, c'est moins transportable.

A moins d'intégrer une fonction d'export de la liste en codé, automatique si le fichier n'existe pas (genre un fichier .dat) et une ouverture de ce fichier avec une fonction de décryptage.
Ca demande peut de temps puisque les sources existent et sont juste à adapter (Notamment les fonctions de cryptage / decryptage de Klaus, puisque le test d'existance d'un fichier et l'ouverture d'un fichier (avec contrôle de validité c'est encore mieux ) sont très simples à faire)

L'idée est séduisante. Mais du fait de mon niveau élémentaire, je nage...

Bonjour;
Personnellement, j'ai plutôt tendance à faire l'inverse. Ce que je ne comprends pas, c'est pourquoi tu es si pointilleux sur le fait qu'on ne puisse pas modifier un fichier d'aide.
Je fais l'inverse. Pourquoi? pour que l'utilisateur puisse adapter l'aide à sa convenance, à sa compréhension. Exemple: dans le fichier d'aide de Panoramic, il y a un exemple pour une fonction, et je trouve celui-ci très succinct. Si en faisant des tests, on pense qu'un complément, ou l'ajout d'un autre programme est plus explicite, alors pourquoi refuser de le faire. Celui de Panoramic est intégré, donc inaccessible, mais lorsque cela le devient, j'estime que c'est un progrès.
Sans de véritables raisons, je ne souscris pas à cette façon de faire. Désolé.

Je comprends ton point de vue. Toutefois, je vais proposer mon programme à qui veut bien l'utiliser, toutes copies autorisées. Je crains que si quelqu'un modifie l'aide originale et passe sa copie à Pierre qui la passe à Paul après avoir ajouté son grain de sel, mon aide pensée au mieux ne devienne un chaos inintelligible pour le suivant. Et je n'ose imaginer le cas où on modifie mon aide malicieusement... En perdre le contrôle me pose question...

D'où la possibilité de générer un fichier d'aide (ça permet de le passer modifié ou de le regénrer si besoin )

essayes ceci:
Voir le Fichier : texte_en_exemple.exe
C'est un texte que j'ai fait pour exemple.
Cela peut t'intéresser

Ah oui, ça, ça m'intéresse au plus haut point... Tu fais ça comment ?

J'allais partir, et j'ai cliqué par mégarde.
Enfin, dans le texte, tu as l'adresse pour récupérer le programme. Il fait 403 kg, et tu le mets où tu veux.
Après comme tout autre éditeur de texte.

Ce petit programme est un must...

Merci Cosmos70 pour cette suggestion.

Pas de problème.
Par contre, même si le texte est bloqué, lors de transferts à d'autres personnes, il est tout à fait possible de récupérer le texte avec copier, de le modifier, et de faire la même chose avec ce programme, ou un autre. Je ne pense pas qu'il soit le seul à cela.