"Mais si je ne la mets pas a jour à chaque nombres premier trouvé il faudra que je les affiche tous d'un coup et ça va aussi prendre du temps non? "

Tu peux faire un appel à la méthode BeginUpdate au début du calcul. Une fois terminé, tu appelles la méthode EndUpdate de la propriété Items de List1. Et là, le temps de traitement sera divisé par un facteur significatif. Résultats garantis et qui prouve que ce qu'a dit Nono40 est tout à fait exact.

L'exploitation de ressources dans une DLL dépasse quand même le niveau débutant.

L'unité Unit2 est utile puisqu'elle est appelée par Button5Click. Chacun se fait sa pub comme il peut mais qu'il ne vienne pas se plaindre d'être spammé après cela.

Idem pour miniFMOd puisque XMPlayFromRes est appelée lors de l'activation de TForm2.

A propos de TForm2 : le contenu est inexact. Il ne s'agit pas de "charger des images dans une DLL" mais d'afficher des images contenues dans une DLL.

Enfin, on n'est pas pollué par les commentaires, ni dans le code ni sur ce site. Dommage...
Pour les débutants, il aurait été utile de leur indiquer la démarche pour réaliser une DLL de ressources ou, au moins, de leur donner quelques bonnes adresses.

Je retiens un ensemble de routines intéressantes dans l'unité miniFMOD. Dommage qu'elles ne soient pas mises en avant pour intéresser davantage de monde à ce code source.

KoolFree2005 : ce serait bien de mettre une description plus "vendeuse" si tu veux des visiteurs.

Thanks a lot, Akelawhite ;o)

Tout d'abord, je salue la présence de Nono40 parmi nous.
Comme la création dynamique de composants, leur sauvegarde  et leur restauration à partir d'un flux fichier est un sujet sur lequel nous avons collaboré, j'invite les curieux à se rendre à cette adresse : http://tinyurl.com/k72zj

Toutefois, voici un point sur lequel je suis un peu moins d'accord quand il écrit "Tu dérives une classe descendante de TObjectList ou même un TComponentList et tu n'as plus rien à transtyper non plus."
Je trouve que c'est se donner beaucoup de mal quand on n'a besoin que de deux ou trois méthodes de TObjectList, TComponentList ou autres semblables. Il faut pratiquement surcharger toutes les méthodes alors qu'elles ont été définies comme statiques par les concepteurs de la VCL.
Dans ces cas là, je vous conseille d'opter pour la composition et non l'héritage.

Caribensila a écrit : "j'avais rencontré des problèmes pour traiter les événements des compos créés après un 'ReadComponentResFile' dans le code"
Quand tu affectes une méthode à un évènement, tu affectes en réalité un pointeur de méthode. Si au cours de la session courante de ton logiciel tu affectes Nil puis que tu affectes de nouveau une méthode à un évènement, pas de problème. Mais comme les exe sont relogeables et rien ne permet de dire que la session suivante s'effectuera avec les mêmes adresses mémoire, je te laisse imaginer les dégâts que cela pourrait causer si tu affectais une adresse qui ne serait alors plus valide !...
GPF garantie 8-S

Quand on ne connait pas à l'avance le nombre de composants qui seront créés à l'exécution, l'utilisation de listes est encore meilleure que les tableaux quand bien même ces derniers seraient dynamiques.
La VCL propose un certain nombre de conteneurs tels que TList, TObjectList ou encore TComponentList.
D'ailleurs, la propriété Components des objets dits "containers" n'est-elle pas une liste de références ?
Caribensila, je trouve que ta forme baisse ces derniers temps ;o)
Une petite cure de vitamines te ferait le plus grand bien, lol.

On passe souvent à côté des choses simples et évidentes mais Ô combien puissantes.
Là, moi je dis bravo à Caribensila dont je salue le come back.

Extra !
Que du code comme on l'aime !
Félicitations.

Quel est le but de mettre le constructeur en portée Published ?

Je n'ai pas regardé l'implémentation mais le sérieux et la réflexion menée pour définir la partie interface me semblent intéressantes.
Encore une belle démonstration de la puissance de la POO.
Bravo mon cher Foxi.

Pourquoi vouloir créer une classe par type de données à traiter ?
As-tu déjà entendu parler des templates ?
Tu vas me répondre que ce n'est pas possible en Delphi, je suis sûr !
Eh bien non, c'est possible et jette donc un oeil à cette page sur le site de Borland et regarde bien la classe _vector_ :
http://bdn.borland.com/article/0,1410,27603,00.html

Tu pourrais t'épargner bien des prises de tête.
Ah ben voui, si t'avais su avant, c'est sûr que... ;o)

Dans la procédure CopieFichier tu as écrit :
buf : array [1..32768] of Pchar; {taille du buffer 32Ko par defaut mais vous pouver modifier pour voir le resultat}

Il doit y avoir une erreur. Soit tu as voulu déclarer un array of char, soit tu as déclaré un buffer de 131072 caractères !
Un PChar est un pointeur sur chaine et a une taille de 4 octets (adressage 32 bits).
Donc tu as déclaré un buffer de 32768 * 4  soit 131072 octets.

Autrement, on trouve encore trop de composants non renommés ralentissant la lecture du code source. On en est toujours à se demander ce que doit faire tel ou tel composant. Le code doit se lire sans avoir besoin de faire des allers retours entre l'éditeur de code et le concepteur de fiches de Delphi. Ca devient pénible car les membres ne cessent de faire cette remarque mais tout le monde s'en fout. Pas sérieux tout cela.

Je laisse le soin aux autres membres le loisir de détailler les nombreuses maladresses et lourdeurs dans le code.