f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 2022
-
18 août 2007 à 12:20
aminorimos
Messages postés1Date d'inscriptionvendredi 24 août 2007StatutMembreDernière intervention27 août 2007
-
27 août 2007 à 10:16
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
aminorimos
Messages postés1Date d'inscriptionvendredi 24 août 2007StatutMembreDernière intervention27 août 2007 27 août 2007 à 10:16
salut les amis
quelqu'un peut m'aider
je veut programmer un logiciel d'hotel
biensur hotellerie et tourisme
sur la gestion des reservation
mais je n'ai aucune formation sur le tourisme
et l'hotellrie....?????????
Debiars
Messages postés285Date d'inscriptionlundi 16 juin 2003StatutMembreDernière intervention11 février 2018 19 août 2007 à 20:45
@Delphiprog : merci pour les réponses à mes questionnements.
Effectivement, j'aurais dû mettre TBitmap à la place de TGraphic. Je me suis servi, comme base pour ce composant, de la classe que j'utilise dans le prog du Dé qui roule, et cela a échappé à mon oeil fatigué.
Je vais rectifier le tir en attendant de trouver mieux.
Les idées derrière la tête, ça va, ça vient...
J'ai mis celle-là sous forme de composant parce que je n'en avais jamais écrit.
A suivre...
cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 19 août 2007 à 19:09
Voilà un composant qui peut s'avérer utile à condition :
1- qu'on n'ait que des bitmaps à afficher
2- que toutes les images aient la même dimension
C'est un peu restrictif mais Debiars a justifié sa décision et je ne la contesterai pas.
Pourquoi utiliser le type TGraphic dans "ChargerGraphic(UneImage: TGraphic);" ? Cela peut induire en erreur la personne qui croirait que l'on peut injecter n'importe quel type d'image dans le liste. Pourquoi ne pas avoir obligé à transmettre un TBitmap en argument à la place ?
"csDesigning in ComponentState" : comme son nom le suggère, cette propriété indique que le composant est actuellement en cours de dessin.
Bon, je sens que si Debiars a eu besoin de nous pondre un composant, c'est qu'il a une idée derrière la tête...;o)
Debiars
Messages postés285Date d'inscriptionlundi 16 juin 2003StatutMembreDernière intervention11 février 2018 19 août 2007 à 11:26
@foxi : " j'aurais pas vus ça de cette façon ..." ça, je n'en doute pas...;-)
Pour l'index dans AfficheImage, je te suis, ainsi que pour le Refresh.
J'utilise le format bitmap en interne pour la simple raison que toutes les images de mêmes dimensions ont la même taille, ce qui n'est pas le cas avec les jpeg's (j'ai testé), ce qui complique le stockage avec en plus position et taille pour chaque image, à moins que tu ais une autre solution que le TMemoryStream.
"if fTempo <> Valeur then fTempo := Valeur;" je ne vois vraiment pas l'intérêt de la chose, que l'on remplace une valeur par la même valeur, ça ne casse pas trois pattes à un canard.
(csDesigning in ComponentState) je ne connais pas cette bête là, ça fait quoi ?
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 18 août 2007 à 12:20
mmmm ... j'aurais pas vus ça de cette façon ...
et y'a deux ou trois truc qui me chiffoune ... :)
par exemple, la methode AfficheImage necessite un index, index que l'on ne peu pas réellement controler puisque qu'il n'existe pas de methode Count par exemple ...
il faudrait aussi quelques methodes pour vider les images chargée au cas ou ...
ensuite il me semble qu'il est superflus d'appeler le Refresh a la fin de cette methode puisque logiquement, l'assign du bitmap notifie l'objet TImage de la modification (et donc qu'il doit se rafraichir) ...
ensuite tu utilise le format bitmap en interne, soit, mais ne serait il pas judicieux de fournir une alternative (jpeg par exemple) qui prendrais moins de ressource memoire (au cas ou).
il y a aussi un manque de control dans les methodes Set* :
procedure TAnimage.SetTempo(Valeur : Integer);
begin
if fTempo <> Valeur then
fTempo := Valeur;
end;
procedure TAnimage.SetActive(Valeur : boolean);
var
no : integer;
begin
if fActive <> Valeur then
begin
fActive := Valeur;
if not (csDesigning in ComponentState) then
while fActive do
for no := 0 to fNbima-1 do
begin
if not fActive then
exit;
AfficheUneImage(no);
Sleep(fTempo);
Application.ProcessMessages;
end;
end;
end;
mais bon, je peu pas trop "critiquer" puisque j'ai moi même tenter sans succés d'ecrire de tel composant mais aucuns n'est satisfaisant.
27 août 2007 à 10:16
quelqu'un peut m'aider
je veut programmer un logiciel d'hotel
biensur hotellerie et tourisme
sur la gestion des reservation
mais je n'ai aucune formation sur le tourisme
et l'hotellrie....?????????
19 août 2007 à 20:45
Effectivement, j'aurais dû mettre TBitmap à la place de TGraphic. Je me suis servi, comme base pour ce composant, de la classe que j'utilise dans le prog du Dé qui roule, et cela a échappé à mon oeil fatigué.
Je vais rectifier le tir en attendant de trouver mieux.
Les idées derrière la tête, ça va, ça vient...
J'ai mis celle-là sous forme de composant parce que je n'en avais jamais écrit.
A suivre...
19 août 2007 à 19:09
1- qu'on n'ait que des bitmaps à afficher
2- que toutes les images aient la même dimension
C'est un peu restrictif mais Debiars a justifié sa décision et je ne la contesterai pas.
Pourquoi utiliser le type TGraphic dans "ChargerGraphic(UneImage: TGraphic);" ? Cela peut induire en erreur la personne qui croirait que l'on peut injecter n'importe quel type d'image dans le liste. Pourquoi ne pas avoir obligé à transmettre un TBitmap en argument à la place ?
"csDesigning in ComponentState" : comme son nom le suggère, cette propriété indique que le composant est actuellement en cours de dessin.
Bon, je sens que si Debiars a eu besoin de nous pondre un composant, c'est qu'il a une idée derrière la tête...;o)
19 août 2007 à 11:26
Pour l'index dans AfficheImage, je te suis, ainsi que pour le Refresh.
J'utilise le format bitmap en interne pour la simple raison que toutes les images de mêmes dimensions ont la même taille, ce qui n'est pas le cas avec les jpeg's (j'ai testé), ce qui complique le stockage avec en plus position et taille pour chaque image, à moins que tu ais une autre solution que le TMemoryStream.
"if fTempo <> Valeur then fTempo := Valeur;" je ne vois vraiment pas l'intérêt de la chose, que l'on remplace une valeur par la même valeur, ça ne casse pas trois pattes à un canard.
(csDesigning in ComponentState) je ne connais pas cette bête là, ça fait quoi ?
18 août 2007 à 12:20
et y'a deux ou trois truc qui me chiffoune ... :)
par exemple, la methode AfficheImage necessite un index, index que l'on ne peu pas réellement controler puisque qu'il n'existe pas de methode Count par exemple ...
il faudrait aussi quelques methodes pour vider les images chargée au cas ou ...
ensuite il me semble qu'il est superflus d'appeler le Refresh a la fin de cette methode puisque logiquement, l'assign du bitmap notifie l'objet TImage de la modification (et donc qu'il doit se rafraichir) ...
ensuite tu utilise le format bitmap en interne, soit, mais ne serait il pas judicieux de fournir une alternative (jpeg par exemple) qui prendrais moins de ressource memoire (au cas ou).
il y a aussi un manque de control dans les methodes Set* :
procedure TAnimage.SetTempo(Valeur : Integer);
begin
if fTempo <> Valeur then
fTempo := Valeur;
end;
procedure TAnimage.SetActive(Valeur : boolean);
var
no : integer;
begin
if fActive <> Valeur then
begin
fActive := Valeur;
if not (csDesigning in ComponentState) then
while fActive do
for no := 0 to fNbima-1 do
begin
if not fActive then
exit;
AfficheUneImage(no);
Sleep(fTempo);
Application.ProcessMessages;
end;
end;
end;
mais bon, je peu pas trop "critiquer" puisque j'ai moi même tenter sans succés d'ecrire de tel composant mais aucuns n'est satisfaisant.