Avis sur DevExpress

Bonjour,

Nous nous apprêtons à mettre à jour (mise à jour majeur) nos logiciels. Pour ces nouvelles versions, nous aimerions adopter un style Office 2013, étant donner que nos versions actuelles utilise le ruban Delphi, qui est une copie du ruban Windows 2007.

Après renseignements sur internet, je me retrouve avec deux fournisseurs de composants ayant développé ce ruban : DevExpress et TMS Software.

Que pensez vous de ces 2 fournisseurs de composants ? Des utilisateurs réguliers ?

De prime abord, je pense plus me tourner vers les composants de DevExpress, qui, il est vrai, ont l'air de fournir une palette importante de composants. Un d'entre eux me fait de l’œil, leur super Grid "QuantumGrid". C'est vrai qu'elle à l'air vraiment pratique. Quid de l'utilisation? Et surtout des performances ? Quelqu'un a fait des test ? Utilité du module de multi-langage ? D'impression ?

Je vous remercie d'avance pour les éclaircissement que vous pourriez me faire sur ces 2 fournisseurs,

Florian

J'ai pratique les deux

DevExpress en 2004 à l'époque de la TdxDBGrid
On faisait des jolies choses en D7
étant le seul développeur devant maintenir du D3 à cette époque,
j'ai appris à faire la même chose manuellement pour certains trucs :mouarf:
Très formateur !

TMS en 2007
J'ai même proposé des codes sources corrigés à TMS,
Sans le savoir, j'exploitais des bugs :ptdr:
c'est dur lorsque tu changes de version et qu'il est corrigé !
Un peu lourd, interaction louche sur les lookup combo

Cela date tellement que mon avais n'est pas très utile
Sauf pour les composants Smooth, juste pour changer l'affichage faut changer le compo !
C'est une approche pas terrible, avec l'évolution des styles VCL,
je suppose que TMS a proposé autre chose

Je ne peux pas en dire plus,
je ne peux plus comparer un TMS datant de 2006 avec le Dev Express de 2012

DevExpress 12 sous XE2
Je trouve que la TcxGrid et la TcxTableView sont compliqués !
Comme je me suis fait mes propres assistants graphiques pour la TDBGrid que j'ai corrigé pour gérer les styles,
j'ai de grosse difficultés à m'y mettre !

structure des objets/properties alambiqués à la limite de l'anti pattern "Abstraction inverse",
on a plus l'impression d'avoir un portage C# sur Delphi qu'une lib pensée pour Delphi
dans la version que j'ai, j'ai trouvé des incompatibilité entre des éléments de base de la RTL
en particulier le DisableControls qui peut faire planter les grilles si l'on veut protéger contre les affichages inutiles,
il faut utiliser à la place leur système de BeginUpdate (ultra lourd)
Même soucis pour le Bookmark, tu plantes la multi-selection dans certains cas avancés de fitre
C'est peut-être des bugs corrigés depuis mais j'ai la version 12.1.6 sur mon poste,
et mon collègue maintient encore pour quelques mois une appli qui ne fonctionne correctement qu'avec la version 12.1.3 !
:roll:

un truc fortiche et très utile, c'est le système de niveaux,
ça c'est très utile pour fournir à l'utilisateur un écran pour retrouver facilement ce qu'il cherche en gérant des hiérarchies de données
Après cela dépend du métier cible

Si tes utilisateurs aiment EXCEL, alors tu adoreras DEV EXPRESS !
Car tu pourrais faire des grilles ultra puissantes avec plein de d'option d'affichage, de filtre ...
Certains utilisateurs seront des pénibles, ils aiment Excel du coup, il préfère un export sur Excel, joué de dessus que d'utiliser ta superbe grille ! :lol:

L'utilisation de Footer et des totaux !
J'ai pas eu le temps d'approfondir mais c'est un piège !
L'utilisateur, il adore avoir des totaux et c'est si facile dans la grille que tu oublies vite les bonnes pratiques DB !
On utilise ODAC en Partial Fetch (25 par 25 rec) mais comme la grille pour faire ses totaux balaie le DataSet
et que l'on a une DB des tables avec des centaines de millions d'enreg et des stats ultra complexes qui peuvent renvoyer plus de 100 000 lignes (oui inutile, illisible mais l'utilisateur il aime va savoir pourquoi)
En ajoutant des progressions pour faire patienter l'utilisateur durant le Fetch
je me suis rendu compte qu'en fonction des options de la grille, cela balaye 2, 3 voire 4 fois tout le DataSet,
le 1er balayage faisant le Fetch, cela ramène un tas de données (occupation réseau, cPU..., RAM) ce qui peut prendre 10-15 minutes !

J'ai du coup ajouté un mode visualisation rapide sans les totaux (ni les filtres façon Excel dans les colonnes qui consomment du fetch aussi) via une simple TDBGrid
Résultat en 1 à 10s, ensuite l'utilisateur, le temps qu'il défile ou utilise les champs de recherche, il se rend moins compte qu'il accumule du temps et donc des données !


Si j'ai le temps, je ferais un système pour mettre le calcul des totaux en thread !
Je n'ai pas le niveau suffisant pour corriger des script SQL de plusieurs centaines de lignes qui utilisent 20 tables (et les plus grosses évidemment),
surtout qu'il suffit que notre admin DB patch Oracle pour que les directives Oracle ne fonctionne plus ou empire les performances qu'elles avaient améliorés un temps

J'ai un développement, ou je pourrais proposer de toute nouvelle stat lié à un tout nouveau flux !
Au moins, au début, ça sera rapide car les données seront peu volumineuse à peine 10 000 nouvelles lignes par heure :mouarf:
Et je pourrais purger au fur et à mesure puisque la durée de vie de la données sera au pire d'un mois : 2 millions de lignes dans la plus grosse table de ce nouveaux flux, ça le fera tranquille


DevExpress
perso, j'arrive à m'en passer dans mes modules, à part le tri sur colonne, la couleur, la recherche, on utilise pas grand chose qui n'ai pas faisable en Delphi en se faisant de petits assistants (moi je traine les même depuis plus de 10 ans)
Lorsque j'arrive au limite de la TDBGrid, je propose un bouton exporter sur Excel (ça aussi vieux code d'export de DataSet)
l'utilisateur adore bricoler sur EXCEL et ça m'évite de me prendre la tete avec la TcxGrid !






sur un écran d'un module massivement utilisé, il y a :
- une TcxGrid en lecture seule (Dev Express)
- une TtsGrid pour la saisie en masse (TopGrid ObjectSight)
Il semblerait que pour la saisie la TcxGrid n'ai pas convaincu mon prédécesseur

Sur l'écran suivant
- une TcxGrid en lecture seule (Dev Express)
- une TDBGrid en lecture seule (VCL)

Dans d'autres, on a aussi des composants RX Lib, Jazmine ... chacun avec un grille ! :weird:

J'ai installé Delphi et ODAC sur un Portable, mon module compile et fonctionne ,
ça me suffira pour un déplacement

il me faudrait bien une heure pour trouver tout les composants à installer pour compiler certains modules
je n'ai aucune documentation, faut trouver ce qui manque en compilant les 300 dproj :aie:

Merci pour ces précisions et ces informations.

Au niveau du schéma classique de nos applications, c'est simple. On part d'une grid pour en sortir des formulaire de création, modification, ... C'est le schéma un peu prêt classique de nos applications. La grid est vraiment au coeur de nos applis. C'est le point d'entrée de nombreuses de nos fonctions. Et effectivement, l'utilisation d'Excel fait parti des pratiques courantes de nos utilisateurs.
Je pense donc qu'on va se tourner vers DevExpress ... là où j'ai plus un doute, c'est sur la rapidité de la chose. Je sais qu'on a du basculer nombreuse de nos grid d'une listview a un DataGrid.

Là où DevExpress me parrait plus complet, c'est qu'il intègre plusieurs choses que l'on veut ajouter à nos applis (des grids plus complète, un peu plus de personnalisation, une application multilangue, ...).

Je crois que je vais re télécharger une période d'essai pour poursuite mes tests ...

Citation:

---

Envoyé par ShaiLeTroll

L'utilisation de Footer et des totaux !
J'ai pas eu le temps d'approfondir mais c'est un piège !
L'utilisateur, il adore avoir des totaux et c'est si facile dans la grille que tu oublies vite les bonnes pratiques DB !
On utilise ODAC en Partial Fetch (25 par 25 rec) mais comme la grille pour faire ses totaux balaie le DataSet
et que l'on a une DB des tables avec des centaines de millions d'enreg et des stats ultra complexes qui peuvent renvoyer plus de 100 000 lignes (oui inutile, illisible mais l'utilisateur il aime va savoir pourquoi)
En ajoutant des progressions pour faire patienter l'utilisateur durant le Fetch
je me suis rendu compte qu'en fonction des options de la grille, cela balaye 2, 3 voire 4 fois tout le DataSet,
le 1er balayage faisant le Fetch, cela ramène un tas de données (occupation réseau, cPU..., RAM) ce qui peut prendre 10-15 minutes !

J'ai du coup ajouté un mode visualisation rapide sans les totaux (ni les filtres façon Excel dans les colonnes qui consomment du fetch aussi) via une simple TDBGrid
Résultat en 1 à 10s, ensuite l'utilisateur, le temps qu'il défile ou utilise les champs de recherche, il se rend moins compte qu'il accumule du temps et donc des données !


Si j'ai le temps, je ferais un système pour mettre le calcul des totaux en thread !

---

Bonjour, ShaileTroll,

Je te conseille de regarder le "Server Mode" proposé sur les grilles devexpress...

C'est un mode qui est adapté aux tables contenant des centaines de millier / millions de lignes...

Le principe c'est que les tris, les totaux, etc sont fait coté serveur. C'est en fait la grille qui va faire ses requêtes de manière dynamique. et ne va ramener que le nécessaire. (tu peux tracer les requêtes SQL pour voir la tête qu'elles ont et constaté leur légèreté)

En d'autre terme seule les colonnes et les enregistrements visibles à l'écran sont demandés au serveur (il ramène d'autres info pour notamment gérer correctement la scrollbar mais rien de bien lourd.).
Quand l'utilisateur scroll une autre requête est lancée pour demander la suite. Les totaux sont fait coté serveur...

Bref a première vue ça me parait adapté à ton besoin ;)

Citation:

---

Envoyé par Barbibulle

Je te conseille de regarder le "Server Mode" proposé sur les grilles devexpress...)

---

Je te confirme que c'est ce dont j'ai besoin mais que cela n'existe que sur les objets standard ADO ou DBX
Où je travaille, on utilise ODAC (c'est le choix qui a été fait il y a 10 ans pour remplacer le BDE) et il faut coder soit même la classe d'implémentation du Server Mode
On trouve des exemples pour d'autres lib, à l'occasion je le coderais et le publierais ici