LIER DEUX TDBGRID
cs_cantador
Messages postés
4720
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
31 juillet 2021
-
19 sept. 2009 à 12:34
cs_mark15 Messages postés 18 Date d'inscription dimanche 7 décembre 2008 Statut Membre Dernière intervention 6 décembre 2010 - 29 sept. 2009 à 13:35
cs_mark15 Messages postés 18 Date d'inscription dimanche 7 décembre 2008 Statut Membre Dernière intervention 6 décembre 2010 - 29 sept. 2009 à 13:35
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50584-lier-deux-tdbgrid
https://codes-sources.commentcamarche.net/source/50584-lier-deux-tdbgrid
29 sept. 2009 à 13:35
28 sept. 2009 à 22:25
ça fait plaisir que tu viens nous voir de temps en temps...
et de plus pour me passer un savon !
Pour ce qui est de l'exercice tu as certainement raison quelque part..
mais je n'ai pas fini..
je vais lui en rajouter une couche !
patience..
ça va être terrible(lol)
cantador
28 sept. 2009 à 18:22
j' ai hésité à poster un commentaire sur cette source...
En fait, c' est le titre qui n' est pas aproprié.
En fait, on fait une liaison d' un DataSet à un autre, les DbGrids ne faisant que montrer les enregistrements disponibles dans ces 2 DataSets via le DataSource.
Pour ce qui est de la source, il est louable de ta part de montrer aux débutants comment faire cela. Ce qui me chiffonne, c' est que sur DelphiFr il existe déjà de nombreux exemples dont des applis plus ou moins complètes et donc, tu as perdu ton temps pour des gens qui ne veulent pas perdre le leur dans une recherche.
Ouai, c' est un coup de gueule! Pas contre toi mais pour ceux qui même avec la nourriture dans leur assiette, il faut encore que quelqu' un leur mette la bouffe à la bouche.
A+
Free Cindy components at http://sourceforge.net/projects/tcycomponents/
27 sept. 2009 à 21:50
C'est une autre histoire...
dont le déroulement n'est pas l'objet de cet exercice..
cantador
27 sept. 2009 à 20:39
le code ne fait que la selection, commment faire pour la mise à jour, l'insertion et la suppression.
Merci
21 sept. 2009 à 14:20
On peut tout à fait les modifier en date ou datetime..
Mais attention, certaines tables sont utilisées dans plusieurs démos et si on change le type des champs alors certains programmes vont planter.
C'est la raison pour laquelle, je n'ai pas modifié la nature de ces derniers.
cantador
21 sept. 2009 à 13:35
Cordialement, Bacterius !
21 sept. 2009 à 11:13
si l'on veut les comparer il faut les convertir..
Mais j'aurais pu simplifier en écrivant directement :
if Query1Saledate.asDateTime < Query1ShipDate.AsDateTime then
Mais faut avouer que le transtypage fait plus d'effet !
merci pour le Smaaaaaakkk !
cantador
21 sept. 2009 à 08:23
Néanmoins, le terme transtypage n'est pas approprié dans la dernière partie du code puisque ton code utilise le résultat de la propriété Text des champs.
Enfin, reconvertir en date une date convertie en chaine n'est pas une opération très performante. Je suis étonné que tu aies fait cela.
21 sept. 2009 à 08:11
J'ai droit à la bise de delphiprog..
20 sept. 2009 à 19:16
le if form1 Nil then exit doit avantageusement être remplacé par if self nil then exit;
L'intérêt, comme tu le sais dans une souce complexe où il y a beaucoup de formes (certaines non créées au démarrage) l'évènement OnDataChange se déclenchant de manière intempestive sur un certain nombre d'actions (notamment en cas de liaisons multiples entre plusieurs table), cette ligne protége d'une erreur.
Quant au paramétrage des composants, c'est effectivement une bonne idée..
Mais il faisait beau, et je me suis fais une petite balade en famille dans les bois.
Et j'aime beaucoup la nature.
cela me délasse et fait du bien..
Diable, delphiprog veille aux grains
Qu'on se le dise aux fonds des ports..
Mais cela dit, dès que je peux je comble le vide.
Cordialement
cantador
20 sept. 2009 à 14:54
Dans cette partie du code :
# procedure TForm1.DataSource1DataChange(Sender: TObject; Field: TField);
# begin
# if Sender = nil then exit;
# if Field <> nil then exit;
# if Form1 = nil then exit;
# if StrToDateTime(Query1SaleDate.Text) < StrToDateTime(Query1ShipDate.Text) then
# ShowMessage('ok');
# end;
A quoi cela sert-il d'écrire :
if Form1 = nil then exit;
Si form1 vaut nil, c'est que la fiche est détruite, non ?
D'autre part, au lieu de form1 et pour que le code soit réutilisable par un copier/coller, il serait préférable d'écrire "if self = nil then...".
Pour que la démonstration soit encore plus parlante, il eût été préférable de réaliser la paramétrage des composants par le code ou alors de réaliser un tuto en parallèle puisque ce code s'adresse avant-tout à des débutants.
19 sept. 2009 à 12:34