Ecraser une partie d'un string par un autre

J'ai ajouté une nouvelle fonction à ma dll Strings.dll. elle permet d'écraser partiellement un string par un autre, en choisissant le décalage de départ dans le string de sortie

Exemple:

Code:

dim entree£, sortie$, offset%, i%
entree$ = "123"
sortie$ = "abcdefghijkl"
offset% = 5

i% = dll_call3("StringOverString",adr(entree$),offset%,adr(sortie$))
' le résultat dans sortie$ = abcd123hijkl"

Disponible sur mon site dans la distri de KGF.dll

Ha!!! ça ça m'intéresse!

Entre jack et toi je me demande désormais lequel s'inspire de l'autre

@Tecking,Ce dont je suis certain c'est que les deux sont des passionnés.

C'est ta deuxième provocation dans le même journée (à moins que ce ne soit un humour auquel je suis imperméable), surveille toi.

Provocation? Humour? je ne vois pas désolé.

On est tous passionné ou au moins intéressé. c'est pourquoi on est la.
Ton post veux-t-il insinuer que personne n'aurais le droit de se prendre pour jack et de développer son langage?
Que je n'ai pas le droit de comparer deux développeurs?

Moi c'est à ce genre de réflexion que je suis imperméable, désolé.

Et ne t'inquiète pas je me surveille.

Ta façon de voir les choses t'appatient, peut-être que tu as raison, je manque d'humour.
J'arrête là, car ce n'est pas le sujet pour débattre. Klaus parlait d'autre chose. Tu peux facilement trouver mon adresse mail... A+

On peut aussi faire comme ça:

Code:

dim s1$, s2$, ofs%

s1$ = "abcdefghijkl"
s2$ = "123"
ofs% = 5
s1$ = LEFT$(s1$,ofs%-1)+s2$+MID$(s1$,ofs%+LEN(s2$),LEN(s1$)-ofs%-LEN(s2$)+1)
PRINT s1$

Et je regrette toujours qu'il faille préciser le dernier paramètre du MID$, alors que ça devrait être implicitement le reste de la chaîne.

Je pensait que l'avantage des DLL était de pouvoir inventer ses mots clé perso?

Ah ?

@JL35: effectivement, ma fonction fait exactement cela Faut voir ce qui est plus clair et plus rapide. Puis, j'ai maintenant 2 fonctions string: CompareStr qui retourne une valeur <0, 0 ou >0 suivant si str1$<str2$, str1$=str2$ ou str1$>str2$, et cette fonvtion StringOverString. Mais il y en aura d'autres - et en particularité le retour d'un indice indiquant quelle place occupe une chaine dans une autre, mais pas comme instr: imagine une chaîne avec des segments délimités, tu fournis une autre chaîne et tu veux savoir quel est le numéro de segment qui correspond, sachant que chaque segment est de longueur variable. La fonction retournera alors 0 si pas trouvé, 1 pour identité avec le premier segment, 2 pour identité avec le deuxième segment etc. Intéressant, non ? Peut servir à analyser des fichiers CSV, ou les paramètres passés en ligne de commande DOS, etc...

@Tecking: une DLL sert à apporter des fonctions non disponibles autrement, ou non disponibles simplement. Exemple, communication entre programmes. De nouveaux mots-clé ou autres fonctions fondamentales ne peuvent être apportés que par l'auteur de Panoramic, du moins tant qu'il n'y a pas la notion de plug-in, et encore, faudra-t-il voir, si ça se fait un jour, quelle sera l'étendu de l'accès offert aux plug-in. Pour le moment, c'est de la science-fiction.

J'ai codé quelque chose comme ça pour un fichier genre csv (je ne sais plus où, et comme la recherche est un peu branlante...), mais c'est un peu lourd en basic avec les outils actuels, effectivement si on en a l'usage et qu'on puisse le sous-traiter à une dll, ça évite de se casser la tête (sauf toi).
Comme pour mon exemple ci-dessus: c'est un peu pénible d'avoir à calculer les tailles des segments à chaque fois, alors si c'est sous-traité, tant mieux.

Pour l'Instr, ce qui manque c'est la recherche dans la chaîne à partir d'un indice donné, pour rechercher des occurences successives. Mais je ne doute pas que tu vas nous concocter ça parmi tout le reste.

En effet, c'est prévu...

Tu vois, ça y est : ma DLL Strings contient une nouvelle fonction InString qui fait exactement cela - regarde ce lien:
https://panoramic.1fr1.net/vos-sources-vos-utilitaires-a-partager-f2/chercher-un-string-dans-un-autre-avec-un-offset-t1028.htm

Sans vouloir lancer de polémique, je ne donne que mon humble avis en tant que débutant sous pano:
mais l'intérêt des DLLs c'est d'apporter des nouvelles fonctionnalités non réalisables sous Panoramic (en attendant que Jack mette sa touche).
Je ne dénigre pas le travail de Klaus, loin de là :
Quand on vois le boulot qu'il effectue, la patience et la gentillesse qu'il met aux services des panoramiciens je ne dis qu'une chose : chapeau bas !
Mais je pense, comme l'a démontré JL35, que certaines fonctions de traitement de chaine peuvent être réalisées sans passer par DLL.
Il est clair que c'est plus compréhensible/attrayant d'écrire :

entree$ = "123" : sortie$ = "abcdefghijkl"
offset% = 5
i% = dll_call3("StringOverString",adr(entree$),offset%,adr(sortie$))

que de se prendre la tête en écrivant :

s1$ = "abcdefghijkl" : s2$ = "123"
offset% = 5
s1$ = LEFT$(s1$,offset%-1)+s2$+MID$(s1$,offset%+LEN(s2$),LEN(s1$)-offset%-LEN(s2$)+1)

Mais je trouve que sur le plan pédagogique, la deuxième solution apporte un plus...
Tout comme d'ailleurs le travail monstrueux (y'a pas d'autre mot) qu'a fait Klaus sur les GList.

Cela peut paraitre bizarre pour certains que je tienne ce langage, car il vrai que je m'intéresse aux DLLs,
mais c'est peut être parce que je ne connais pas suffisamment Panoramic...
et que Klaus est toujours sur les starting-bloc quand il s'agit d'ajouter des nouvelles fonctions... c'est vachement tentant !!

Le piège avec les DLLs c'est qu'a force de les utiliser, on risque de dénaturer Panoramic (qu'il ne soit plus qu'un 'squelette' sur lequel s'appuient des DLLs) et au final de pousser les gens à s'intéresser plus à Delphi qu'au langage Basic...
Ce qui serait évidemment, bien dommage.

Amicalement,
Nardo

C'est pas faux, mais ce qui importe c'est que çà n'empêche pas Jack de suivre sa route. Et les utilisateurs des DLL(s) la leur.

Personnelement je préfère attendre les évolutios de Panoramic car c'est plus simple pour moi. J'aime fabriquer des programmes, mais je n'aime pas me prendre la tête.

Les 2 côte à côte, c'est bien ainsi.

Avis personnel, bien entendu.

A+

Je suis bien d'accord avec toi,
chacun est libre de faire ce qu'il veut...

Mais je suis sûr qu'il y a certainement des Panoramiciens (JL35, Klaus, ainsi que toi et beaucoup d'autres ) qui ce sont déjà pris la tête pour écrire des solutions pour un problème donné en Panoramic (quitte à les modifier par la suite pour en faire des procédures appelées via un gosub).
Je trouve très enrichissant (dans le forum de Panoramic) de se pencher sur un code écrit dans ce langage que de faire appel à une "boite noire". enfin, c'est mon avis...

L'idéal serait d'avoir des bibliothèques de fonctions écrites en panoramic disponibles à l'ensemble des panoramiciens. Un petit include et hop le tour est joué! (cela éviterai de réinventer la roue). Reste à savoir comment gérer cela.. (CVS, autre...) Je suppose que ce sujet a du déjà être abordé (mais je n'arrive pas à trouver le moindre message dans ce satané forum! )

Pour finir, je suis entièrement d'accord sur l'utilisation des DLLs du moment que c'est pour rajouter des trucs irréalisables en pano... (puis cela diminuerai le boulot de Jack)

Je me réveille (il est temps !), mais j'allais dire à peu près la même chose: oui pour les dll pour ce qu'on ne PEUT PAS réaliser en panoramic pur, par contre s'il y a un moyen, même détourné, de le faire en panoramic, je préfère, parce que là au moins je maîtriserai mon code, contrairement à la boîte noire dll.

C'est vrai que l'idéal serait de monter une bibliothèque commune de routines qui feraient chacune une chose bien précise (dans les domaines des strings, graphiques, etc.).
Mais dans l'était actuel des choses, ce n'est pas très facile à intégrer, malgré l'Include, à cause des déclarations de variables et labels qui risquent de provoquer des conflits avec l'existant.

Cela dit, moi aussi je tire mon chapeau à Klaus, pour tous ses utilitaires irremplaçables (j'utilise régulièrement le WinTextPrint, génial), et pour... sa rapidité à programmer des produits opérationnels du premier coup !

En ce qui concerne la déclaration des variables dans une bibliothèque, on peut s'appuyer de l'exemple de Klaus au sujet des GLists...
mais alors là, bonjour le boulot !!
Mon chapeau est tout abimé à force de trainer par terre !

(J'espère que Klaus a utilisé des "Search&Replace" pour nommer ses variables)

J'avais pensé, dans chaque sous-programme de bibliothèque à un truc du genre:

Code:

Monsp1:
IF inisp1% = 0
    DIM v1$, v2$, ..... s%, z%
    LABEL r1, r2, ...
    inisp1% = 1
END_IF
'  ... déroulement du sous-programme
r1: ...
...
RETURN

mais c'est quand même scabreux, il faut quand même déclarer le nom du s/p et la variable inisp1%, mais surtout il faut qu'aucune des variables ni labels internes n'existent pas ailleurs, alors il faut s'astreindre à leur donner un nom unique, mais forcément assez compliqué, du genre i_sp1%, a_sp1$, tu me diras c'est une fois, après on ne l'utilise plus ailleurs et on n'en parle plus.

oui ou un truc dans ce genre :

Code:

#include "string.def" :  ' ici un fichier qui contient les déclarations des variables nécessaires à la librairie

' ici commence mon programme
dim a$
...
a$="abcdefghijkl"
...
...
strReplace_dest$ = a$ : strReplace_src$ = "123" : strReplace_offset% = 5
gosub strReplace
a$= strReplace_dest$
...
...
...

end
' ---------------------------------------------------
' -                  fin du programme
' ---------------------------------------------------

#include "string.bas" : ' ici la librairie proprement dite...

puis dans string.def :

Code:

label strReplace
dim strReplace_src$,strReplace_dest$,strReplace_offset%

et dans string.bas :

Code:

' ************************************************************************
' * LIBRAIRIE DES FONCTIONS DE MANIPULATION DE CHAINE
' ************************************************************************

strReplace:
    strReplace_dest$ = LEFT$(strReplace_dest$,strReplace_offset%-1)+strReplace_Src$+MID$(strReplace_dest$,strReplace_offset%+LEN(strReplace_src$),LEN(strReplace_dest$)-strReplace_offset%-LEN(strReplace_src$)+1)
return

ouh là, c'est un peu tordu ton affaire ! attends, je vais d'abord chercher une aspirine...
et en plus tu essaies de me troubler en donnant deux noms différents à la même routine... pas sympa...

Je vois, mais c'est pas très facile à manipuler non plus...
Vivement les variables locales !

La déclaration obligatoire des variables, c'est bien pour la rigueur, mais ça ne vaut pas le bon vieux basic où on ne déclarait rien du tout !

Désolé, mais je ne suis pas d'accord.
Il m'est arrivé d'utiliser un langage avec
- variables locales (pour une procédure)
- variables je sais plus quoi (pour une form entière)
- et variables globales (pour toutes les form).

J'ai trouvé ça inutilement compliqué !
Je trouve bien plus simple les variables panoramic.

Je déclare des variables provisoires (comme locales)
comme i , j , a$... que je réutilise indéfiniment (en les réinitialisant à 0 ou à "")
sans avoir à les redéclarer à chaque fois
et des variables spécifiques (comme globales)
que j'utilise chacune pour un usage particulier.

Je trouve qu'il n'y a pas plus simple et que c'est mieux comme ça.
Et en faisant comme ça, on peut utiliser les variables
de toutes les manières possibles,
sans qu'il y ait de choses qu'on ne puisse pas faire.

Alors, ça ne servirait à rien de plus
d'avoir des variables locales ou globales.
Voilà, c'est mon avis !

Citation :

Je déclare des variables provisoires (comme locales)
comme i , j , a$... que je réutilise indéfiniment (en les réinitialisant à 0 ou à "")
sans avoir à les redéclarer à chaque fois
et des variables spécifiques (comme globales)
que j'utilise chacune pour un usage particulier.

Complétement d'accord, Je fais exactement pareil.

Et compte tenu des possibilité des matériels actuels et du "NoLimit" de Panoramic, pourqoi se compliquer.

Oui certes, mais il y a des risques, surstout avec des variables courantes (pour moi) comme i, j, x, y, a$ etc
Si tu fais dans le programme principal
FOR i% = deb% to fin%
....
Gosub sousp
...
NEXT i%
et que dans le sousp tu utilises quelque part i% ça fiche tout en l'air, alors qu'avec des variables locales dans le sous programme, aucun risque, c'est bien plus confortable.

Mouaihhh !
(borborygme du mec pas convaincu)

Il suffit de jeter un coup d'oeil pour vérifier qu'on ne l'a pas déjà utilisée.

Ouais ! (même borborygme), si tu as de longs sous-programmes...
En tout cas ça existait en basic, pas pour rien, et on pouvait déclarer les variables soit locales, ou certaines communes, et certaines réutilisables (inchangées) d'un appel du s/p à l'autre, et je l'ai bien utilisé.