Discussion :

[Invité]

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.


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 :

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

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...


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

[SergioMaster]

J'ai un peu (beaucoup) laissé tombé lazarus mais j'ai moi aussi tripatouillé le DBgrid classique +Zeos (autosize d'une colonne, autosize de l'entete de colonne, zone de recherche etc..) pour le compte de JPNuage (qui se fait rare depuis 6 mois)

avant de découvrir KGrid http://www.tkweb.eu/en/delphicomp/kgrid.html
et également redécouvrir VirtualTreeView

je suis prêt a te faire parvenir ce que j'ai fait à l'occasion

[Invité]

Bonjour,

Merci pour votre proposition.

J'ai un peu (beaucoup) laissé tombé lazarus...

Oui, j'ai failli aussi. Et j'ai regardé un petit peu ce qu'il y avait à côté pour me rendre le même service puisque je "travaille" en permanence sous Win et Nux, OS que j'apprécie autant l'un que l'autre :

• Java : Chouette langage, mais pour l'installation des IDE, je laisse cela aux petits jeunes car pour leur(s) IDE favori(s), mes qualifications "plombier/gazier" sont insuffisantes. "L'assisté" va encore se faire "tancer"...
• Delphi : techniquement trop lié à Windows, je n'y crois pas (plus) pour diverses raisons... d'autant -si j'ai bien compris- qu'un retard est annoncé du fait de la nouvelle version de QT Et d'autre part, je n'accepte pas leur déclinaison du mot "Client" et les rapports induits par celle-ci.
• C++/QT : oui sauf que pour l'instant -il y a peu, disons un trimestre- la version Nux était en retard... sauf que j'apprécie modérément la mise en oeuvre des connexions aux bases telles que mySQL (sous Nux)... et que ce n'est plus du C++ mais du QT... et qu'enfin j'imagine mal développer intégralement une de mes applis dans cet environnement. Manque de savoir-faire et de suivi sans doute...

D'un autre côté, le problème principal de Lazarus, c'est la mauvaise circulation directe des informations. Pour être efficace, l'équipe Lazarus a mis en place une solution qui à mon avis permet en effet de gérer un grand nombre d'informations mais dont le mauvais côté de la "pièce" est un "filtre", un tamisage qui ne relativise pas l'importance des problèmes des utilisateurs, filtre qu'il faut forcer pour obtenir "satisfaction" et surtout se faire entendre. Pendant plus d'un an, à propos des "inacceptables" StringGrids, j'ai maugréé seul dans mon coin... et sur ce forum pensant que ses intervenants pouvaient avoir une quelconque action sur le développement... avant de rentrer directement en contact avec un programmeur juste avant d'abandonner, en dernier recours. Et 1 mois après, et quelques échanges en privé un peu virulents parfois, le problème était réglé.

Enfin, si on compare la technologie Lazarus/Free Pascal et sa LCL multi-OS avec celle de Delphi/Kylix "l'historique" (VCL+CLX) et à défaut peut-être Delphi/QT "la future" (mais IDE Win only et cross-compilation "bientôt" pour production d'exécutables Linux/Mac), il n'y a pas photo quant aux ambitions respectives. Bref, comme je n'ai pas réussi à en convaincre Chris, je crois qu'il faut soutenir Lazarus... d'autant que beaucoup de choses ont changé en bien dans la 0.9.29 notamment la réécriture de certains "parents/ancêtres"...
D'ailleur à ce sujet, j'ai eu un échange significatif avec les Lazarusiens. Il y avait un bug récurrent sur la propriété d'un TEdit. Il a fait l'objet d'une discussion sur ce forum. Le bug était connu en 0.9.26, avait été réglé et était revenu... Comme il a fait l'objet d'une discussion publique sur le bug tracker, j'en copie un extrait :

I've also added delphi compat patch for modified.
Embarcadero docs says:
"Use Modified to determine whether the user changed the Text property of the edit control. Modified is only reset to False when you assign a value to the Text property. In particular, it is not reset when the control receives focus."

Je crois qu'il va falloir que l'Equipe Lazarus s'affranchisse une bonne fois pour toute de Delphi. Lazarus, c'est autre chose. En multi-OS, ils ne sont plus à la poursuite de... Ils sont devant... Et dans cette histoire, le plus "savoureux", c'est que le bug n'existait que sous Nux... (et peut être Mac)... Et Delphi ne sait pas ce que c'est qu'un TEDit sous Nux, enfin il ne sait plus depuis l'abandon de Kylix... Il y a un bond psychologique à réaliser maintenant. Delphi, c'est l'ancêtre de Lazarus, on ne peut le renier [quoiqu'il y ait grande divergence depuis Delphi7/Kylix]... Lazarus n'hérite en rien et heureusement de la suite Delphi 200x. Delphi est toujours un bon IDE Win32... Mais bien que disposant d'une version 2007 ou 5 (je ne sais plus, je ne l'utilise jamais), j'utilise -rarement maintenant- mon vieux Delphi 7 (avec Zeos ).

Si je ne suis pas indiscret, quel a été votre choix de remplacement de Lazarus ?

avant de découvrir KGrid http://www.tkweb.eu/en/delphicomp/kgrid.html

J'avais testé Kgrid (pour les StringGrids) sous Lazarus et Delphi... et sous Lazarus, elle avait les failles de son héritage alors qu'elle fonctionnait correctement sous Delphi.

je suis prêt a te faire parvenir ce que j'ai fait à l'occasion

... En réalité, je suis sûr que c'est digne d'intérêt -et je vous en remercie encore- mais je préférerais travailler avec quelqu'un(e). Le mimétisme est une méthode d'apprentissage parmi d'autres... Elle est pratique et très efficace mais dans ce cas précis, elle ne peut pas me satisfaire : elle manque de "subtilité". On apprend (constate) ce qui fonctionne en passant (très) souvent à côté des subtilités de la démarche qui a mené à la "conclusion exploitable"... Et à terme, on s'en sert mal ou à un faible pourcentage de ses capacités. Comme j'en ai le temps et surtout que je veux mieux comprendre les arcanes de Lazarus pour pouvoir participer efficacement à son développement (je propose déjà mais mon approche est encore trop limitée justement par manque de subtilité et de vision globale), je préfère une démarche coopérative. Evidemment, en environnement professionnel, je suis convaincu que l'intérêt économique du "mimétisme" est primordial et incontournable, mais je ne me situe pas actuellement sur ce registre.

Bonne journée. Cordialement.
Gilles

[chris37]

Tiens ! on parle de moi

Bonjour les amis,

C'est vrai que pour le moment je n'ai pas de temps a consacrer mais j'ai toujours un faible pour mon petit guépard....

J'ai tenté de créer un équipe pour le développement de composants Lazarus mais comme le dit Gille, une étroite coopération est nécessaire pour que cela fonctionne. Aussi j'ai lâché l'affaire et pas convaincu par QT à 100% car j'ai encore moi l'impression de maitriser mon code.

Pour le moment, c'est Stand By.....et toujours grosse réflexion car je n'ai toujours pas migrer mes programmes Lazarus de la boite

Cordialement,
Chris

[Invité]

Héhé...

Salut Chris,

Prends ton temps... Il travaille pour... Lazarus... qu'à mon avis tu rejoindras... Quand on est tombé dedans...

Prends ton temps mais essaye de terminer ta méditation avant ma retraite !

En attendant avec ton (et il y a peu notre) "? -> XP-Pro", on a l'air malin. Je regardais hier sur le forum une discussion de Javaïens (entre eux) dans laquelle on percevait également leurs incertitudes et parfois même leur frustration. Or, quand on connait Java, sa stature, l'importance et la richesse de sa communauté, on se rend compte que finalement les certitudes sont rares... et encore plus rare la "perfection", plus exactement la "solution parfaite".

J'espère que tu installes toujours les dernières versions de Lazarus et que tu es allé faire un tour du côté des Grids & co : même les ancêtres ont été "bougés" ! Cela dit, c'était nécessaire : le bug des StringGrids était structurel et non pas une petite erreur ou une insuffisance de programmation. Dans l'état, c'était irréparable.

Et puis, hormis un petit problème de surdité parfois, l'équipe de Lazarus -pour ce que j'en connais- est fréquentable... Le problème est probablement que l'on reste trop franco-français : on se monte la tête, on se frustre et on abandonne. Les "Lazarusiens", ils n'étaient même pas au courant ! A l'occasion, j'ai même appris quelques expressions disons... "usuelles" de mécontentement en anglais...

Bon maintenant, vu qu'au niveau des composants tu as quelqu'avance, entre 2 méditations, tu pourrais peut-être en dédier une nouvelle à l'idée iconoclaste de te "re-sacrifier" en acceptant de te mettre au niveau de mes paquerettes (pour les composants) à charge de revanche pour d'éventuels autres domaines ... Ceci évidemment dès que tu auras un peu de temps.

Ceci dit, j'arrête-là mes bavardages. En attendant une nouvelle DBGrid, il faut que je débarasse mon code additionnel dans des {$I xxxx.inc} pour faire place nette au code "métier".

Au plaisir de te relire,
A bientôt. Gilles

[SergioMaster]

Heureux de voir Chris encore vivant

J'ai tenté de créer un équipe pour le développement de composants Lazarus mais comme le dit Gille, une étroite coopération est nécessaire pour que cela fonctionne. Aussi j'ai lâché l'affaire

ce n'est pas évident ( je le sais , j'en étais )

avant ma retraite !

tu en es loin jeunot

Toujours est-il que si j'ai mis Lazarus de coté c'est surtout pour des questions de productivité , n'ayant pas le temps donc de m'y consacré pleinement (et effrayé par tout les problèmes reportés dans la mailing list Lazarus : ne jamais s'y inscrire )

J'ai donc continué a utiliser DELPHI , il faut bien gagné sa croute
je ne comprend pas trop

je n'accepte pas leur déclinaison du mot "Client" et les rapports induits par celle-ci.

mais je confirme , enfin en partie , l'annonce de la version 2011 n'est que pour la rentrée

qu'un retard est annoncé du fait de la nouvelle version de QT

plutôt que QT , je dirais plûtot l'environnement graphique LINUX s'appuyant sur les bibliothèques QT .

Et , oui, Delphi sera et restera un EDI windows , malgré tout ,et c'est ce que j'attends avec impatience , on pourra compiler une application Delphi pour différents OS .

. Le mimétisme est une méthode d'apprentissage parmi d'autres... Elle est pratique et très efficace mais dans ce cas précis, elle ne peut pas me satisfaire : elle manque de "subtilité". On apprend (constate) ce qui fonctionne en passant (très) souvent à côté des subtilités de la démarche qui a mené à la "conclusion exploitable".

je suis d'accord , mais c'est un peu la même chose avec ce que tu proposes

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.

-Le bug était connu en 0.9.26, avait été réglé et était revenu..
-même les ancêtres ont été "bougés"

Et c'est bien là un des problèmes de Lazarus , qui ne me le fait choisir que pour des applications lègères . Quand aura-t'on enfin une version "LTS" stable ?!

[Invité]

Bonjour SergioMaster,

Je ne reprends pas tout, mais seulement quelques points.

Delphi : je passe. L'après Borland ne me convient pas. On peut en parler par messages privés si vous voulez. Je ne dis pas qu'il est mauvais. Je n'utilise plus ce produit. Il ne remplit pas mon cahier des charges.

Mimétisme : non, ma démarche est différente, pas facile à expliquer. Schématiquement et de manière trop simpliste probablement, répétons (par mimétisme donc ) qu'on apprend autant par ses erreurs que par ses réussites... et surtout on renouvelle moins les premières au fil du temps... Ce qui permet de redécouvrir la roue, plutôt les principes et contraintes de sa conception... alors que ce que vous me proposez, c'est de l'utiliser. Je fais une grande différence conceptuelle entre le programmeur qui utilise un langage (et ici ses composants) pour remplir un cahier des charges qu'il a contracté avec son Client, et celui qui dans le cas présent, crée ou modifie des composants, non pas à sa sauce (ie en gardant la maîtrise de son développement), mais en restant compatible avec l'esprit et la manière de programmer du groupe de développement de l'IDE. Pratiquement toutes mes propositions ont été retoquées très justement ou ont été insuffisantes, non pas parce qu'elles ne réglaient pas le problème, mais parce qu'elles n'étaient pas compatibles avec le "reste", avec d'autres procédures, avec d'autres composants qui devaient pouvoir les utiliser.

it took a little more than suggested patch, please check

Bref, j'ai besoin de globaliser. Le mimétisme 'simple' (à la différence d'un mimétisme 'riche', interactif grâce à la présence d'un prof, d'un "accompagnateur" par exemple), donc un mimétisme 'simple' (un code même commenté que l'on reproduit) ne permet pas cela, quelque soit soit son véritable intérêt et donc ses très nombreuses utilisations. Cette méthode est trop "pauvre". Mais bon, la terminologie et même le concept sont peu importants... et ma démarche vous paraît peut-être un peu étrange... Ces "échecs" ou incapacités, loin de me démoraliser, m'incitent au contraire à persister... sans garantie de succès évidemment. Peu importe. Quoiqu'il en soit, je vous remercie une nouvelle fois de me proposer vos codes.

Pour Linux qui varie en permanence. Oui, enfin, il faut savoir de quels Linux on parle. Ma Debian est très stable (dans le temps) : les nouvelles versions ne sortent pas tous les jours. Contrairement, à mon Ubuntu qui l'est beaucoup moins (stable), non pas en utilisation au jour le jour (je ne me plains pas à ce sujet), mais en terme de compatibilité ascendante (notamment à une période pour son gtk2)... mais c'est la rançon d'une évolution rapide, qui colle au matériel et à la demande des utilisateurs. Si on ramène cela à Lazarus, dans la mesure où il n'y a qu'une LCL, les contraintes sont encore plus fortes que pour Delphi par exemple. Comme je l'ai déjà précisé, c'est donc de la part des concepteurs de Lazarus/Free Pascal une démarche autrement plus ambitieuse que de s'appuyer sur d'autres produits développés par d'autres équipes... et ceci quelque soit le Prism (le prisme, voulais-je dire) ou le QoTé (4 évidemment) par lequel on suit mon regard.

Pour la retraite, c'était une boutade. Les profs commencent leur carrière "tardivement". Mais pour rester dans le même registre (et dans mon domaine), en maths, on commence à s'interroger sur un nouveau problème de possible non-convergence : à la vitesse où la date de la retraite s'éloigne, allons-nous vieillir moins vite que ne va reculer la date ? Plus sérieusement, je suis tellement addicte à la programmation que j'envisage plutôt une reconversion qu'une retraite.


Bonne journée.
Cordialement. Gilles