PureBasic

C'est pour ça que j'ai hâte que le fichier d'aide soit mis-à-jour à l'égard des libs Module/Runtime afin de mieux comprendre leur utilisation et leur but, car cela m'intrigue

La librairie Runtime c'est une sorte de moteur de fenêtres basé sur XML (qui, pour le coût, n'est qu'un format de fichier qui ne fait pas partie de la librairie). C'est drôlement puissant et ça va permettre de générer des interfaces beaucoup plus rapidement, notamment grâce aux gestionnaires de placement (les layouts).

Ça autorise également la génération de fenêtre à la volée simplement => l'appli génère le XML qui génère les fenêtres utilisées par l'appli. Ce qui était faisable avant mais qui est simplifié par cette librairie. Bref ça ouvre tout un tas de possibilité.

Pour la librairie Module, c'est une autre évol aussi intéressante et aussi puissante. Ça ajoute un namespace aux fonctions / variables. La cloisonnement des noms de fonctions va permettre de créer du code plus facilement réutilisable. Exemple pour 2 librairies qui aurait une fonction Add(). Sans les modules on doit appelés les fonctions LibA_Add() et LibB_Add(). Maintenant il est possible faire LibA::Add() et LibB::Add().

Notez qu'on se rapproche de la POO dans les notations. Petit à petit, on y arrive...

Merci CLS de ces explications détaillées

Notez qu'on se rapproche de la POO dans les notations. Petit à petit, on y arrive...

Et ben on est pas sorti de "l'eau des berges"

Spock a écrit : rien ne nous empeche de ne pas suivre cette progression ...

Clairement, chacun fait comme il veut

Oui vous avez raison tout les deux
J'espere que FRED ne perdra pas de vue que pas mal de nous ont choisi PB du fait de son mode de programmation procedural.
Je me doit de reconnaitre que pas mal des fonctions apportées depuis 8 ans n'ont pas été trop faites dans la douleur, on peut toujours utiliser l'ancienne methode, et ça c'est cool

J'ai même decouvert qu'on peut mettre une bibliotheque d'une ancienne version à la place de la nouvelle, comme par exemple pour la lib Packer ou j'avais rien compris au nouveau systeme de compression
En fait, c'est que je ne croyait pas OBLIGATOIRE de mettre un UseTrucMucheCompress()
C'est vrai c'est noté : "Vous devez utiliser un UseTrucMucheCompress() auparavant"...certes (comme dirait le colonel chef chaudard),...... mais ce qui est dommage c'est que l'on ai pas un MsgBox comme dans le dessin disant qu'il faut activer StartDrawing() avant.

Du coups j'ai cherché plusieurs jours pourquoi ça marchait pas dans des codes megacompliqués que je comprenais pas toujours
En fait, moi j'aurais mis un super MsgBox : "ATTENTION !!! Il faut utiliser un UseTrucMucheCompress() auparavant, au risque de perdre une semaine de votre vie à chercher un bug qui n'existe pas"

Kwai chang caine a écrit :pas mal de nous ont choisi PB du fait de son mode de programmation procedural

Et moi, c'est pour ça que je le délaisse de plus en plus

Bah, je ne pense pas que FRED ai eu l'envie au commencement de PB de le faire objet.
Sinon il aurait pris cette direction du départ, l'objet existait surement déjà à cette epoque non ???
PB de mon humble avis est un C simplifié, la puissance du C sans sa rigueur et sa complexité.

Maintenant quoi qu'il fasse il n'arrivera jamais à contenter tout le monde :
Un peu comme sur les tee-shirt c'est marqué :
"une femme sur deux b....mal"
"Qu'est ce que vous voulez..je peux pas etre partout..."

Mais le fait qu'il ne perde pas son coté procedural, même si il devient EN PLUS objet, ferait peut etre naitre le miracle de reunir les torchons et les seviettes dans le même panier.
Reste à déterminer qui sera la serviette

J'avoue que moi ayant testé le VB est été attiré par le coté objet du style, exemple:

RichTextBox1.ForeColor = Color.Black

Ceci simplifie grandement la programmation je trouve

Le coté objet est plus appréhendable et plus simple que je pensais, c'est même fun je trouve