Améliorer le composant dbGrid
Bonjour,
Je travaille toujours en parallèle de mes développements... sur les composants.
En code "classique" (ie utilisateur de Lazarus), j'ai peaufiné un peu une dbGrid pour la trier (Champ principal Asc/Desc + champs secondaires Asc/Desc ) et pour pouvoir faire une recherche dans chaque colonne déclarée triable.
http://www.selzig.com/1008051100/3.png
Pour cela, lors de mon approche en tant qu'utilisateur de Lazarus (mais dans l'optique de pouvoir concevoir ultérieurement un composant), j'ai essayé d'inclure tout le maximum de code possible dans celui de la dbGrid et de ses évènements. Néanmoins, j'utilise un TEdit (que je pensais pouvoir créer dynamiquement et utiliser dans le composant) et deux tableaux qu'il est nécessaire de renseigner (Colonnes triées et formules de tris associées [J'utilise les SortFields et non les requêtes])... Et c'est là que commencent mes problèmes dans la conception d'un composant : je ne comprends pas comment créer ce tableau dans le composant, le rendre publiable (published), pouvoir le remplir et ensuite le mémoriser (en tant qu'utilisateur du composant) et le rappeler pour pouvoir le modifier. Sur une propriété simple, je n'ai pas de problème... mais sur un tableau dynamique... J'ai un autre soucis : je comprends comment modifier une propriété ou un évènement en y ajoutant du code... Mais pour que mon code fonctionne, j'ai besoin d'ajouter à l'évènement de base -et de manière transparente- l'équivalent (en langage "interne" du composant) de mon propre code actuel. Par exemple :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| procedure TFormSDeco.DBGrid1TitleClick(Column: TColumn);
var
sTmp : String;
i, iFound : integer;
begin
// Fermeture du champ de recherche si visible
{ Normalement il se rend invisible, lorsqu'on en sort mais
lorsqu'on clique sur le header,... on n'en sort pas ! ...}
if EdSEARCH.Visible then EdSEARCH.visible := false;
//Renversement du sens de la colonne si déjà dedans
//Récupération du FieldName de la colonne cliquée
sTmp := DBGrid1.Columns.Items[DBGrid1.Columns.IndexOf(Column)].FieldName;
[...] |
Comment fait-on cela ? Travailler sur (avec) les éléments de la Grid, je m'en sors mais pour le tEdit, l'utilisation de ses propriétés et de ses évènements, là, je "buggue" complètement. Est-ce que cela suppose que je le déclare mal, ou que l'approche est foncièrement techniquement mauvaise ?
Bref, j'ai réalisé sous forme pdf une description complète du code actuel...
http://www.selzig.com/1008051100/2.png
Je peux terminer également en parallèle une petite "démo" en SQLite3 avec les composants natifs -à l'origine j'utilise Zeos- (peut-être un prob. de portage avec le nom des propriétés des DataSet... Je connais mal ceux des SQLxxx). Démo que j'accepte volontiers de mettre à disposition... en espérant qu'un "spécialiste composant" veuille bien partager son savoir ou qu'un "apprenti en composant comme moi" veuille bien s'associer afin d'au moins faire progresser cette ébauche de composant.
Il n'y a pas urgence car je travaille actuellement à rectifier une approche identique (pas comme composant) en StringGrid. Je reprends un vieux code 0.9.26 que j'avais abandonné et qui corrigeait partiellement l'impossibilité de gérer des colonnes invisibles et dans lequel le tri et la recherche sont intégrés. Mais, il requiert beaucoup trop d'évènements de la Form (et non du StringGrid lui-même) et de plus il est très emmêlé avec les "rustines"...
Par contre, niveau timing, s'il n'y a pas d'urgence, j'ai quand même une contrainte forte : j'aimerais me faire un avis (possible ou pas) avant la fin des vacances scolaires. La rentrée de mes chers élèves va évidemment me rendre moins disponible et de ce fait, 'diluer' ce travail... Y a-t-il quelqu'un(e) volontaire pour le DBGrid?
Cordialement. Gilles
