Discussion :

[gvasseur58]

Le premier meetup Delphi à Lille est confirmé pour le 25 avril 2019 prochain, une occasion unique d'échanger avec d'autres programmeurs et Patrick Prémartin (MVP) très présent sur nos forums. Un apéritif dînatoire avec planches de charcuteries, fromages et desserts est offert dès 19 heures, sachant que les présentations commenceront au plus tard à 20 heures. L'ensemble est gratuit, mais demande une pré-inscription à cette adresse : https://www.barnsten.com/fr/evenements

Ce meetup intéressera plus particulièrement les porteurs de projets logiciels, les étudiants et les informaticiens désireux de concevoir rapidement des prototypes de logiciels et d’applications mobiles afin d’en valider le concept. Pas besoin de savoir programmer pour suivre la présentation qui sera basée sur un cas concret de développement d’application mobile pour Android en moins de deux heures.

La présentation sera faite avec la version gratuite de Delphi destinée au grand public : Delphi Community Edition. Bien entendu, elle sera aussi utilisable pour les licences commerciales et académiques de Delphi et RAD Studio.

Au programme :

• Présentation de Delphi et RAD Studio avec un tour des fonctionnalités de l’EDI de Delphi / RAD Studio et de sa configuration pour compiler des applications mobiles.
• Présentation du framework FireMonkey à utiliser pour la création graphique d’applications multiplateformes sous Delphi et C++Builder.
• Prototypage d'une application mobile avec Delphi : création d'une application de gestion de fiches de lecture avec sa liste de livres, son écran d’ajout et de modification d’un livre, ainsi que son écran de modification des commentaires de lecture.
• Passage du prototype à la production : le prototype ayant passé la phase de validation des fonctionnalités et de l’ergonomie, cette application mobile sera transformée en véritable application autonome. En bonus, il est même prévu la recherche d'informations liées aux livres sur Internet à l’aide d’API REST.

Coordonnées :
ESPACE INKERMANN-CHÂTILLON
5 rue Gauthier de Châtillon - 59000 LILLE
Tél : + 33 (0)3 20 12 01 68
Portable : + 33 (0)6 16 51 92 39

Nous souhaitons un riche avenir à ce groupe meetup qui comporte déjà 88 membres !


Que pensez-vous des sujets proposés ?
Envisagez-vous de participer à cet événement ?

Les meilleurs cours et tutoriels pour apprendre la programmation Delphi

[Fxg]

Bonjour,

Lille étant très loin de Nice, sera-t-il prévu une rediffusion sous forme de vidéo ?

[pprem]

Pas pour les meetups, même si je tenterai quand même d'enregistrer mon écran pour mes archives personnelles, mais ne surtout pas hésiter à organiser un meetup sur Nice et m'y convier.

[gvasseur58]

Bonjour,

Lille étant très loin de Nice, sera-t-il prévu une rediffusion sous forme de vidéo ?

Bonjour,

La présentation la plus proche de Nice est celle prévue le 16 mai à Aix-en-Provence. Ce n'est pas la porte à côté, mais il n'y a pas mieux pour le moment .

Cordialement,

Gilles

[pprem]

La soirée s'est bien passée. J'ai bien sûr débordé sur le timing car je suis trop bavard (ou je voulais montrer trop de choses), du coup j'en ferai probablement une session en vidéo (live ou différé) dans les semaines qui viennent car ce que j'avais prévu tient difficilement en moins de deux heures.

Prochains rendez-vous prévus en live ou sous forme de webinaire en mai, référez-vous aux dates indiquées dans ma signature.

[Invité]

[...] du coup j'en ferai probablement une session en vidéo (live ou différé) dans les semaines qui viennent [...]

Bonjour,

je suis intéressé par le titre qui me semble prometteur : " Codez plus rapidement et plus intelligemment". Bon, le "plus intelligemment" est je suppose marketing, mais le "plus rapidement" m'interpelle. Actuellement avec FireMonkey sur des applications multiplateformes Desktop, je suis -malgré mes efforts- (beaucoup) moins rapide qu'avec Lazarus et Qt.
En cause,

• le Livebinding qui graphiquement semble alléchant mais qui de manière programmée est mal duplicable du fait des contraintes qu'il impose. Par exemple, impossible de piloter comme sous Lazarus les colonnes d'un TGrid sans créer dans l'inspecteur les dites colonnes du TGrid alors que pour Lazarus, on les pilote parfaitement à partir du Query (sans même les créer dans l'éditeur de colonnes du TdbGrid).
• la réalisation des composants -et pourtant je fais cela depuis longtemps- est longue, difficile avec des approches très alambiquées (autant pour le LiveBinding que les styles) : Dériver une TGrid est un exercice chronophage qui exclut toute rapidité et rentabilité par la même occasion. Là, encore à mon sens, l'approche "graphique" a été privilégiée au détriment du développement 'en lignes' de code.

Bref, comme je l'ai écrit à plusieurs reprises, FMX est bien conçu pour développer les "Forms" dans un projet mobile qui en général en contient peu. Mais à mon avis, il est moins bien (mal?) conçu pour développer des projets Desktop d'envergure de manière rapide lorsque la réplication (la transposition) des codes d'une Form à l'autre (une dizaine par exemple) est un avantage quant à la rapidité de développement.

Mais je ne demande qu'à être convaincu du contraire. Aussi suis-je alléché par le titre... et par la vidéo en espérant qu'elle ne porte pas -comme c'est très souvent le cas- sur du projet mobile. Normalement, on est supposé développer également pour mac OS, voire Ubuntu (comme avec Lazarus et Qt) avec les mêmes avantages que procurent ces 2 frameworks).
A bientôt. Cordialement. Gilles

[pprem]

Bonsoir Gilles

Cette présentation était essentiellement orientée mobile et zéro code (ou le moins possible) car plutôt destinées à des non développeurs désireux d'avoir des prototypes opérationnels rapidement pour leurs applications/logiciels, mais bien entendu ça s'applique aussi aux Mac/Win.

Pas sûr que ça change ton opinion sur LB dans FMX, mais tu me diras quand tu l'auras vue.

Dès que j'ai mes dates de live ou de publication, je vous en tiendrai informé ici même.

Stay tuned

[SergioMaster]

Bonjour,

la réalisation des composants, difficile avec des approches très alambiquées (autant pour le LiveBinding que les styles) : Dériver une TGrid est un exercice chronophage qui exclut toute rapidité et rentabilité par la même occasion. Là, encore à mon sens, l'approche "graphique" a été privilégiée au détriment du développement 'en lignes' de code.

On est d'accord sur ce point.
Peu ou pas d'informations précises ajoute à la confusion, la logique voudrait que pour écrire un composant on passe d'abord par une création du dit composant au runtime afin de le tester, mais ensuite il y a une foultitude de choses à prendre en compte et que le test en runtime ne soulève pas (et je ne parle même pas de la partie liaison ). Mon "simple" composant image m'a fait découvrir nombre de ces détails (le tutoriel version "finale ?" est encore en correction même s'il reste encore un point non résolu). Mon attaque sur un RadioGroupBox (truc purement desktop) se solde pour l'instant décevante dès que je dépasse le stade de ma création au runtime


Quant aux styles j'ai encore un petit goût amer, dès qu'il y a des objectsstyles imbriqués cela devient d'une complexité crasse !

Pour la partie grille par contre, je suis mitigé. Comme tu t'en doutes j'en utilise pas mal pour mes applications desktop mais j'utilise de plus en plus les TListview en remplacement. Quand je crée des grilles je le fait généralement avant de faire les liaisons donc, effectivement je crée les colonnes en premier lieu, la pratique m'a montré que ce choix était plus pertinent. Je ne me suis pas encore attaqué, faute de temps, à une création de celles-ci au runtime mais c'est une approche que j'ai envisagée comme j'ai pu le faire pour certaines liaisons mais cela s'éloigne du "zéro code" (à utiliser donc avec parcimonie)

[Invité]

[...]Pour la partie grille par contre, je suis mitigé.[...]

Bonjour Serge,
je ne sais pas comment tu procèdes mais que ce soit avec Lazarus ou Qt, j'utilise des fenêtres réplicables.

D'abord une unité relative aux traitements de toutes les fenêtres :

Code :

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

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
unit uSQL;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, uGlobals {Tsrvs, TErrorsSQL}, lzDBGrid,
  Uni, UniProvider, MySQLUniProvider, MyClassesUni {EMyError -ADD GH 190321-1752},
  DB {Tbookmark},
  Dialogs;
 
{Méthodes générales}
function CreateID(): string;
function ResetErrorSQL(): TErrorsSQL;
function AssignSrvToConn(aSrv: TSrvs; aConn: TUniConnection): TErrorsSQL;  {Obsolète}
 
{Méthodes Grids élémentaires}
function GridGetIDSelectedSEL(aKey: string; aUniQuery: TUniQuery): TErrorsSQL;
function GridGetIDtoReplaceSEL(aKey: string; aUniQuery: TUniQuery): TErrorsSQL;
function GridReplace(aID: string; aKey: string; aUniQuery: TUniQuery): TErrorsSQL;
function GetMultiParams(aGrid: TlzDbGrid; aKey: string): string;
 
{Méthodes Query Base}
function QueryAssignSrv(aQuery: TUniQuery; aSrv: TSrvs): TErrorsSQL;
function QueryConnect(aQuery: TUniQuery): TErrorsSQL;
function QueryStartTrans(aQuery: TUniQuery): TErrorsSQL;
function QueryOpen(aQuery: TUniQuery; const aReq: TStrings = nil;
  const aTypes: TStrings = nil; const aValues: TStrings = nil): TErrorsSQL;
function QueryExecSQL(aQuery: TUniQuery; const aReq: TStrings = nil;
  const aTypes: TStrings = nil; const aValues: TStrings = nil): TErrorsSQL;
function QueryCommit(aQuery: TUniQuery): TErrorsSQL;
function QueryRollback(aQuery: TUniQuery): TErrorsSQL;
function QueryClose(aQuery: TUniQuery): TErrorsSQL;
function QueryDisconnect(aQuery: TUniQuery): TErrorsSQL;
{and... tools}
function QueryLockAndDel(aQueryUID: TUniQuery; aREQlock, aREQdel: TStrings;
  aValue: string): TErrorsSQL;

Ensuite une fenêtre modèle :


Je paramètre le Query et charge son éditeur de champs :


Et comme tu peux le constater l'éditeur de colonne de la Grid est vide :


Je modifie éventuellement quelques présentations dans le Create de la Form.

Code :

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

1
2
3
4
5
6
7
8
{IHM}
  with dbGridSEL do
  begin
    Columns[DataSource.DataSet.FieldByName('imActif').Index].Title.Alignment :=
      TAlignment.taCenter;
    Columns[DataSource.DataSet.FieldByName('usLASTCONN').Index].Title.Alignment :=
      TAlignment.taCenter;
  end;

et éventuellement quelques modifications "graphiques" dans le OnDrawColumnCell de la Grid

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
procedure TfUSsel.dbGridUSDrawColumnCell(Sender: TObject; const Rect: TRect;
  DataCol: integer; Column: TColumn; State: TGridDrawState);
var
  corrX, corrY: integer;
begin
  with Sender as TlzDbGrid do
  begin
    if Column.FieldName = 'imACTIF' then
    begin
      corrX := (Column.Width - imListACTIF.Width) div 2;
      corrY := (DefaultRowHeight - imListACTIF.Height) div 2;
      imListACTIF.draw(Canvas, Rect.Left + corrX, Rect.Top + corrY,
        DataSource.DataSet.FieldByName('xxACTIF').AsInteger);
    end;
  end;
end;

Et c'est tout. Mon composant TlzGrid gère le reste de l'affichage automatiquement, y compris les tris, les champs de recherche, la largeur des colonnes.

Et impossible de faire cela en Delphi XE. Avec un vieux Delphi 7, aucun problème. En Qt, j'utilise la promotion des modèles ce qui va aussi vite. Et je me suis créé l'équivalent du composant TlzdbGrid. Pour en revenir à FireMonkey, ce qui déraille c'est l'absence de DataSource remplacé par les composants du LiveBinding et l'impossibilité (provisoire ?) d'adapter un composant TGrid à mes besoins. Pour le reste, tous mes codes sont transposables de Lazarus à Delphi...

Bref, j'enrage de ne pas pouvoir en faire autant avec Firemonkey parce que sinon FMX est sensationnel dans les 3 OS Desktop. Il a des capacités que ne présente pas Lazarus (mais auxquelles j'accède en Qt).. sachant que pour le mobile, j'ai d'autres solutions au moins aussi performantes que FireMonkey. Alors je me dis que c'est un manque de savoir-faire de ma part... et je ne demande qu'à apprendre. Mais il faut que le résultat soit au bout. Il ne s'agit même pas de faire, mais de faire dans un temps "concurrentiel". En attendant que ce soit le LiveBinding ou les styles, ces "machins" échappent à la programmation classique (POO) et mélangent un peu tous les genres. C'est à moitié descriptif et à moitié ...(je manque de vocabulaire). Séparer les couches est difficile. Même avec QML, on s'y retrouve bien mieux... enfin en réalité, on s'y retrouve très bien !

J"attends la vidéo de Pprem en espérant qu'elle réponde au moins en partie à mes attentes. Je n'ai pas réussi à accumuler ni organiser une recherche documentaire me permettant de régler ces problèmes. Je regarde même des fois auprès d'organismes de formation... Rien. D'où mes conclusions peut-être hâtives... Enfin je l'espère compte tenu du temps déjà investi dans FMX.

Bonne fin de journée. Cordialement. Gilles