Discussion :

[Invité]

Bonjour,

je savais que je ne pourrais pas longtemps me passer de mes propres composants.

• VCL : je cherche une documentation fiable pour empaqueter mes paquets perso. J'ai commencé une dbGridPerso à partir de mes lzStringGrids. Je dois commencer à intégrer des propriétés dans l'IO des Columns.
  Par exemple, la taille minimale des colonnes triables se calcule automatiquement en tenant compte de la place de l'icône dans l'entête de la colonne considérée. Mais certaines colonnes ne sont pas triables et échappent donc à ce traitement. Or cela, le caractère triable ou pas, je dois l'indiquer pour chaque colonne. En réalité, je définis 2 propriétés SortAsc et SorDesc, comme pour la déclaration d'Index sauf que cette génération d'index est générée au moment de la création de la dbGridperso.
  C'est non pas difficile avec une classe intégrée dans le projet-même... mais les codes deviennent illisibles, difficilement différenciables... même si j'ai découvert pas hasard, l'utilisation des {$REGION 'function xxxx'} [...]{$ENDREGION} qui vraiment est très pratique, que je ne connaissais pas sous Lazarus mais qui y fonctionne également, je viens de vérifier sur une 1.2.0. Mais je reste sur mes habitudes premières : je veux séparer définitivement les codes en faisant un paquet, ne serait que par soucis de pérennité. Je procède comment ? C'est uniquement l'empaquetage qui m'intéresse autrement dit la manière adéquate pour l'intégrer dans l'IE. Il semble différent de celui de Lazarus.
• FMX : là, j'en suis à un stade moins avancé. Il semblerait -ce n'est pas une certitude- que tout paquet soit associé à un style. Mal dit : il semble obligatoire d'associer un fichier style à chaque paquet créé même si'il ne sert à rien dans le cas d'un composant non graphique... Cela mérite quelques précisions que je ne trouve pas. Ensuite comment crée-t-on le paquet et éventuellement comment l'intègre-t-on à l'IDE ?

ADD : Je précise ma question. Avec Delphi, il semble qu'il y ait 2 approches possibles. Soit on utilise, Fichier >> Nouveau >> Autre >> Package... enfin je suppose.
Sinon on utilise, Composant >> Nouveau Composant...
J'ai essayé avec cette deuxième méthode :

Pour lzGrid, j'ai procédé ainsi.

Il est vrai que je n'ai pas précisé le Chemin de rech. mais je l'ai supposé optionnel puisque ligne précédente, j'ai précisé le nom complet de l'unit associée.
Et j'ai obtenu cela :

Et de plus, mon Delphi semble moins stable depuis ces incidents... Le dernier message d'erreur revient de temps en temps
Merci.

[Invité]

Il semble -mais je n'ai pas trouvé d'autres solutions- qu'avec cette méthode, il faille faire le paquet en 2 fois... en prenant les mêmes références. D'ailleurs, il m'a demandé d'écraser la deuxième fois, l'unit créée la première fois. Donc, première fois pour créer l'unit et une deuxième fois pour créer un paquet d'installation qui écrase l'unit ?... Le tout plantant toujours à la fin de la procédure.

D'ailleurs à la fin de celle-ci, Delphi vous demande s'il faut installer le paquet ou non, vous prévenant que si tel n'est pas le cas, c'est à vos risques et périls...

Je l'ai laissé faire et j'obtiens en effet le composant :


Donc, maintenant il m'est permis l'autre solution, le package à la main. Je le fais usuellement en Lazarus. Reste à intégrer l'icône du composant. Cela va donc régler mon problème définitivement et facilement.

Mais comme j'ai un point de comparaison... et un excellent concernant ce sujet (Lazarus), la procédure assistée de Delphi est ambiguë et lourde... et semble-t-il plus ou moins buguée. Je ne vais pas passer plusieurs heures à rédiger le problème en anglais et le communiquer à un bug tracker - à moins qu'il y en ait un en français ?- mais normalement les composants sont les fondements même de l'approche Delphi (et Lazarus). Créer facilement les siens est une nécessité. Et là, c'est vraiment améliorable... Même si au bout du cheminement le but est atteint, je trouve l'approche actuelle dissuasive.

Je re-testerai cela en FireMonkey.

[SergioMaster]

Bonjour Gilles,

Mais comme j'ai un point de comparaison... et un excellent concernant ce sujet (Lazarus), la procédure assistée de Delphi est ambiguë et lourde...

parce que recompiler l'EDI Lazarus pour intégrer le composant dans la palette n'est pas lourd peut être ? (c'était un des points les plus rageant de mes expériences composants Lazarus, composants que l'on était obligé de créer par manque ! ceci l'offre de composant a évolué soyons juste).

Pour en revenir a ta démarche , il me semble qu'il y a un faux pas quelque part (mais je ne saurais dire où, il faudrait suivre tes étapes et ce avec ta disposition de bureau pour mettre le doigt dessus) .

Pour la démarche "classique" Fichier/Nouveau/Package cela ouvre en fait un nouveau "projet" (visible dans le gestionnaire de projet) , il suffit ensuite d'ajouter l'unité du composant (ou les unités) et de compiler et/ou installer (toujours via le menu contextuel du gestionnaire par exemple) . En y repensant , ta première tentative a peut être été avortée tout simplement parce que le gestionnaire de projet ne se voyait pas ?

via l'expert je dois avouer n'avoir jamais essayé ! donc je me lance . Une seule différence par rapport a tes étapes , je dérive un TMemo (bref quelque chose de rapide), et au lieu de passer par nouveau package , je passe par nouvelle unité (j'aime bien garder la main) . => pas de lézards , mon nouveau tmemo s'installe lorsque je l'ajoute à un "ancien" paquet . (Je ne franchirais pas l'étape nouveau paquet mais je pense que cela fonctionne également) .
Ceci étant , c'est bien évidemment avec XE4 on ne peut donc écarter le bug avec XE7 mais je doute (sans vouloir t'offenser)

Pour ce qui est des composants FMX , là je suis "vierge" mais je suppose (bien qu'un chef de projet britannique avec j'ai travaillé me disais "dont ass/u/me") que tu as été faire un tour du coté du docwiki ?

[exoseven]

sous FMX c'est la même chose, tu dois simplement indiquer les plateformes que ton composant supporte

Code :

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

1
2
3
 [ComponentPlatformsAttribute(PidWin32 or PidWin64 or pidLinux32 or  pidAndroid or PidOSX32 or PidiOSDevice or PidiOSSimulator)]
  TMonControl = class(TComposantdeBase)
...

Comme l'EDI est en 32bits tu ne peux installer que le paquet windows 32 bits, ComponentPlatformsAttribute permet de griser ton composant sur la palette si la plateforme n'est pas supportée

[Invité]

Bonjour Serge,

Normal qu'il faille recompiler en Lazarus. L'IDE des Delphiens est seulement Win32... Donc évidemment, cela permet quelques facilités ! En plus la "compilation" de l'IDE sous Lazarus ne nécessite que quelques secondes et il est très facile de récupérer la version "old" pour revenir au point de départ. Pour moi cela reste toujours la référence. On verra comment pratique Delphi, si un jour l'IDE devient multi-plateformes.

Pour le reste, je vais m'y faire. Simplement pour le fun, je vais retenter la démarche. Je ne dis pas que cela ne fonctionne pas. Je dis en clair que c'est peu ergonomique, mal accompagné... De toute façon, une fois un premier paquet réalisé, tous les autres empaquetages seront faits à la main. Je me mets simplement à ma place de novice, place que je veux maintenir ainsi. C'est plus pratique pour apprendre et minore les effets "grosse tête"... quoique des fois, je n'arrive pas à interprété correctement les réponses fournies ce qui est très mauvais signe à ce niveau. Novice je l'ai été il n'y a pas longtemps en Qt 5, justement pour faire mes propres widgets... J'écris "je l'ai été", parce que je n'utilise plus beaucoup Qt depuis que j'ai acheté XE7. J'ai même rebranché mon Lazarus pour Linux. Donc en Qt 5, je te garantis qu'il faut garder le moral et être plus que motivé. D'ailleurs, "ils" utilisent peu cette méthode mais un "substitut" lié aux projets et non à l'IDE.

Bref, les composants Delphi/Lazarus sont un trésor. Et l'approche Delphi doit être nickel à ce niveau. Il se peut que j'ai "fauté" dans la démarche. Mais un jour, il faut bien apprendre à marcher. Tu as vu les conséquences du faux-pas ? A améliorer donc ou du moins à corriger.

Bonjour Exoseven,

Le problème soulevé est intéressant. Supposons un composant Win32/Win64/OS X. Le code RunTime doit différencier si nécessaire les cibles releases. Quid du debug en Windows ?
Et pour la partie interface (interactions) avec l'IDE (DesignTime), on place uniquement évidemment du code Win32 dans if csDesigning in ComponentState. C'est cela ?

Je revois tout cela cet après-midi. Y compris la méthodologie sous Windows.

[exoseven]

oui.

Après il faut voir aussi si tu veux un composant qui soit compatible VCL et FMX, là il faut ruser un peu plus et séparer les partie interfaces

en gros tu as FMX.MonComposant.pas et MonComposant.pas

dans FMX.MonComposant.pas je place juste les déclarations pour FMX et j'incorpore MonComposant.pas

Code :

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

1
2
3
4
5
6
7
8
9
{$DEFINE UseFMX}
unit FMX.MonComposant;
 
interface
 
uses
... // déclaration FMX
 
{$I MonComposant.pas}

et dans MonComposant.pas

Code :

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

1
2
3
4
5
6
7
8
9
10
{$IFNDEF UseFMX}
{$DEFINE UseVCL}
unit MonComposant;
 
interface
 
uses
... // déclaration VCL
 
{$ENDIF}

et ensuite tu fais un FMX.MonComposant.dpk et un MonComposant.dpk

[Invité]

Bonsoir,

je confirme. C'est fonctionnel mais systématiquement lors de la création d'un composant, j'obtiens l'erreur 1400 puis un plantage de Delphi, puis le dernier message d'erreur figurant ci-dessus. Et je pense appliquer strictement la procédure de création. Concernant l'erreur 1400, j'ai regardé sur le Web. Elle y est référencée mais les lectures la concernant ne me sont pas d'utilité. Cela restera donc comme cela : heureusement, cela n'empêche pas la création du composant et son intégration dans l'IDE.