Discussion :

[fredfred]

Salut à tous,

J'ai un problème avec un DBCtrlGrid.

Celui-ci affiche le résultat d'une requête (ADO) qui est réactualisée toute les 3 secondes par un REQUERY, de manière a refléter en temps quasi-réél les modifs faites sur les autres postes.

Le problème se pose si la liste contient plus d'enregistrements que le DBCtrlGrid n'a de lignes.

Exemple : le DBCtrlGrid affiche 9 lignes, et la requête envoie 25 records.
au début la première ligne sélectionnée correspond au premier records de la requête.
Si je fais PAGE DOWN, le DBCtrlGrid affiche les 9 records suivants, et c'est toujours la première ligne qui est sélectionnée. Normal.
Mais lorsque le REQUERY se lance, je dois faire en sorte que l'écran reste positionné sur le record sélectionné, sinon la liste se remet sur le tout premier record.

Quelle que soit la solution que j'utilise pour revenir à l'enregistrement en cours de sélection avant le REQUERY (bookmark, recno, panelindex), le DBCtrlGrid affiche l'enregistement sélectionné au milieu de l'écran, ce qui est perturbant : avant le requery, la ligne sélectionnée est la première de la grille, après le requery cette ligne "se déplace" au milieu de l'écran alors que l'utilisateur a encore les yeux rivés sur la première ligne.
L'enregistrement sélectionné est toujours le bon, mais sa position d'affichage ne cesse de changer.


De plus, le bookmark reste la solution la plus sécurisante, car des enregistrements peuvent avoir été supprimés sur d'autres postes entre deux REQUERY.

Y a t'il un moyen de mémoriser ou de repositionner la grille de telle manière que l'enregistrement sélectionné ne change pas de place après un rafraichissement de la requête ??

Merci d'avance.

[alheuredudejeuner]

bonjour

avant requery tu notes la clé de ton enregistrement (clé := fieldbyname('clé').asstring;

puis requery

puis locate la clé pour te repositionner sur l'enregistrement encours
( je n'ai pas le code sous la main )

André

PS : Avec D2009 sur clé, bouton droit de la souris, refactoring déclaré une variable
ou alors MAJ+Ctrl+V

[fredfred]

ah oui, flute, j'ai oublié de dire que j'avais aussi essayé le locate, et ça fait pareil (et c'est même un poil plus long que le reste)

[alheuredudejeuner]

pendant le traitement.

ca accélère beaucoup les choses....

puis

datasource.enable := true // après le traitement.

25 enregistrement c'est pas beaucoup

lis les un par un jusqu'à que

// en gros

Code :

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

1
2
3
4
5
6
7
8
9
10
11
datasource.enable:=false;
with Mondataset  do begin
   if is empty then  Requiry else 
   begin
      cle := Fiedbyname('cle').asstring;
      Requiry;
      first; // j'ai cru lire que sa sert à rien, mais bon ca me rassure
      while not Fiedbyname('cle').asstring:=cle do next ;
   end;
end;
datasource.enable:=true;

au moins voir si cela fonctionne, j'ai pas testé, peut-être a corriger un peu
25 lignes d'enregistrements, si il n'y a pas une infinité de champs, ou des blob très lourds, cela devrait quand être rapide;

André

[fredfred]

Idée intéressante,

sauf que...

arrivé en bas de la première page écran, le next reste sur la dernière ligne de la grille. Au final, le programme retrouve bien l'enregistrement sélectionné, mais il est toujours affiché au bas du DBCtrlGrid (au lieu du milieu avec mes différents essais).

Il faudrait pouvoir associer un Recno et un PanelIndex, mais je ne vois pas comment...

[alheuredudejeuner]

Sélectionner les 4 lignes avant et les 4 ligne après

puis gérer la pagination, un bouton suite si il y en a une et retour si besoin

pas beau mais bon

ce que je fais quand j'ai besoin de connaitre des infos sur mes données avant de les afficher.

Tu peux ouvrir un query

interroger ce query pour connaitre la cle du 4° enregistrement avant ta clé.

ensuite dans le dataset tu sélectionne les 9 premiers enregistrement a partir de la clé que tu as chercher précédemment ( en sql " select * first 9 from ma table")

et tu te cales sur ton enregistrement

ensuite pour gérer la pagination

tu te créer des boutons qui commanderont des requêtes type

select * skip a, first a from ma table. a est un entier.

Il restera toujours un souci

si entre la milisecondes ou le qurery prends l'information et celle ou tu ouvres ton dataset des enregistrements sont committés par ailleurs, alors il se peut que le l'enregistrement que tu cherches ne soit pas centré, voir même qu'il n'apparaisse pas.
Sauf a bloqué la base de donnée le temps que ça se fasse.

bon courage

andré

[chaplin]

Dans l'idéal, il faudrait passer par un proxy travailler de façon assynchrone.

[fredfred]

Gérer manuellement la pagination pourrait être envisageable si la requête n'était pas si tordue et si gourmande en ressources coté serveur (rien moins que 12 jointures conditionnelles). Si je dois relancer la requête, même en limitant le nombre de records a afficher, les temps de réponse vont s'écrouler.

[chaplin]

Il faut gérer cela astucieusement au niveau SGBDR.
Ensuite, il faut appeler la requête uniquement s'il y a des changements dans le SGBDR pour minimiser le rafraîchissement, quitte à centraliser l'appel au niveau middleware et ensuite renvoyer les résultats aux postes clients.