Discussion :

[Invité]

Bonjour,

je cherche à déplacer par Dnd (par glisser-lâcher) une ligne d'une Grid. Le champ concerné est xxINDEX (Integer).

Ce qui fonctionne : si je charge mes données dans une TStringGrid (donc sans lien permanent avec la table), je peux déplacer sans problème une ligne. C'est la méthode que j'utilisais sur mes TStringGrid en Lazarus. Je n'utilisais pas les TdbGrid.

Ce qui ne fonctionne pas : si j'utilise une TGrid liée (par Dataset classique ou LiveBindings) directement et de manière permanente à une table dont un champ contient le N° des lignes (clé), au mieux il ne se passe rien... et au pire, suivant les modifications (de plus en plus hasardeuses ) du code, cela plante. J'ai même corrigé la structure de la table : j'ai initialement utilisé une cle unique sur le champ xxINDEX, puis une simple clé sur ce champ. Le résultat est toujours identique. J'ai également essayé avec un seul DataSet puis 2 (un pour l'affichage et un deuxième pour le update) sans plus de succès.

Je pense en effet que c'est au niveau du recalcul de xxIndex puis son Update, que cela coince.... Quand par exemple, la ligne "8" est déplacée en ligne "4" par le Dnd, les xxIndex doivent être recalculés (xxINDEX = Row)... mais comme la Grid est en prise directe avec la table, il y a un problème de chronologie dans les Updates. Je ne peux pas changer 2 indexes à la fois...

Bref, quelqu'un sait-il déplacer à la souris une ligne d'une TGrid liée à une table qui contient un champ indexé enregistrant le N° de la ligne, index qui sert de parcours (ORDER BY) à la lecture de la dite table ? Si possible en FMX... en espérant le code transposable aux composants TMS, mais je suis également preneur d'une approche VCL.

Merci.

[SergioMaster]

Bonjour Gilles,

tu me connais, toujours à l'affut d'un truc qui me serait utile par la suite, je n'ai donc pas hésité à penser à ce post

environnement XE8 TMSFMXGrid (pour le reste Firedac/Firebird pour des questions pratiques : j'ai une BDD et donc des tables à utiliser )
de prime abord je me suis dit : 'la TMSFMXGrid "stocke" les données et permet des tris sur colonne(s) donc, au pire, l'ajout d'une colonne calculée (comment ?) me permettrait de faire ça !
si tôt dit si tôt testé, ne sachant pas trop comment calculé la colonne je met simplement un code plus que bidon

je pose donc mes composants
FDConnexion,FdTable (je passe sur les FDGUIXWaitCursor,FdTransaction et fdPhysFBDriver)
et la grille TMSFMXGrid
je déclare les champs de ma Table et rajoute un champ calculé ('Order') que je met invisible
et ajoute le code suivant

Code :

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

1
2
3
4
procedure TForm3.FDTable1CalcFields(DataSet: TDataSet);
begin
Dataset['Order']:=1;
end;

me reste "plus qu'à" lié visuellement mes champs à mes colonnes
et à me pencher sur les propriétés (si nombreuses) de la Grille
je met SelectionMode à smsingleRow
reste les options de Sorting (puisque c'est là ma première idée) et en profite pour mettre le mode à gsmNormal et multicolumn à false
et je découvre les options de souris (options.mouse) autodragging (true par défaut) et rowDragging que je coche

je me prépare à mettre les gestions d'évènements OnDragxxxx (un simple // dans chaque pour qu'une compilation ne les enlèvent pas)
et vérifie le tout par curiosité

pas de code de plus et j'arrive à faire du dragging de lignes serait-ce aussi simple ?

Bon la table est petite (2 recs) je n'utilise pas de query (donc pas de order by) et ne sais si par la suite tu veux garder ce nouvel ordre
je n'aime pas non plus le fait que je puisse mettre une ligne au dessus de la ligne de description des colonnes (mais ça ce doit être gérable via les évènements OnDrag)
Le prochain épisode et post de ma part concernera donc ces points : Query, grosse table (en tout cas plus de lignes que n'en a la grille et compréhension des OnDrag à utiliser)

++ Serge

[SergioMaster]

Me voilà de retour

Le prochain épisode et post de ma part concernera donc ces points : Query, grosse table (en tout cas plus de lignes que n'en a la grille et compréhension des OnDrag à utiliser)

première bonne nouvelle avec l'utilisation d'une query (donc avec un order by pour le tri) dans une plus grosse table (soyons modeste elle ne dépasse pas pour l'instant la limite, si énervante, des je ne sais plus combien de lignes qui m'énervait tant à mes débuts FMX)

tout fonctionne sans une ligne de code (j'ai même ôté le champ calculé) avec les même options que dans mon post précédent, une ligne déplacée, même lorsque plus visible après moultes Scroll avant ou arrière reste bien dans sa nouvelle position


pour les OnDragxxxx par contre je bogue

si j'ai découvert le OnCanDragRow qui me permet de ne pas pouvoir déplacer la ligne 0 ainsi :

Code :

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

1
2
3
4
5
procedure TForm3.TMSFMXGrid1CanDragRow(Sender: TObject; ARow: Integer;
  var Allow: Boolean);
begin
Allow := ARow > 0;
end;

le OnRowDragged qui permettrait certainement le traitement pour mémoriser le nouvel ordre

Code :

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

1
2
3
4
5
procedure TForm3.TMSFMXGrid1RowDragged(Sender: TObject; FromRow,
  ToRow: Integer);
begin
if ToRow=0 then ToRow:=1; // ne fonctionne pas
end;

Ne pas accepter un drag (et même entrer dans ces événements OnDragxxxx) reste le défi du WE

++ Rocky Balboa n'a pas dit son dernier mot : "Gabrielle" (tousse, crache du sang et des dents)

[Edit] cela ne valant même pas la peine d'un nouvel épisode, pour empêcher de déplacer au dessus de la ligne 0 voici le code/évènement à utiliser : OnBeforeRowDrop

Code :

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

1
2
3
4
5
procedure TForm3.TMSFMXGrid1BeforeRowDrop(Sender: TObject; FromRow: Integer;
  var ToRow: Integer; var Allow: Boolean);
begin
Allow := ToRow>0;
end;

victoire aux points ?

[Invité]

Bonjour,

j'ai utilisé

Code :

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

1
2
3
4
5
6
7
procedure TfDND.TMSFMXGrid1RowDragged(Sender: TObject; FromRow, ToRow: Integer);
var
  i : integer;
begin
   for i := min(FromRow, ToRow) to max(FromRow, ToRow) do
   TMSFMXGrid1.Cells[4, i] := intToStr(i);
end;

En réalité, je n'ai pas de problème dans la mesure où la connexion ne semble pas active avec les TMSFMXGrid1. Les cellules de la colonne 4 [qui contient l'index] peuvent être changées sans impacter la table. Il suffit de lancer alors un update sur toutes les lignes concernées (en réalité celle comprises entre min(FromRow, ToRow) et max(FromRow, ToRow).

[SergioMaster]

Bonjour Gilles

Il suffit de lancer alors un update sur toutes les lignes concernées (en réalité celle comprises entre min(FromRow, ToRow) et max(FromRow, ToRow).

super la réduction aux lignes concernées, je n'y aurait pas songé

[Invité]

Bonjour Serge, pas si super que cela. J'ai un problème d'écriture de requête.

Voilà ce qui fonctionne sur mon serveur mariaDB.

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
39
procedure TfDND.TMSFMXGrid1RowDragged(Sender: TObject; FromRow, ToRow: Integer);
var
  i : integer;
  sREQ, sREQdeb, sREQfin : String;
 
begin
  sREQdeb := 'INSERT INTO teTEST (teid, teINDEX) VALUES ';
  sReqfin := ' ON DUPLICATE KEY UPDATE teINDEX=VALUES(teINDEX);';
 
  with UniQueryUID do try
    for i := min(FromRow, ToRow) to max(FromRow, ToRow) do begin
      TMSFMXGrid1.Cells[2, i] := intToStr(i);
 
      if (sREQ = '') then sREQ := sREQdeb else sREQ := sREQ +', ';
      sREQ := sREQ + '(' + quotedstr(TMSFMXGrid1.Cells[1, i]) + ',' + intToStr(i) +')' ;
    end;
 
    sREQ := sREQ + sREQfin;
 
    SQL.Clear;
    SQL.Add(sREQ);
 
    Execute;
    Close;
  except
   {$IFDEF DEBUG}
   on E: EDatabaseError  do
     showmessage(E.Message);
   {$ELSE}
   Close;
   with UniConnection1 do
     if Connected then Connected := False;
   MessageDlg( 'Erreur critique', 'La liaison internet avec la base est impossible. ' +
               'Le programme va s''arrêter.',
               mtError, [mbOK], 0);
   Application.Terminate;
   {$ENDIF}
  end;
end;

Cela fonctionne correctement et rapidement même sur mon serveur distant. Pour un peu, je me demanderais si cela vaut le coup d'utiliser une base locale... Mais ici je suis en fibre... Alors cela relativise beaucoup. Reste quand même à trouver une base locale proche de mariaDB... SQLite reste problématique en surcharge d'écriture.

J'aurais préféré ainsi :

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
39
40
41
42
43
44
procedure TfDND.TMSFMXGrid1RowDragged(Sender: TObject; FromRow, ToRow: Integer);
var
  i : integer;
begin
  with UniQueryUID do try
    SQL.Clear;
 
    for i := min(FromRow, ToRow) to max(FromRow, ToRow) do begin
      TMSFMXGrid1.Cells[2, i] := intToStr(i);
 
      with SQL do begin
        if Text.IsEmpty then
          Add('INSERT INTO teTEST (teid, teINDEX) VALUES')
        else
          Add(', ');
        Add('(:paID, :paINDEX)');
      end;
      with Params do begin
        ParamByName('paID').AsString  := TMSFMXGrid1.Cells[1, i];
        ParamByName('paINDEX').AsInteger := i;
      end;
    end;
 
    SQL.Add('ON DUPLICATE KEY UPDATE teINDEX = VALUES(teINDEX);');
 
    Execute;
    Close;
 
  except
  {$IFDEF DEBUG}
    on E: EDatabaseError  do
      showmessage(E.Message);
  {$ELSE}
    Close;
    with UniConnection1 do
       if Connected then Connected := False;
       MessageDlg( 'Erreur critique', 'La liaison internet avec la base est impossible. ' +
                   'Le programme va s''arrêter.',
                   mtError, [mbOK], 0);
       Application.Terminate;
   {$ENDIF}
  end;
 
 end;

Et là je suis dans les choux... Soit il y a une erreur que je ne vois pas, soit on ne peut pas injecter paID et paINDEX en boucle.

[solilog]

Bonsoir,

Pfff je trouve que vous faites vraiment compliqué. Il faut faire 3 updates et passer par une clé unique, temporaire (ici -1), et on peut conserver la clé unique.
On va le faire de 2 façons, avec des tables, et en SQL sur une DB Firebird 2.5
Soit la table TBTIER avec le champ TiId (integer) sur un unique index.

sur ta form une table TB_TIER avec . tablename = 'TBTIER' , indexname 'TBTIER_01' sur le champ TIID (integer)

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 TForm1.ChgRec( kFrom, kTo:integer );
begin
   tb_tier.findkey( [kFrom] );
   tb_tier.edit;
   tb_tier.fieldbyname('TIID').asinteger := kTo;
   tb_tier.post;
end;
 
procedure TForm1.SwapRec( kFrom, kTo:integer);
begin
   chgrec( kTo, -1) ;
   chgRec( kFrom, kTo);
   chgrec( -1, kFrom);
end;

Avec SQL et un tQuery
Soit qyTIER: tquery et en mode conception ('cest mieux, ca crée les params tout seul) tu mets le SQL suivant:
update tb_tier set TIID= :kTo where TIID=:kFrom

et tu crées les procedures:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TForm1.Sql_ChgRec( kFrom, kTo:integer );
begin
   qyTIER.params[1].asinteger := kFrom;
   qyTIER.params[0].asinteger := kTo;
   qyTIER.execsql;
end;
 
procedure TForm1.SQL_SwapRec( kFrom, kTo:integer);
begin
   SQL_chgrec( kTo, -1) ;
   SQL_chgRec( kFrom, kTo);
   SQL_chgrec( -1, kFrom);
end;

Ca marche bien, c'est quasi instantané.

solilog

[SergioMaster]

Bonjour,

Pfff je trouve que vous faites vraiment compliqué.

d'accord

Il faut faire 3 updates et passer par une clé unique, temporaire (ici -1), et on peut conserver la clé unique.
On va le faire de 2 façons, avec des tables, et en SQL sur une DB Firebird 2.5

Déjà, il s'agit d'une base MariaDB mais peu importe

j'aurais surtout tout mis dans une transaction

enfin tout cela est théorique, je n'en ai pas fait l'essai . C'est juste une réaction à chaud, ce qui me choque surtout c'est le INSERT .... ON DUPLICATE j'eusse pensé qu'il s'agissait uniquement de UPDATE. Cependant, comme cela dépend de la structure de la table (index, contraintes) je te laisse juge, nonobstant si teid est l'ordre et teINDEX la clé unique j'aurais mis un simple 'UPDATE teTEST set teid=:teidp where teINDEX=:teINDEXp'

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
with UniQueryUID do
  begin
    SQL.Clear;
    SQL.Add('INSERT INTO teTEST (teid, teINDEX) VALUES (:teidp,:teINDEXp)';
    SQL.Add('ON DUPLICATE KEY UPDATE teINDEX=VALUES(:teINDEXp);');
    Prepare;
    StartTransaction;
    try 
      for i := min(FromRow, ToRow) to max(FromRow, ToRow) begin 
        ParamByName('tedip').asInteger:=i;
        ParamByName('teindexp').asString:=TMSFMXGrid1.Cells[1, i];
        ExecSQL; 
       // ici je n'ai pas trop saisi le EXECUTE; CLOSE; mais c'est peut être tes composants 
       // si EXECUTE est l'équivalent de EXECSQL il me semble pas qu'il y ait besoin de close 
       // grâce aux paramètres le SQL ne change pas donc pas besoin de clear dans la boucle ;) 
      end;
      Commit;
    except
      Rollback;
   end;

Petite Note à ton attention Gilles, utilises plutôt des requêtes paramétrées que des concaténations de chaines pour obtenir le SQL, tu noteras également le prepare juste après avoir créer la requête (je ne sais si Anydac a la même chose mais je pense que oui)

[Invité]

Bonjour,

Ca marche bien, c'est quasi instantané.

Certes mais pas ma compréhension de votre approche. Il va me falloir un petit peu de temps. En tout cas, merci pour votre aide.

Serge,

• Le INSERT... ON DUPLICATE KEY UPDATE. Tu te rappelles que mon serveur est distant. J'évite les allers et retours entre la station et le serveur. Tu te rappelles aussi que j'utilise Windev. Il ne me permet pas de concaténer des requêtes UPDATE en une seule requête (genre Update...;...; Update...; ). J'ai donc utilisé cette astuce. Dans la requête (unique donc), comme les enregistrements existent, le INSERT est remplacé par le UPDATE (ON DUPLICATE KEY UPDATE). Il y a un point faible cependant : si un enregistrement vient juste d'être effacé par un autre utilisateur sur le serveur distant... Cela a imposé une boucle de vérification (en thread secondaire sous Windev).

• Le codage est de type Lazarusien::Connecteurs natifs... J'en ai des tonnes et donc je les réutilise à outrance. Ici, les verrous ne sont pas posés ni le transactionnel puisque j'utilise une imbrication Local/Distant. Compte tenu de mon temps libre, je suis en phase recherche... (C'est un bien grand mot... "découvertes un peu trop lentes à mon goût" serait plus approprié)... Au final, je regrette vraiment de plus en plus, non pas cette absence du support Nux par Delphi, mais l'absence de sa présence dans le roadmap. Sinon je changerais mon choix, je crois (ie exit Qt).

• Les requêtes paramétrées semblent impossibles sur des tuples... donc ma concaténation de chaînes (et ma question)

• Sinon, j'arrive à faire fonctionner sous Windows le libmysqld.dll (Embedded) avec Unidac. Le problème est de savoir si c'est portable en OS X. Pour trouver des explications, c'est délicat. Il faut que je regarde si c'est transposable à FireDac... car dans tous les cas (y compris avec les composants Devart) la présence de la bibliothèque libmysqld.dll est obligatoire.

Enfin, j'ai adopté "ta" méthode pour le mac OS X... Et en effet, cela fonctionne mieux (mais plus mon Qt ?)... Mais je n'en démords pas... L'approche est mauvaise : en desktop, un IDE doit fonctionner sous l'OS (donc ici mac OS X).

Bonne journée.

[SergioMaster]

Gilles,

je comprends bien le sens du INSERT... ON DUPLICATE KEY UPDATE pas de soucis. Cependant je pense que ce que je n'ai pas du saisir est ton type de programme
on à affaire a du client/serveur (type dans lequel je me suis engouffré) ou du multi-tiers ?

S'il s'agit de client/serveur je ne comprends pas trop la partie windev (je suis bouché ce matin) , s'il s'agit juste de parler d'ajout de plusieurs requêtes (un Script) je pense alors à TUniScript plutôt qu'à TUNIQuery. Là tes concaténations de chaîne prendraient plus de sens

Code :

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

1
2
3
4
5
6
7
8
9
10
 
const uneQuery : String ='INSERT INTO teTEST (teid, teINDEX) VALUES (%d,%s) ON DUPLICATE KEY UPDATE teINDEX=VALUES(%s);'
 begin
     TUniScript.SQL.Clear; 
     for i := min(FromRow, ToRow) to max(FromRow, ToRow) 
        TUNiScript.SQL.Add(Format(unequery,[i,Quotedstr(TMSFMXGrid1.Cells[1, i]),Quotedstr(TMSFMXGrid1.Cells[1, i])]); // format "améliorable"
  ...
    // test connection
    // si ok envoi du script TUniscript.Execute 
 end;

et ce pour le script toujours au sein d'une transaction (je n'en démord pas )

UniQueryUID est connecté à la base "distante" ou locale ?

Au final, je regrette vraiment de plus en plus, non pas cette absence du support Nux par Delphi, mais l'absence de sa présence dans le roadmap.

la compilation LINUX côté serveur dans le cadre des programmes multitiers/datasnap (je mets les points sur les i en fonction de ce que j'en ai compris au Codeway tour Nantes) est bien dans la RoadMap et devrait être dans la version XE9. Le problème FMX LINUX semble être la partie GUI, Embarcadero estime que trop de versions LINUX, et donc de cible, empêche d'envisager cet aboutissement. Ce à quoi je pourrait rétorquer qu'ils n'ont qu'a en choisir une ou deux les plus utilisées et on s'adaptera

Quant au pourquoi Delphi est-il Windows 32 bits et pas portable sur Mac c'est un autre débat, je ne sais même pas s'il est prévu en Windows 64

[Invité]

Mon approche n'est pas très orthodoxe.

En windev chaque update implique l'exécution d'une requête. Donc dans notre cas, si tu échanges la ligne 2 et la ligne 4, je dois exécuter totalement 3 requêtes (ExecSQL). Si tu échanges la ligne 500 avec la ligne 1,...

Pour l'instant dans la configuration actuelle mes requêtes doivent être portables Windev, Qt et Delphi... Développer sous 3 IDE différents et 3 OS différents est chronophage. Tout ce qui est "factorisable" et réemployable est bon à prendre.

Le QueryUID est pour les tests actuels connecté au serveur MariaDB distant.

Pour les transactions RAS. Compte tenu de ma configuration un peu particulière, ils sont en place dans les projets mais pas dans les tests (autocommit). D'ailleurs en mySQL embedded, je teste : j'ai une suspicion sur le transactionnel (par contre je n'ai pas besoin des verrous puisque monoposte).

la compilation LINUX côté serveur dans le cadre des programmes multitiers/datasnap (je mets les points sur les i en fonction de ce que j'en ai compris au Codeway tour Nantes) est bien dans la RoadMap et devrait être dans la version XE9.

Compte tenu du datasnap et du nombre de serveurs Nux... ils ne pouvaient pas s'en passer...

Le problème FMX LINUX semble être la partie GUI, Embarcadero estime que trop de versions LINUX, et donc de cible, empêche d'envisager cet aboutissement. Ce à quoi je pourrait rétorquer qu'ils n'ont qu'a en choisir une ou deux les plus utilisées et on s'adaptera

Comment font Lazarus et Qt ?... Mais je reconnais que la rentabilité d'un tel portage ne sera pas nécessairement au rendez-vous... Cependant une partie du chemin a été faite pour les serveurs et pour Mac OS X qui est à l'origine un cousin de Linux.... Et une ligne dans le roadmap me suffirait même si c'est prévu dans 2 ou 3 ans. Abandonner Linux actuellement n'est pas envisageable dans mes développements mais si on reporte, je peux m'adapter ponctuellement (et en attendant) avec Qt ou lazarus.

Quant au pourquoi Delphi est-il Windows 32 bits et pas portable sur Mac c'est un autre débat, je ne sais même pas s'il est prévu en Windows 64

Oui, c'est un autre débat très Windowsien... C'est lié à la culture des Delphistes "branche historique" pour qui le win64 est inutile et Mac OS et Nux sont des sous OS... ou presque ! La branche historique est sédentaire : "ils" ne sont pas allés voir si l'herbe était plus verte ailleurs... Windows me plaît autant que Nux ou Mac OS X... Et je ne dois pas être le seul dans ce cas... Et le 32 bits (surtout Windows) est le passé (ce bon vieux win32 attend la bonne, la vraie succession...)... Va y a avoir de l'ambiance sur le forum encore...