Discussion :

[rvzip64]

Salut tout le monde,

J'ai besoin de savoir si la méthode que je veux mettre en place et la meilleure avant de la coder.

Voila donc en fait j ai une base de données qui va me renvoyer un certain nombre de data. En fonction de ces datas, je dois créer dynamiquement un écran.

Ce que je vais faire c est mettre dans cet écran, une scrollbox et construire dynamiquement un certain de nombre de frame a l'intérieur (ça peut aller jusqu' a une bonne centaine). Le truc c'est que cette technique ne me semble pas la plus optimisé, et je me doute qu'elle va prendre un bon paquet de temps.

Qu'est ce que vous en pensez ??
Est ce que vous avez pas une solution plus adapté a mon problème ?

[Clorish]

les TFrames sont tres bien pour le developpement de groupes de composants en mode conception.
Elles se situe entre le TForm et le TPanel, un bon compromis dans ces cas la.

Si tu arrive a definir une serie de frames types (moins de 10 a mon avis) il serait bien de les developper sous des TFrames crees et positionnés dynamiquement.

Sinon le mode conception est a exclure.
et la creation en mode execution des groupes des composants (frames) peut se faire au travers de TPanel. Les TFrames ne sont pas d'uen tres grande utilitée dans ces cas la.

Si tu as peu de types, tu peux aussi deriver un TPanel contenant en private les composants necessaires et proposer une serie de methodes/property pour le parametrer.

Personellement je prefere toujours la derniere solution

Sinon ile ne te reste plus que la creation de chaques composants dynamiquement

Note : 100 frames sur une seule form ?!? avec au moins 2 compos, sinon ca sert a rien de faire une frame c'est pas un peu lourd ?
Tous les affichages sont ils necessaire en simultané ?
Parce que dans ce genre de cas, on peut opter pour une serie de TFrames stayontop que le client affiche au choix, etn fonction des criteres a surveiller.

[ALWEBER]

Effectivement le TPanel est beaucoup mieux adapté à ton problème.
La solution MDI avec ses childs est aussi possible.
Il est vrai qu'avec une centaine de fenêtre l'utilisateur final risque d'être un peu perdu. Il peu être interessant de filtrer les fenêtres à visualiser.

[Clorish]

La solution MDI avec ses childs est aussi possible.

LA version MDI est desormais deconseillée.
Borland continue a supporter cette technologie pour des raisons de maintenance d'anciennes application mais ne la fait plus evoluer.
D'ailleur toutes les application comerciales de grande renomée sont passe de la version MDI a une version a base de panels

[rvzip64]

J appote un peu plus de détail a mon poblème.

En fait je ne veux pas faire 100 fenetre utilisateur différente , mais faire un style de page dans une scrollBox.

Pour avoir un exemple qui si apporte , c est un peu comme le forum, chaque message d'un utilisateur serait une frame, et la suite de frame serait dans une scrollbox pour voir la chronologie... (c'est un exemple un peu rapide je ne veux pas refaire un forum )

J'ai fait quelque essai, et le simple fait de mette 100 panel dans une scrollbox avec la propriété align:=altop, cela prend plusieurs secondes.

C'est trop long ...

[Clorish]

Pour avoir un exemple qui si apporte , c est un peu comme le forum, chaque message d'un utilisateur serait une frame, et la suite de frame serait dans une scrollbox pour voir la chronologie... (c'est un exemple un peu rapide je ne veux pas refaire un forum )

J'avais bien compris

J'ai fait quelque essai, et le simple fait de mette 100 panel dans une scrollbox avec la propriété align:=altop, cela prend plusieurs secondes.

C'est trop long ...

Tu m'etonnes ....
D'ailleur regarde : meme les forums sotn limité a 20 messages maximums par page (dans le meilleur des cas)

Je te conseille de faire de la meme maniere : Decoupe ton affichage en pages
Apres il faut choisir entre un affichage rapide (peut de données) ou long (l'ensemble des données est necessaire).

Autre chose : Ca m'etonnerais que tu puisse afficher toutes tres frames/panels sur le meme ecran (a moins d'avoir un 2000" ).
Donc tu peux baser ton affichage a N Frames/Panels : uniquement ceux qui sont visible.
LA creation dynamique des panels se faisant en temps reel au fure et a mesure de l'affichage des données.
Il te faudra pour ca te passer de ta scrollbox et la remplacer par un PAnel, avec une scrollbar que tu parametrera convenablement.

Tu peux aussi baser ton affichage sur 2, 3 ou 4 frames seulement, statiques, et scroller le contenu. c'ets a dire que la frame1 contiendra les données 1 puis quand on scroll on y affiche des donnée N+1 ou N-1.

[rvzip64]

L'idée est pas mal.

T'aurais un bout de code pour que je vois ce que cela peut donner ?

[Clorish]

Oula !
pas trop C'ets assez specifique comme code

LE principe est surtout de tester les prop top et bottom = top+height.
Si bottom < 0 alors la fenetre n'est plus visible, on la detruit.
Si Top > ClientHeight alors la fenetre n'est plus visible, on la detruit.
Si Top > 0 alors on peut afficher une 2e frame/panel. On la creer on la rempli avec les champs de l'id correspondant.
Idem si Bottom < ClientHeight

Ensuite la scrollbart party de 0 a NbFrames*FrameHeight et quand on scroll on declae les frames visible (TObjectList) de Delta.
Soit on part de 0 a NbFrames-1 et on decale de FrameHeight.

Ca c'ets pour la version dynamique.
Pour la version statique, suffit juste de garder l'id du premier element affiche en memoire et afficher Id->Id+N dans les frames correspondantes.
La scrollbar allant de 0 a FrameCount-1 indique l'id du premier element de la liste affichée.

Personellement j'opterais pour la 2e methode.
On peut meme simplifier encore en fixant le nombre de frames affichées a 1 avec une listbox ou une combobox pour selectionner les frames (un mousewheele sur la liste ou la combo change automatiquement la selection comme un scroll)

[ALWEBER]

En complément de cette idée tu peux jouer sur la propriété visible des panels.
Je te joint un petit programme qui te montre comment gérer une liste d'objets visuels. Tu peux remplacer la TListBox par un TStringList. Sur l'exemple tu peux déplacer les images avec la souris.

[Clorish]

En complément de cette idée tu peux jouer sur la propriété visible des panels.

Jouer sur la property Visible revient a posseder une isntance de chaques frames, donc forcement passer par un certain temps de creation.
Le deplacement aussi aura un cout plus important (mais surement negligeable sur une centaine d'element).

L'idee d'opter pour une creation dynamique est de n'avoir pas plus de 3 creation au demarage suivi de 1 creation au maximum par deplacement.
Donc gain de temps.

Une autre solution reviendrais a threader la creation en arriere plan ... mais comme on passe par du traitement sur la VCL, la version Threadée sera plus delicate a mettre en place ....

On peut peut etre passer par des messages .... une boucle parcourant les 100 elements a afficher et lancant successivement 100 messages de creation de frames sur un ID precis.
La pile se remplit et Delphi gere la creation de maniere autonome sans bloquer l'applciation.

[rvzip64]

Woaw ... et comment tu fais le truc avec les messages ???

[Clorish]

Woaw ... et comment tu fais le truc avec les messages ???

Oula ..... je te conseille plutot d'aller voir les tutos et cours du site


Mais grosso modo, il te faut creer une constante message WM_MonMessage et (si je ne dit pas de betise) un type record qui defini les champs de ton message.

Apres, tu utilise les fonctions SendMEssage ou PostMessage pour envoyer ton message.

Enfin, tu definie une procedure associee au message (directive message) qui sera executee lorsque le message sera recut par l'objet.

Je ne sais pas si c'ets important, mais une surcharge de la methode wndproc permet de traiter les messages au sein d'un objet ....

C'ets pas tres compliqué mais comme tout technique, il faut y consacrer du temps pour la comprendre et un peu de pratique pour la maitriser
Choses que je n'ai pas encore eu le temps ou le besoin de faire

[rvzip64]

Et en quoi cela pourrait accélérer le traitement ??? je serais toujours obligé de créer l'ensemble de mes frames , non ?

[Clorish]

Et en quoi cela pourrait accélérer le traitement ??? je serais toujours obligé de créer l'ensemble de mes frames , non ?

Accelerer ... non.
Ca le ralentira meme peut etre un peu car entre 2 creation, Delphi effectuera d'autres actions.

Cela permet jsute de rendre la creation parallele a l'execution.
Donc pendant que l'utilisateur cotinue d'utiliser le logiciel, la creation se fait en tache de fond.
Bien que je prefere les threads, c'ets une alternative interessante.

[Rayek]

Est ce qu'un foncitonnement de ce style (voir image) ne serait-il pas mieux pour ce que tu veux faire

[rvzip64]

L'idée du grile capable de gérer cela , en effet ce n'est pas bète, mais ça ipose pas mal de contrainte puisque que je ne suis plus libe de faire des frames différentes, et que a mon avis il y a moins de liberté de 'création'.

[Clorish]

l'idee des frames n'ets pas une mauvaise idee en soit.
Ta solution reside dans le traietement des frames non visible.

Qual interet d'avoir plus de 90% de ses frames cree invisible.
C'est 90% du temsp d'execution perdu pour rien.

Soit tu les crees dynamiquement au fure et a mesure des besoins, soit tu lance la creatio ndes frames invisible en parallele de l'execution de la form, de facon a ce que le programme ne soit pas bloqué par la creation des frames invisible.

[rvzip64]

Je suis entièrement d'acord avec toi !

Pas besoin de me rapeler qu'il y a X% des frames qui ne seront pas visible, je le sais , et c est pour cela que j ai mis un post sur le forum , pour vous demander votre avis.

Maintenant faut me comprendre, j'essaye de trouver la technique la meilleure

Soit j'utilise des theads, mais ça me semble compromis, vu que je vais avoir accés a la VCL principale et donc il va falloir utiliser du synchronize. Donc l'interet est nul.

Soit j'ai la méthode des messages, mais la je vois meme pas par ou commencé, et je met pour le moment un doute sur le fait que ça effectue des taches en parallèle. meme si c est le but des messages je suis pas sur que lors de l'interception par l'object créateur ça ne bloque pas l'appli, va falloir surement glissé du application.processmessage par là.

Soit j'ai la technique des grille,s il me semble que c est trop restrictif, par contre eux, il arrive a creér X 'ligne' ou bloc d'image, en un éclair (comment ils font).

Et aprés il me reste une méthode assez obscure qui consiste a utiliser le DockManager de la scollBox,mais je n'y connait rien du tout.


Donc je ne vois qu en solution, Ami du forum si vous etes:

Pour le thread vous tapez 1
Pour les messages vous tapez 2
Pour la grille vous tapez 3
Pour le DockManager vous tapez 4

[Clorish]

Maintenant faut me comprendre, j'essaye de trouver la technique la meilleure

halala .... toujours cette recherche de LA Solution

Soit j'utilise des theads, mais ça me semble compromis, vu que je vais avoir accés a la VCL principale et donc il va falloir utiliser du synchronize. Donc l'interet est nul.

Je ne vois pas en quoi l'usage de synchronize pose des problemes ?
Cela permet juste d'eviter que le thread modifie des objets pendant que le thread principal les manipulent ...

La classe principale propose de maniere publique une (ou plusieurs) methode de creation de frames et le thread les appellent de maniere synchronisé.

Bien sur, seul l'appel a la creation d'uen frame sera synchronisé et non l'ensemble de la boucle ....

Soit j'ai la méthode des messages, mais la je vois meme pas par ou commencé, et je met pour le moment un doute sur le fait que ça effectue des taches en parallèle. meme si c est le but des messages je suis pas sur que lors de l'interception par l'object créateur ça ne bloque pas l'appli, va falloir surement glissé du application.processmessage par là.

LE principe de gestion des messages reside dans sa pile d'appel.
Ils sont stocké dans une FIFO et sont traités par ordre d'arrivée.
LE tout est de les envoyer dans la file en laissant le temps au systeme d'y intercaler ses evenements a lui.

Au pire tu peux toujours lancer l'evenement suiovant en fin de gestinnaire de l'evenement precedent ....

Soit j'ai la technique des grille,s il me semble que c est trop restrictif, par contre eux, il arrive a creér X 'ligne' ou bloc d'image, en un éclair (comment ils font).

La je suis d'accord avec toi .. bien que chercher a trop rendre generique complique bie nsouvent plus que cela ne rapporte.

Et aprés il me reste une méthode assez obscure qui consiste a utiliser le DockManager de la scollBox,mais je n'y connait rien du tout.

Moi non plus

Pour le thread vous tapez 1
Pour les messages vous tapez 2
Pour la grille vous tapez 3
Pour le DockManager vous tapez 4

On peut tapper Nikos ? depuis le temps que j'en reve !!
Bon allez ... je vote 1

[ALWEBER]

Z'etes nuls les enfants regardez comment fonctionne la grille sur une fiche Paradox et vous aurez la réponse à votre problème d'une manière totalement simple. Sur cet objet, il n'y a de frames/panels que les frames/panels visibles. Le résultat est immédiat et nul besoin de thread.