Pourquoi êtes vous allergique aux modules ?

Je constate que chaque fois que je vous parle de modules
je me fais renvoyer dans mes 22 .

Et je me demande pourquoi vous êtes aussi réfractaire quand
je vois apparaitre des #include ou chain ?

D'autant que certain n'ont pas besoin de form et que ,personnellement ,
je trouve que les sources sont plus lisible dans les cas où les dim et labels sont là à
profusion.



PS: Ces quelques mots ne sont pas une critique mais un questionnement
qui a peut être une raison que ma petite connaissance de la programmation ignore encore.

Oh, je crois que tu enfonces des portes ouvertes ! Depuis longtemps, on souhaite des sous-programmes indépendants qu'on appellerait comme ça:
CALL sousprogramme(par1,par2,...)
ou des fonctions:
resultat% = MaFonction%(par1,par2,...)

Et ces modules auraient bien sûr leurs propres dim et label invisibles en-dehors...

C'est le seul moyen d'avoir une collection - et je n'ose pas dire bibliothèque - de modules partageables entgre tous les panoramiciens.

Alors, si c'est de quelque chose dans ce genre que tu parles, je te suis à 100 % !

Ce ne suis pas tout par manque de temps.
Personnellemnt je n'ai pas remarqué ce que tu dis. Cela dit #include peut poser des problèmes à certains.

A moi en premier. Je ne comprend bien ce que j'espérimente moi-même. Ayant toujours la tête pleine d'idées ou de problèmes, j'ai du mal de rentrer dans ce qui est extérieur à ceux-ci. Je dois d'abord me vider la tête pour celà, et si j'approfondi une idée, je n'y tien pas

Ensuite il faut la bonne méthode pour qu'un include marche. Je dois dire que j'avais eu du mal sur un Palm, dont les programmes étaient dans des mémos avec 4kg maxi pour chacun d'eux, et il fallait les enchainer par include.

Mais maintenant j'ai une bonne méthode qui me parrait toute simple. Soit après les déclarations de label et de dim, je les mets à la suite, soit si il y en a plein, je mets tout dans un s/programme.

Et je procède ainsi:
étant encore dans les déclarations:
' --- include -----
' parti A: déclaration des variables et label du sous programme include
label xxx,xxx,xxx :dim xxx,xxx,xxx
label nom_de_la_procedure , sorti_etiquette

' parti B: sorti des déclarations, le reste est le programme
goto sorti_etiquette

' parti C: étiquette de branchement et programme
nom_de_la_procedure:
ligne de programme
return

' pardi D: sorti, fin de l'include
sorti_etiquette:

Il se trouve que selon ce principe, les procédures se trouve dans les déclarations, mais ça ne pose pas de problème au programme.
Les déclaration se lise à la suite, le programme est évité par le goto qui a son sens ici.
Comme les label sont déclaré, un gosub nom_de_la_procedure: ira se brancher et sortira par le return.

L'inconvénient des includes, est qu'il faut un respet des variables et des labels par rapport au programme appelant. Là il faut attendre les variables locales.

Une dernière chose: #include actuellement ne fonctionne pas avec l'instruction CHAIN.
Finalement j'ai fait un chargeur pour remplacer #include, car j'ai pas de réponse de Jack. Je ne sais pas si il veux corriger ce défaut, et travaillant maintenant avec PsPad, c'était la meilleur solution.

je vais faire un exemple:

dim b% :label include1 , sorti_include1
' -----
rem ici commence l'include
dim a% ,b% : label compter
goto sorti_include1

' ici commence le programme
include1:
b%=0 : for a%=1 to 10:b%=b%+a%:next a%
return

sorti_include1:
' -----

Si cette méthode a déjà été dite, je m'en excuse, je ne la connaissait pas avant.

@cosmos :Pour les includes, cela ressemble à ce que j'utilise moi-même (cf color.lib et base16.lib)
C'est la solution qui me parait la plus "propre"...

@ygeronimi: Je crois qu'on souhaite tous faire des programmes modulaires.
Klaus en a réalisé avec ses Pseudo-objets

DJ Peters à fait le FTP

Moi je commence tout juste avec le prog de traitement de couleur...

il y en a des modules !

Mais actuellement, je ne vais pas rentrer dans les détails, cela a été dit plusieurs fois, c'est un peu galère à réaliser...

@ Klaus,

je crois que je me suis mal exprimé en dénommant "Module"

Moi ce que j'appelle un prog modulaire
c'est un .*exe qui en appelle d'autres pour executer certaines taches.

un exemple :

pour afficher un A Propos qui est toujours le même code à l'exception du n° de version
on peut générer un .*exe réutilisable pour d'autres programmes
et le faire appeler par execute_wait en passant un paramètre.

On réduit le nombre de lignes, de dim aussi (ca peut aussi éviter les variables avec un nom à coucher dehors avec un billet de logement)
On éclaircit le code
On diminue le nbre d'objets

enfin voilà ce que j'entendais par module
pour ce que tu disais, je suis d'accord mais se pose peut être le problème de compatibilité
avec d'anciens programmes.

Perso il y a une chose qui serait bien en déclarant un objet:

exemple

button 1 (t,l,h,w) plus besoin de répéter des left width height, top+
button 1 () mesures et position par default
button 1 (,,h,w)position par default et mesure déclarés
etc...

Bon imagine maintenant ceci :
Panoramic donne la possibilité d'avoir de variables locales et de réaliser des passages de paramètres.
L'exemple du bouton que tu donnes s'écrirait comme cela: (c'est un exemple! la syntaxe pourrait être completement differente)

Code:

dim MonBouton%
MonBouton%=1

call Bouton(MonBouton%,10,10, , ,"Essai")
' puis pour une fonction :
print calcul(17)

END

PROC Bouton(id%,left%=0,top%=0,with%=50,height=20,caption$="Button"):
  BUTTON id%
  LEFT id%,left%
  TOP id%,top%
  WIDTH id%,width%
  HEIGHT id%,height%
  CAPTION id%,caption$
ENDPROC

FUNC Calcul(x,y):
  dim resultat,i
  for i = 0=1 to 5
    resultat = resultat + (3.1415 * x / i) : ' cherche pas, j'écris n'importe quoi là....
  next i
  return resultat
ENDFUNC

Tu pourrais écrire tes propres commandes et personnaliser ton code...
plus besoin de faire des exécutables "séparés" comme tu le propose.

imagine maintenant le module FTP:

Code:

#include "ftp.bas"
dim resultat%
resultat%=connection("ftp.monSite.org","Toto","MonMotDePasse")
...

Ça ne serait pas sympa ?

@ Nardo26

En effet
Mais le problème de compatibilité avec des sources.bas antérieurs va se poser.

Non il n'y aura pas de problème :
La seule chose c'est que les anciens programmes utilise des étiquettes sur des "emplacements" en absolu

si tu as besoin d'une procédure sans paramètre tu pourras toujours écrire par exemple :

Code:

gosub MaProcedure
...
...
END

MaProcedure:
...
return

ou alors avec paramètres:

Code:

gosub MaProcedure(param1,param2)
...
...
END

MaProcedure(i,j):
...
return

Et dans ce cas tu conserves l'ancienne ecriture... l'exemple que j'ai donné plus haut et juste un exemple... maintenant si Jack souhaite ajouter ces possibilités, c'est à lui de choisir la syntaxe adequate, c'est son bébé !....

Tient c'est vrai, il est passé où Jack ?



Si quelqu'un sait où il est, dites lui que quelques sujets du forum nécessite son avis.

Je sais c'est hors sujet !

@Nardo26

Tu vois ce petit clipart...
avec ton outils fini...ben fini le blanc je recupère les valeurs du fond de page sur le site
et je remplace le blanc.

Bonjour ygeronimi:

Tu peux déjà le faire : dans la dernière version du fichier zip (29/01/11), la dll est déjà présente.
Tu dois avoir un bouton supplémentaire....

ygeronimi a écrit:

Tient c'est vrai, il est passé où Jack ?
Si quelqu'un sait où il est, dites lui que quelques sujets du forum nécessite son avis.

Si j'ai bien compris Jack est précisément en train de travailler sur ce thème. C'est ce qu'il appelle des plug-ins.

Et je suis moi-même très impatient de voir le résultat

Citation :

Tient c'est vrai, il est passé où Jack ?

Toujours à son poste. Il lit le forum régulièrement.
Mais il est plus débordé que jamais.

Content de te relire Jack !
On aimerai ton avis sur plusieurs sujet du forum
et sur certains cela pourrait orienter la suite des projets.

@ Nardo

Tu l'as caché à quel adresse la dll ?


heuuuu , autant pour moi.
ca y est j'ai recharger le zip.
c'est super ! génial !

si j'ajoute un hide 0 , je ne risque rien ou le form doit rester visible ?