Création d'un composant FMX : Capture d'écran sous Windows, macOS, Androïd et iOS
Bonjour,
j'ouvre une discussion pour traiter les problèmes que je rencontrerai avec Delphi XE7. L'objectif est précisé dans le titre. Parallèlement à l'approche Delphi, je réalise le même composant avec Qt 5.10 que je découvre (je travaille tous les jours avec la 5.6).
Les tests seront réalisés sur un Mac Mini High Sierra, Windows 7 pro 64 bits, une tablette Samsung Galaxy et une tablette iPad.
Cordialement. AD.
2 pièce(s) jointe(s)
Problème 1 : création du composant. Que signifie le message Delphi ?
Je crée le composant, définis ma classe, mon paquet d'installation.
Pièce jointe 339072
Il me demande alors de prendre une décision. J'ai répondu oui mais je ne comprend pas bien l'autre alternative.
Pièce jointe 339082
Il me propose quoi en réalité ? J'ai choisis au départ (en cochant le bon bouton) de réaliser un composant FireMonkey. Alors pourquoi me demande-t-il s'il faut intégrer ce qu'il appelle (et qui pour moi ne signifie rien) le "framework Firemonkey" ?
4 pièce(s) jointe(s)
Etape suivante : où sont tous les fichiers....
Je pars de cette structure :
Pièce jointe 339191
Sur le Mac Mini, le projet du composant est dans un dossier commun (accessible) à tous les OS. Ce n'est pas une nécessité mais en Qt, comme les IDE sont natifs, j'ai pris cette habitude.
Pièce jointe 339194
Et dans les répertoires Win32 et Win64, j'ai bien les dcu
Pièce jointe 339196
J'installe à partir d'une option qui n'apparaît plus dans le menu (???? -> Je regarderai cela plus tard)
Pièce jointe 339199
Tout semble bien se passer.
Je crée un projet de test en Win32. J'ai bien mon nouveau composant enfin 2 car j'ai créé 2 versions avec des noms différents. J'ai pourtant bien supprimé les fichiers de la première version. Je regarderai cela plus tard. Je n'ai pas non plus d'icône associée. Je regarderai cela plus tard.
Le ScrCapture est bien dans les uses du projet de test. Je compile mon projet et il me signale une erreur parce qu'il ne trouve pas le dcu du composant. J'ai manqué quoi ? Pourquoi ne les trouve-t-il pas automatiquement ?
Ensuite une question qui m'a traversé l'esprit tout à l'heure : faut-il développer le composant systématiquement en debug et release ?
Pour l'instant, c'est plutôt le mode submersio :. C'est compliqué par rapport à Lazarus et pourtant il y a moins de cibles. Et la doc papier ? Ou un petit squelette de composant hérité d'un simple TControl serait bien utile (il n'y a pas de TcustomControl en Delphi ?)
Merci.
il faut mettre des en-tête a l'unité du composant pour la cible
Bonjour,
Code:
1
2
3
| type
[ComponentPlatformsAttribute(pidWin32 or pidWin64 or pidAndroid)]
TFDMemTableBase = class(TFDMemTable) |
Ca fait longtemps que je n'avais pas fait de paquet fmx.
La compile et l'installation se faisait en win32.( j'ignore a quoi sert le 64 bit pour un composant)
Cordialement
10 pièce(s) jointe(s)
Petite comparaison avec Lazarus
J'ai vérifié avec Lazarus en créant un petit composant à partir de mon "squelette" sous High Sierra.
Evidemment cela n'a pas grand chose à faire dans le forum Delphi, mais on peut cependant se rappeler que Lazarus est issu de Delphi et comparer les 2 processus actuels. Je le redis, la réalisation sous Lazarus d'un composant est restée simple et peu chronophage, dans l'esprit de Delphi 7, pour une efficacité multi-OS sans faille. Ma prose ci-dessus démontre que ce n'est pas le cas avec Delphi XE7. J'ai retrouvé, un truc disparu. On appelait cela une documentation : Delphi7ComponentWritersGuide.pdf. Il y a quelques avantages à ce format désuet (encore plus si c'est du papier), une table des matières et un index qui ne vous obligent pas à regarder la première vidéo Embarcadero longue de 40 minutes, avant de vous arrêter sur la deuxième vidéo (au bout de 4 min.), à moins que Serge ne vous signale que c'est à la 4ème min. de la 2ème vidéo que se situe l'information recherchée :P
----
- Etape préliminaire que l'on ne fait q'une fois : Compiler lazres.lpi, un petit utilitaire fourni dans les sources /lazarus/tools/lazres.lpi qui permet d'inclure l'icône du composant en une seule ligne de code.
----
Ensuite :
- Création du fichier permettant d'inclure l'icône du composant. On ouvre un terminal :
Sous osX
Code:
1
2
3
|
cd "/Volumes/Data HD/LazComponents/slzStart"
/Developer/lazarus/tools/lazres comp_icon.lrs TlzMain.png |
En Windows
Code:
1
2
3
|
C:\lazResTmp
C:\Lazarus-1.8.0RC4-32\toolslazres.exe comp_icon.lrs TlzMain.png |
2 petites remarques :
- Il faut que le nom de l'image est le nom de la classe principale du composant (ici TlzMain).
- Vous ne pouvez pas renommer le fichier lrs obtenu. Il vous faut réutiliser lazres si vous choisissez un autre nom.
Dans le terminal de l'OS X :
Donc le dossier du composant ressemble à ceci (dossiers lib et R&D en moins - lzStart.pas est un fichier créé automatiquement lors de la compilation):
- Je vérifie que le source de la classe principale du composant contient bien l'include du lrs.
- Je compile le composant et l'installe :
- J'ouvre un nouveau projet. Je place mon nouveau composant dans la Form. Je compile le projet.
Voilà.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| <?xml version="1.0"?>
<CONFIG>
<Package Version="4">
<PathDelim Value="\"/>
<Name Value="lzStart"/>
<Author Value="ApproxDev"/>
<CompilerOptions>
<Version Value="11"/>
<PathDelim Value="\"/>
<SearchPaths>
<UnitOutputDirectory Value="lib\$(TargetCPU)-$(TargetOS)"/>
</SearchPaths>
<Other>
<CompilerMessages>
<MsgFileName Value=""/>
</CompilerMessages>
<CompilerPath Value="$(CompPath)"/>
</Other>
</CompilerOptions>
<Description Value="Paquet modèle"/>
<License Value="GNU General Public License"/>
<Version Major="1" Minor="1" Build="1"/>
<Files Count="1">
<Item1>
<Filename Value="lzMain.pas"/>
<HasRegisterProc Value="True"/>
<UnitName Value="lzMain"/>
</Item1>
</Files>
<Type Value="RunAndDesignTime"/>
<RequiredPkgs Count="2">
<Item1>
<PackageName Value="LCL"/>
</Item1>
<Item2>
<PackageName Value="FCL"/>
</Item2>
</RequiredPkgs>
<UsageOptions>
<UnitPath Value="$(PkgOutDir)"/>
</UsageOptions>
<PublishOptions>
<Version Value="2"/>
</PublishOptions>
<CustomOptions Items="ExternHelp" Version="2">
<_ExternHelp Items="Count"/>
</CustomOptions>
</Package>
</CONFIG> |
- Code la classse.pas du composant :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
| unit lzMain;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, LResources;
type
TlzMain = class(TComponent)
private
{ Private declarations }
//Incorporées
FVariable : String;
protected
{ Protected declarations }
public
{ Public declarations }
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
published
{ Published declarations }
property Variable : String
read FVariable
write FVariable;
end;
procedure Register;
implementation
procedure Register;
begin
{$I comp_icon.lrs}
RegisterComponents('Samples',[TlzMain]);
end;
constructor TlzMain.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FVariable := '';
end;
destructor TlzMain.Destroy;
begin
inherited Destroy;
end;
end. |
- Icone utilisée (un png transparent 24*24)
A remarquer que le composant n'est pas placé dans le répertoire de lazarus et que cela ne pose aucun problème particulier (notamment de path).
Evidemment ce composant conçu sous os X est installable et utilisable sous Windows:
- Je compile le source dans le répertoire partagé par tous mes OS (DATA HD nommé F: sous Windows)
- Je crée un nouveau projet, place le nouveau composant sur la TForm et le compile:
---
Parallèlement, j'ai développé le cadre de ce composant avec Qt 5.10. La procédure que je trouvais aussi malhabile qu'en FireMonkey a été nettement (grandement) simplifiée.
