Demande avis pour un "Memo_color"

Bonjour,
Je suis en train de faire un programme 100% Panoramic pour remplacer le programme MemoRich que j'ai déjà présenté, mais qui n'est vraiment pas pratique d'emploi. Je le nomme MEMO_COLOR.
Celui que je fais est une écriture sur des images en directe avec les attributs divers dont les codes sont en arrière-plan, comme cela est le cas avec un objet TEditRich (ce qu'on a avec Word ou autre)

Si je parle de ci-tôt de ce programme, c'est parce que il y a un inconvénient. Si je ne pense pas à détourner le clavier, lorsque je programme sur une autre fenêtre, ou que j'écris dans un autre éditeur, le programme continu à écrire sur mon texte.

Je ne sais pas si ce programme vous intéresse, mais si c'est le cas, j'aimerai le savoir, car dans ce cas, peut-être que Jack accepterai (si c'est possible pour lui), de faire une instruction qui me semble fort utile, pour ce type de programme, une instruction qui permette de savoir quelle fenêtre est active, un genre iF HANDLE_ACTIVE(handle de la fenêtre) = 1 then traitement.

Je donne un mot de ce programme, pour que vous puissiez juger de l'intêret pour vous ou non.
On écrit sur la forme, comme dans un memo. A la différence d'un MemoRich, on ne met pas un attribut par sélection, mais par ce que j'appelle un "taquet attribut". C'est à dire qu'à une position donnée, on met un attribut de couleur écriture, et fond, size et police, gras.... On arrête l'attribut des mots, par un nouvelle attribut qui reprend l'ancien (ou un autre.)
Cette façon de procédé est plus facile à programmer qu'avec un MemoRich. Il n'y a pas de sélection à faire. On procède comme je le faisais avec Oric I ou avec Atari, lorsque je faisais dans une page A4,  3 fois 3 écrans de minitel, soit 9 pages.

Ainsi on peut faire des rapports en couleur par programme. On peut cliquer où on veut sur l'image, la ligne et la lettre est repérée. On peut modifier à volonté le texte et l'attribut.
Cela dit, il faut penser qu'on est en basic, et que la vitesse de saisie n'est pas rapide. Elle l'était au départ, car j'avais choisi une police fixe: Consolas, avec font_size de 10, mais à partir du moment où toute partie de texte est variable, le traitement est beaucoup plus long.
Aussi pour faciliter les choses, je mettrais un outil: memo pour la saisie du texte, et une fois fini, celui-ci se recopie dans le memo_color.

Pour l'instant le traitement de saisie est fini (écriture, effacement arrière - avant, Enter, et les attributs. Je vais m'attaquer au décalage écran, et un ascenseur particulier pour le scroll vertical.
Ensuite dès le départ, je code 10 Memo_Color pour faciliter l'intégration. Ce seront 10 pictures avec width 0 et height 0, qu'il suffira de placer ensuite, comme au veut.

Je vais faire en sorte que la portabilité et la façon de s'en servir soit des plus simples.

Voici un exemple de ce que cela donne:

Spoiler:

Si il n'y a pas d'intervention, c'est que vous n'êtes-pas intéressé.

Ah oui! dans l'exemple, je vois les n° de ligne. C'était pour savoir si c'était possible ou non.

Oui ton programme est intéressant par contre pour tes taquets d'attributs plutôt que de réinventer tes propres codes pourquoi ne prends tu pas une partie des balises HTML ?

Après pour le iF HANDLE_ACTIVE(handle de la fenêtre) = 1 then traitement, je crois que l'on a déjà ça, je ne sais plus si c'est dans Panoramic ou dans la DLL de Klaus. Je ne peux pas regarder ici au boulot, mais je crois que l'on a ça. (A vérifier)

Merci pour ta réponse.
1) pour les taquets: j'ai voulu utiliser un procédé simple qui évite de faire toute série d'analyse du code. Et je signale que cette partie du codage est fait, et vu le temps que j'ai passé pour déboguer, je ne recommencerai pas. Si quelqu'un veut faire un éditeur htlm, il a ma bénédiction.

J'ai procésé ainsi: les balises sont actuellement "{" et "}", pour quelles soient visible pendant le décodage, mais ce sera autre chose ensuite. Dans ces balises, j'ai 5 codes, soit 5 octets. 1 pour gras, italic, souligné, barré, qui donne un résultat de 0 à F pour la somme respective de 8+4+2+1. le 2ème aussi un code hex, qui sera peut-être remplacé par chr$, pour avoir plus de possibilité, et c'est pour size. le 3ème un code hex$ pour une fonte dans un list où j'ai choisi quelques polices. Je ne vois pas l'intérêt pour du texte d'avoir une multitude de fontes inutiles, et ça me prend qu'un caractère. les 2 derniers: 1 code hex$ pour l'encre, et l'autre pour le fond.

2) question dll, hors de question! Pourquoi: je fais un programme qui sera un include, et je ne peux pas savoir à l'avance comment celui qui programme, utilise ou non déjà une dll, et comment il s'en sert, et comment il la définie.
Est-ce res%=, ou r%=, ou resultat%=, ou tout-autre chose. Comme il n'y a jamais eu d'accord pour que tout le monde utilise les mêmes procédés, j'évite cette fonction. Et si une autre dll que kgf est utilisée, je n'ai pas de possibilité pour le savoir. Si je veux que le programme soit généraliste, cela est à éviter. Les fonctions handle de Panoramic ne conviennent pas. Elles permettent de connaitre les handle de fenêtre et de d'objets, mais pas de savoir quelle fenêtre est active à un moment donné.

Sinon bien sûr si Jack est OK, la fonction "intégrée" pour connaitre le handle de la fenêtre active serait bien.

@Cosmos,
çà semble intéressant, j'attends de voir la suite car je ne suis pas certain d'avoir tout compris sur la finalité.
dit-moi si je me trompe ? il s'agit d'un memo pour Panoramic (mais en couleur) que l'on pourrait utiliser comme si c'était un objet Panoramic. Si c'est le cas c'est effectivement intéressant.

A+

Le sujet est très intéressant.
En Panoramic on a :

Res%=HANDLE_FORM("caption_du_form$") 
qui renvoie le handle du form dont on connaît le caption et 0 si le form n' existe pas.

mais rien qui permette de faire ce que tu veux.

La commande que tu demande serait la bienvenue mais il faudrait peut être ajouter
deux autres une pour activer un form à partir de son handle et l' autre pour le désactiver.
mais là, je deviens peut être exigeant...

Pour mon programme, seul la commande citée suffit.  Même en arrière plan, en travaillant sur un éditeur ou autre), Panoramic continu la saisie. Il me suffirait dans la boucle: if Handle_active(...) = 1 alors Panoramic est à l'écoute, sinon il va reboucler jusqu'à ce que Panoramic soit au premier plan. Maintenant je me demande si il ne faudrait pas avoir ce même type de commande pour un objet comme edit, non après-tout, est-ce différent de lire le handle d'une fenêtre ou d'un objet ?

La dernière possibilité qui ne reste, est de faire un petit programme AutoIt qui me donne le résultat dans un edit. D'ailleurs il m'intéresse de faire l'essais du programme avec le compilateur en préparation, et pour ce faire, vu que Jack a des problèmes avec le clavier, je pourrais mettre en attente de résolution, le programme AutoIt, qui donne les codes du clavier. Je l'avais déjà fait au départ, lorsque j'ai posté un message comme quoi inkey$ ne fonctionnait pas.. Il suffit pour Panoramic de scruter un edit avec par exemple ON_Change pour se servir du clavier.

En fait il faudrait l'équivalent sur un FORM, d'un COMMAND_TARGET_IS ...

  Bon, là je suis vraiment en retard... mais je voulais changer mon avatar, un éditeur m'a dit que Mc Gyver ce n'est plus connu des djeunzes...

Bonjour,
En fait hier soir j'ai recherché pour AutoIt.
J'ai trouvé la commande qui est utilisé par ce langage: WinAPI_GetForegroundWindow() et qui fonctionne.
Moi j'ai marqué 100% Panoramic. On verra bien.
L'avantage que j'ai avec AutoIt, est qu'il n'y a pas de problème avec l'utilisation d'une dll, sans savoir si dans un include, une dll ou une autre est déjà ouverte. Quand à l'utilisation mémoire, je ne pense pas qu'elle soit supérieure à celle d'une dll. En fait mon possible que l'occupation de la mémoire soit minimum. J'aimerai connaitre l'avis d'un spécialiste. Est-ce qu'une dll pour faire la même chose qu'un programme prend moins de mémoire? A moins que la dll se met en série dans le noyau de Panoramic.