[0.9.28.2] DbGrid améliorée

Bonjour,
je cherche à améliorer les dbGrids fournies par Lazarus (mais sans réaliser de composant).
http://www.selzig.com/1001291441/dbgrid.jpg

J'ai 2 problèmes de savoir-faire liés à la gestion des en-têtes des colonnes :

1. Existe-t-il un moyen de différencier le DoubleClic d'un simple Clic sur un en-tête autrement que par la méthode du chronométrage de l'intervalle entre les 2 clics ?
2. Comment peut-on inclure un TEdit dans un en-tête (exemple champ de recherche) ?

Dans les 2 cas, le principe me suffirait.
Cordialement. Gilles

J'en étais au même stade que toi jusqu'à ce que je découvre KGrid :)
pour le double-clic aucune idée , par contre pour le TEdit j'avais fait une 'ligne fixe supplémentaire' . Si cette piste t'intéresse je rechercherai mes essais 8O (plus que légèrement laissé de coté , j'avoue que j'hiberne un peu en ce moment)

Bonjour SergioMaster,

J'ai étudié de près le code de la StringGrid de KGrid pour résoudre le problème des colonnes invisibles dans celles fournies par Lazarus. Je n'ai pas regardé le code de la dbGrid de KGrid.

Sans rapport directement avec mon problème actuel, pour la StringGrid, le composant KGrid ne résolvait pas entièrement mon problème. J'ai d'ailleurs laissé tomber Lazarus à ce moment -"dû laisser tomber" serait une formulation plus exacte-, après 2 mois d'examen "intensif" du code en me rendant compte que pour le résoudre, il me fallait remonter 2 crans d'héritage ce qui impliquait qu'une correction modifierait le comportement des dbGrids... Bref tout simplement injouable pour l'utilisation que je fais (voulais faire) de cette plateforme : son développement "ancestral", son socle manquent de cohérence (pas seulement pour les StringGrids car on peut ajouter la gestion de l'UTF-8) et ne semblent pas évoluer d'une version à la suivante...
Petite remarque : les StringGrids de KGrid donnent satisfaction sous Delphi (mais les StringGrids natives aussi). Comme elles sont développées de manière parallèle, cela conforte mon analyse.

Maintenant en rapport avec mon problème actuel, l'utilisation de composants Lazarus venant de "l'extérieur" n'est pas trop envisageable à mon niveau : il n'y a qu'à regarder le nombre de composants Lazarus "externes" en jachères. Si dans une application, on doit en plus de son code, maintenir les composants...
Remarque : l'utilisation en Delphi de composants externes ne me posent pas de problème : il y a toujours une alternative, un choix important de composants de qualité, et une réactivité de bonne "augure". Ce qui plaiderait plutôt en faveur de KGrid... mais si KGrid n'est plus maintenu, les solutions de substitution ne manquent pas sous Delphi. Mais en Lazarus ?
Donc KGrid pourrait être éventuellement "une source d'inspiration" comme on dit. Mais je n'aime pas trop la méthode.

Pour en revenir à ma question initiale :
Pour le 1), j'ai déjà une solution satisfaisante mais lourde avec le chronométrage... (idem à la solution Delphi d'ailleurs)
Pour le 2), en dernier ressort, jexaminerai le code des dbGrids KGrids pour voir comment le problème a été traité. Je n'avais pas pensé à l'idée d'une ligne supplémentaire dans la dbGrid (de prime abord, j'aurais supposé cela impossible) mais par contre j'ai essayé de gérer des TEdits externes. On rencontre rapidement 2 problèmes : la gestion du focus (entre le TEdit et la dbGrid) surtout si on fait des recherches génériques sur les colonnes, et la position du TEdit notamment en cas de modification de la taille de la Form ou de celle des colonnes (mais à ce niveau là, je n'en suis pas loin....)

Enfin, ce n'est pas le sujet, mais j'en profite : pour les StringGrids, j'ai résolu le problème sans modifier les héritages (en utilisant soit une autre StringGrid d'appui, soit des StringLists). Maintenant pour réaliser un composant, j'avoue mon ignorance sous Lazarus d'autant que j'utilise presqu'exclusivement des librairies dynamiques [ne serait-ce que pour un problème de portabilité entre divers langages]. Mais comme je l'ai déjà affirmé sur ce forum : si quelqu'un a un peu de temps (et des connaissances en matière de création de composant Lazarus), on peut essayer de la "composantifier"... histoire de montrer qu'on peut rester critique à l'égard de Lazarus en utilisation professionnelle (et de la perennité des composants développés), et pourtant l'apprécier à titre personnel (Pas Lazarus en tant que tel mais la possibilité qu'il représente d'utiliser Pascal et un IDE à la Delphi avec la portabilité Linux)... Et aussi histoire d'apprendre et de rester curieux.

Bon WE. Cordialement. Gilles