Discussion :

[SergioMaster]

Bonjour,

toujours sur mes listes, je suis en train de comparer ListBox et ListView. L'objectif savoir ce qui ferait choisir l'une plutôt que l'autre

1. déjà il y a une question de Style.
2. de mode de remplissage, puisque l'on n'accède pas de la même manière aux zones (texte ou autre)

ListBox permet utilise des styles pour les items donc, on peut en créer d'autres. ListView autorise un style dynamique
ListBox permet d'ajouter des objets dans un item, Listview je n'ai jamais tenté (à voir)

J'en viens à ma question principale : avez-vous vu d'autres arguments dans le match ?

Dans le cadre de mes essais, en liaison avec des tables cf le dernier billet de mon blog, j'ai également découvert la collection FillBreakGroups. Si j'arrive à la faire fonctionner c'est uniquement s'il n'y a pas synchronisation est-ce un bogue à soumettre ?

[Paul TOTH]

je ne sais pas, mais si tu as vu ma dernière vidéo sur le portage d'un appli VCL vers Android, tu verras que j'ai choisi d'empiler des TFrame dans un VerticalScrollBox

cela permet de créer des "listitem" dans le TFrame assez facilement, ça n'aide pas pour LiveBinginds sans doute, mais comme je travaillais sur un WebService qui me retourne une liste d'éléments c'était assez pratique.

[SergioMaster]

je ne sais pas, mais si tu as vu ma dernière vidéo sur le portage d'un appli VCL vers Android, tu verras que j'ai choisi d'empiler des TFrame dans un VerticalScrollBox

Bonjour Paul,

Non, je suis en visionnage (dans mes temps libres) de tout ce qui concerne les styles (avant le reste) dans la playlist proposée Coderage 2019 Firemonkey Multi-Device Design et n'ai pas eu le temps de regarder ta vidéo.
Il y a de multiples solutions pour faire les listes (dont la tienne), tu remarqueras d'ailleurs qu'un TListbox n'est qu'une "déclinaison" d'un ScrollBox, les Items étant un "équivalent" de Frames (le style est "la frame")

[Edit]
Bon finalement, curieux comme toujours, j'ai regardé ta vidéo. Perso, mais je n'ai pas vu ta couche métier je pense que tu aurais eu moins de codification à faire avec un TListBox ou un TListView et un peu de LiveBindings
j'aurais certainement penché pour un TListview avec une apparence dynamique qui aurait été plus facile à lier (en gros tu as quatre objets texte pour les documents d'un patient) cerise sur le gâteau tu aurais pu inclure une recherche de document directement dans cette liste Tout cela sans un seul caractère de code
Après, l'incidence des LiveBindings sur les temps d'exécution et tutti quanti ce serait un autre débat

Je retiens surtout de ta vidéo les actions pour les enchainements, c'est un composant (TActionList) que j'ai du mal à intégrer (en fait je n'y pense pas ), peut-être que ta vidéo va m'y faire penser plus souvent

[SergioMaster]

Cela permet de créer des "listitem" dans le TFrame assez facilement, ça n'aide pas pour LiveBindings sans doute

Ayant avancé dans mes visionnages, j'ai vu que Adriano Santos avait lui aussi opté pour une solution ScrollBox+Frames pour pouvoir utiliser des threads
Alors que Frank Lauter, "allergique" au concepteur de liens comme de style, se faisait ses propres listes sans passer par les styles (Fluent Creation)

Du coup, je me pose des questions "existentielles" genre "À quoi cela sert qu'Embarcadero il se décarcasse ?" Ou, plus sérieusement, comment est-ce que cela fonctionne vraiment quand une liaison avec une source de données est établie ? Est-ce que cela passe (ou passera) par des threads ?

L'idée d'un match ListBox/Listview lié par Livebinding serait à élargir à ScrollBox+Frame vs Style vs Construction au Runtime liés par code. Gros chantier !

Pour mon dernier point soulevé

Dans le cadre de mes essais, en liaison avec des tables cf le dernier billet de mon blog, j'ai également découvert la collection FillBreakGroups. Si j'arrive à la faire fonctionner c'est uniquement s'il n'y a pas synchronisation est-ce un bogue à soumettre ?

Je ne sais toujours pas quoi en penser, j'ai testé avec 3 versions différentes avec toujours la même problématique, je ne sais toujours pas si c'est censé fonctionner ou pas En effet la synchronisation fonctionne si le groupement se fait dans le cas de groupement "simple" (la colonne sert de Header) ce n'est qu'en cas de groupement "particulier" que se pose le problème

J'ai, toutefois, trouvé un moyen de contourner la difficulté du manque de synchronisation en utilisant ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
// ListGroup n'est pas synchronisée
procedure TMainForm.ListGroupItemClick(const Sender: TObject;
  const AItem: TListViewItem);
var i,rec : integer;
begin
rec:=0;
// recherche du numéro d'enregistrement
// on ne peut pas utiliser ItemIndex à cause des groupes 
// à améliorer : si pas de groupe alors rec:=AItem.index
for i := 0 to AItem.Index do
  if ListGroup.Items[i].Purpose=TListItemPurpose.none then inc(rec);  // uniquement les lignes 
ClientDataSet1.Recno:=rec;  // se positionne 
// TabControl1.Next(); // traitement quelconque, ici affichage détail dans un onglet
end;

Cela me laisse quand même un arrière goût de "non finalisé".

Bogue or not bogue that is the question

[SergioMaster]

Bonjour,

Ce matin, j'ai voulu en avoir le cœur net, un match triple chronométré entre TListView, TListBox (ces deux derniers étant liés par LiveBindings) et TVerticalScrollBox.

Le ring : un même PC qui interroge une base de données (Firebird) en réseau local.
La compétition : combien de temps pour mettre n éléments dans la "liste"


Les résultats sont surprenants, au temps pour les détracteurs des Livebindings ou des Styles

ScrollBox avec Thread Alignement Altop utilisé Temps : 11449
ScrollBox avec Thread Position calculée Temps : 1641
ListView sans thread Temps : 302
ListView avec thread Temps : 541
ListBox sans thread Temps : 131
ListBox avec thread Temps : 1351

Cela écrit, je suis conscient qu'il faudrait un échantillon plus complet et faire des moyennes mais, d'une manière générale remplir de façon manuelle est plus long.
Et, oui, il y a un loup, Livebindings augmente la taille du programme (RTTI Oblige)

Note : vous remarquerez une astuce qui diminue énormément le temps pour remplir un ScrollBox, le calcul de la position plutôt que l'utilisation de l'alignement
cette astuce est fournie par Jaques Nascimento (Imperium Delphi)
P.S. Utilisez les sous-titres si le portuguais n'est pas votre langue de prédilection

Je vous fournirais bien le source mais, comme il utilise une base de données locale il serait sans intérêt pour tests. Je vais donc transférer la table vers SQLite avant de fournir le Zip
J'en profiterai pour ajouter diverses possibilités pour créer l'élément du ScrollBox : via un Frame (technique de Paul et de Adriano Santos à retrouver ici) , via un Rectangle préparé et cloné (une autre astuce de Nascimento)

[Paul TOTH]

tu peux aussi utiliser TPrototypeBindSource

[SergioMaster]

Bonjour,

J'y ai évidemment pensé mais je l'utilise trop et voulais quelque chose plus orienté BDD.
Je me suis même posé la question de générer environ 1000 enregistrements avec TProtypeBindSource pour ensuite les mettre dans une table SQLite (et ce avant de partir déjeuner chez des amis) mais je butte sur la méthode à employer pour récupérer les colonnes dans ce TProtype, pas de BatchMove possible j'en suis resté là hier.
[Edit] ça y est, j'ai (re)trouvé le moyen (basique) de remplir une table à partir du TProtypeBindSource

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Proto.First;
while not Proto.EOF do
begin
  FdTable1.Insert;
  fdTable1.FieldByName('DateFacture').AsDateTime:=Proto.DataGenerator.FindField('DateField1').GetTValue.AsType<TDateTime>;
  fdTable1.FieldByName('NomClient').AsString:=Proto.DataGenerator.FindField('ContactName1').GetTValue.AsString;
  fdTable1.FieldByName('Montant').AsCurrency:=Proto.DataGenerator.FindField('CurrencyField1').GetTValue.AsType<Currency>;
  FdTable1.Post;
  Proto.Next;
end;

J'ai donc maintenant une BDD SQLite pour remplir mes listes, yapluka

[ALWEBER]

Je pense que P.BeginUpdate et P.EndUpdate peuvent accélerer le processus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
procedure TForm75.CreerCarte(const P : TVertScrollBox; const T,D : String; const N : Integer=0);
Var
  F : TFrameCadre;
  R : TRectangle;
  L : TLabel;
Begin
{$REGION '  Tout créer   '}
P.BeginUpdate ;
if rb1.IsChecked then
 begin
    R             := TRectangle.Create(Nil);
    R.Parent      := P;
    R.Height      := 68;
    R.XRadius     := 8;
    R.YRadius     := 8;
    if N=0 then begin
                    R.Position.Y := 500000;
                    R.Align      := TAlignLayout.Top;
           end
           else begin
              R.Position.Y := 70 * (n-1);
              R.Width := P.Width-20;
           end;
    R.Margins.Top := 4;
    R.Fill.Color  := TAlphaColorRec.Whitesmoke;
 
    L         := TLabel.Create(Nil);
    L.Parent  := R;
    L.Align   := TAlignLayout.Top;
    L.Text    := T;
    L.Margins := TBounds.Create(TRectF.Create(8,4,8,0));
 
    L         := TLabel.Create(Nil);
    L.Parent  := R;
    L.Align   := TAlignLayout.Top;
    L.Text    :=D;
    L.Margins := TBounds.Create(TRectF.Create(8,4,8,0));
 end;
 P.EndUpdate ;
.../...
end;

[SergioMaster]

CreerCarte ne crée qu'un seul élément, s'il devait y avoir BeginUpdate et EndUpdate ce serait dans l'appel des procédures
btnScrollboxClick et btnScrollBoxThreadClick, je m'en veux de ne pas y avoir pensé alors que dans mes premiers essais j'utilisais cet encadrement de bloc.
D'un autre côté VertScrollbox étant invisible lors du remplissage c'est la raison qui m'a fait ôter ces instructions ... à vérifier

[ALWEBER]

effectivement !!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
VertScrollBox1.BeginUpdate ;
while not FDQuery1.EOF do
 begin
   Inc(rc);
   CreerCarte(VertScrollBox1,
                  FDQuery1.FieldByName('DateFacture').AsString,
                  FDQuery1.FieldByName('NomClient').AsString,
                  IfThen(ChkCalcPos.IsChecked,rc,0));
   FDQuery1.Next;
 end;
VertScrollBox1.EndUpdate ;

[SergioMaster]

Et, même invisible, il fallait le faire
voici les résultats

ScrollBox sans Thread Alignement Altop utilisé Temps : 25
ScrollBox sans Thread Alignement Altop utilisé Temps : 35
ScrollBox sans Thread Position calculée Temps : 17
ScrollBox avec Thread Alignement Altop utilisé Temps : 87
ScrollBox avec Thread Position calculée Temps : 52
ListBox sans thread Temps : 12
ListBox avec thread Temps : 52
ListView sans thread Temps : 7
ListView avec thread Temps : 42

Le remplissage sans livebindings (scrollbox) n'est donc qu'environ 2 fois moins rapide
Je pense que j'ai un problème avec le calcul des temps car le thread est plus lent que le Livebindings simple, les temps étant tellement cours l'animation n'apparait même pas

Reste que :
- les listbox et listview liés permettent de se positionner directement sur l'enregistrement (synchronisation),
- ListView permet de mettre une "barre de recherche" très facilement mais Listbox permet d'utiliser des styles (qui, si vous regardez d'un peu plus près ressemble beaucoup aux frame et rectangle cloné
sans compter que ListBox peut mettre le défilement en horizontal (soit un équivalent HorzScrollBox)
- ListBox permet de mixer plusieurs styles et ajouter presque n'importe quel composant visuel

En tout cas l'astuce de calculer la position plutôt que d'utiliser l'alignement est à garder en mémoire

Maintenant il y a la question de limite raisonnable entre Listbox et listView