SFCDELPHILITE(AVEC CETTE LIBRAIRIE VOUS POUVEZ CRÉER UNE APPLICATION WINDOWS AVEC SEULEMENT QUELQUES KILO OCTETS !!!)

Commentaire de Delphiprog le 01/05/2006 23:09:56 administrateur CS

Trés intéressant tout cela.
Tu aurais quand même pu implémenter le pattern singleton au minimum car rien n'empêche de créer plusieurs objets TApplication. Imagine la suite !...

Voila un projet à suivre de très près.
Félicitations.

Commentaire de Francky23012301 le 02/05/2006 09:43:25

Quel festival en ce moment entre toi et Delphiprog !!!!

Effectivement j'ai posé récemment une question sur le forum car j'étais surpris de la taille d'une application console (je ne suis pas un habitué de ce mode). Cela provenait de l'ajout de composants non visuels. Ta source est géniale dans la mesure ou elle permet de faire des appli windows de petites tailles. A lire absolument car c'est un régal. Cependant un petit PDF pour bien expliqué ferait plaisir si ce n'est pas trop demandé.

Du reste je vais m'y replonger a tete reposée car c'est quand meme hardus. Continu ce projet car le jeu en vaut la chandelle.

Dis donc va falloir s'arreter là Messieurs (3 codes experts) : ca en fait du travail toutes ses lectures. On va plus pouvoir coder si ca continue : LOL.

Je te félicite

Commentaire de John Dogget le 02/05/2006 22:19:06

Excellente source, on ce moment, on est gâté !

Je connaissais pas non plus la lib KOL.
A ce sujet, ça marche comment ?
C'est une librairie qu'on inclue dans les uses, ou c'est un compo special ?

Merci à vous dans tous les cas :)

Commentaire de poulinr le 03/05/2006 07:44:51

KOl est un ensemble de composants qui remplacent ceux existants de Delphi. Dans la fiche on n'utilise que les classes non graphiques de delphi (classes, windows, shellapi), le reste étant les composants kol. C'est devenu assez évolué, très pratique pour faire des applications très capables mais petite de taille. Mais la présente approche me plait davantage car c'est une naissance :)  

Commentaire de Idefix57 le 03/05/2006 15:49:13

ReBonjour , J'ai une question a poser ...

Quand la bibliotheque des composant seras aussi fournies
que celle de Delphi , l'application finale ne risque pas
d'etre aussi volumineuse ?
Deuxiemme Question ...
pourrais t-on inclure comme dans Delphi des biblitheques venant
d'ailleurs ? au format Delphi ou autres languages ?

ps: J'ai fait tourner ton code sous Delphi 2005 , supert :-)

Commentaire de Delphiprog le 04/05/2006 23:25:02 administrateur CS

Shining a écrit : "peut-on mettre du code de Delphi dans un projet OpenSource, j'entends par bout de code delphi, un bout du code source, exemple classes.pas ect.. qui n'est publique que pour les versions entreprise !!!"

Tu es libre de diffuser les applications réalisées et compilées avec Delphi. En revanche, tu n'as pas le droit de diffuser les codes sources qui restent la propriété de Borland. Evidemment, si tu ne diffuses que les .DCU, c'est différent. Mais là, tu vas te heurter à l'incompatibilité avec les compilateurs des versions précédentes.

Commentaire de rt15 le 29/11/2006 13:37:45 administrateur CS

Salut,

Tout d'abord, bravo pour ce source qui permet des gains en taille impréssionnants.

Je vais juste revenir sur le bricolage des lignes 123 et suivantes de sfcDL_Forms, et proposer une solution (Pas parfaite certe mais, pas nulle non plus je pense).

Déjà, je vais essayer d'expliquer ta solution, pour ceux qui n'auraient pas fait assez d'assembleur pour la saisir.

Windows a besoin d'une CallBack. Autrement dit, de l'adresse d'une fonction à appeler, auquel il donnerat des arguments précis (Des information sur le
message).

Cette fonction serat appelé à chaque clique de bouton nottement.

Côté applicatif, tu dispose d'une instance de bouton par bouton, et dans chacune de ces instances, tu as un pointeur sur la fonction qui doit être executée en
cas de clique sur cette instance de bouton.

Il faut donc que tu fasse le lien entre le message envoyé par windows, et la bonne instance de bouton.

Un autre problème est que ton code est tout en objet, et que tu n'as donc que des méthodes.

Une méthode diffère d'une instance classique (A prototype équivalent) par l'ajout d'un argument implicite tout a fait caché : l'adresse de la structure
(Stockant les attibuts nottement) de l'instance.

En gros :

a.Msg(b);

est compilé

Msg(a, b);

De là, tu sautes sur l'occasion, tu vas ajouter l'adresse de la structure à la volée.

Le code d'ajout de l'adresse, ne peut par définition se trouver que dans la structure de l'objet lui même, du fait qu'il y a une adresse d'instance par
instance.

Ensuite, il suffit de donner l'adresse de cette attribut, contenant le code d'ajout de l'adresse, à windows (Qui l'appelerat sans se poser de question)

Cette attribut appellerat ensuite une méthode prenant les paramètre envoyés par windows, en plus de l'adresse caché.

Le code de l'attribut revient donc à :

1 pop ebx
2 push adresse strucuture
3 push ebx
4 jmp méthode

1 On récupère en fait l'adresse de retour qui serat executé quand la callback aurat fait son taffe.
2 Puis on pousse l'adresse de la structure de l'instance. (Les arguments sont empilé de droite à gauche, l'argument caché etant situé à gauche).
3 On remet en place l'adresse de retour.
4 On se déroute sur la méthode.

Ce code serat executé dans le tas (Dans les structures des différentes instances) à chaque fois que windows enverrat un message.


Cette astuce est manifique, diaboliquement efficace, et vachement bien trouvé.

Néanmoins, elle est pas franchement lisible, et l'execution de code dans le tas est pas super propre.
Sans compter que des protection empèchant l'execution de code dans le tas existent.

Ma proposition de solution, c'est d'utiliser une valeur sur 32 bits laissé au bon vouloir de l'utilisateur dans les données de la fenêtre gérée par windows.
(Je ne parle pas des données supplémentaire, qui seraient chiante à mettre en place car il faudrait recoder les classes BUTTON et companie).
Mais d'utiliser l'attribut GWL_USERDATA.

Il est affectable via SetWindowLong, et récupérable via GetWindowLong.

L'inconvénient est que l'overhead est plus important qu'avec ta méthode. Mais il n'est pas non plus monstrueux.