WALLPAPER ET CALENDRIER
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
-
17 avril 2008 à 02:58
hfr11 Messages postés 20 Date d'inscription mardi 17 décembre 2002 Statut Membre Dernière intervention 8 octobre 2019 - 28 avril 2008 à 13:07
hfr11 Messages postés 20 Date d'inscription mardi 17 décembre 2002 Statut Membre Dernière intervention 8 octobre 2019 - 28 avril 2008 à 13:07
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/46381-wallpaper-et-calendrier
https://codes-sources.commentcamarche.net/source/46381-wallpaper-et-calendrier
28 avril 2008 à 13:07
Après avoir lu ces commentaires...
Petite remarque d'ordre général générée par le ragard d'un administrateur de site :
Un programme qu'aime un administrateur est un programme ou "tout" est paramétrable. Sur un réseau local, sous Windows, chaque utilisateur a ce qu'on appelle "un profil itinérant", un profil enregistré sur un serveur qui est mis à jour à chaque fermeture de session de l'utilisateur et chargé à chaque nouvelle ouverture de session. Pour peu que vous ayez quatre ou cinq applications installées sur vos machines, ce profil devient très rapidement "très lourd".
Quand vous le pouvez, donc, permettez à l'utilisateur de choisir les dossiers où doivent être enregistrés les fichiers nécessaires à l'application... Mieux, permettez, à travers la base de registre, HKEY_USERS\DEFAULT, qu'un administrateur qui installe une application puisse y mémoriser les chemins des dossiers à utiliser par défaut, modifiables ensuite par l'opérateur.
Tout cela parce qu'il nous arrive au sein de l'Education Nationale où nous avons plusieurs dizaine d'utilisateurs censés se connecter sur une même machine, de ne pas pouvoir utiliser certaines applications ne nous permettant pas cette souplesse de gestion de leur utilisation.
Cordialement et pardon si je vous aie ennuyés, bon courage à tous, Patrice
23 avril 2008 à 15:57
Ca me fait chaud au coeur de voir des personnes qui se donnent la peine de me faire profiter de leur compétence juste pour le plaisir d'accueillir un nouveau dans la communauté.
La version corrigée va un peu tarder, pour la bonne raison que nous allons vers les beaux jours ;-) et que mon amie ne comprend pas que je préfère apprendre à programmer que tondre la pelouse. J'ai aussi tant de concepts à assimiler pour faire un programme qui vaille le coup d'être simplement regardé...
Le but ultime est qu'il soit entièrement parametrable, qu'il n'apparaisse que dans le systray (pour pouvoir changer d'image de manière aléatoire) et qu'en positionnant la souris sur certaines dates choisies un hint apparaisse avec la tâche du jour à accomplir (tout en restant dans une image bureau)
souhaitez moi bonne chance !!!
PS Si l'un d'entre vous connait un administrateur du site, proposez lui de sous diviser les codes par rapport à la version de chaque compilateur (ce qui est valable en delphi 7, ne l'était peut être pas en Delphi 3)...
A bientôt
21 avril 2008 à 09:39
Je n'ais plus le temps de developper
mais je suis ravi que ma source est fait des adeptes
Un peu larguer maintenant sur les versions delphi,je n'ais d'ailleurs pas reinstallé ma version delphi depuis un plantage de micro
Bonne continuation dans le developpement
j'essaierais de m'y remettre un jour
@plus
18 avril 2008 à 21:32
- qui arrive ici en février
- qui se dit débutant
- qui poste sa première source en avril
- et qu'en plus elle est de bonne qualité (bien qu'améliorable mais c'est le but)
ça coure pas les rues (surtout ces temps-ci) et j'avoue que ça fait un moment que j'attendais que des gens généreux arrivent!
Donc je vais me permettre une cascade de commentaires à la f0xi:
1. BIENVENUE !
2. Je n'ai pas vu la source originale mais le code retouché est très lisible
3. Quelques remarques cependant :
i. Déjà, appeler ReleaseDC après tout appel à GetDC lorsque tu n'as plus besoin du Device Context
ii. Il existe une fonction DirectoryExists() pour savoir si un répertoire existe ou non
iii. Penser à ne pas mettre de nom de fichier "en dur". Exemple: sur mon ordi, je n'ai pas de lecteur C. Ce que je propose, c'est de demander à ce que les images soient présentes dans un sous-répertoire de celui de l'exécutable.
En effet, tu récupère le nom de fichier de l'exécutable comme ça: ParamStr(0)
Donc son chemin comme ça: ExtractFilePath(ParamStr(0))
Et donc un sous dossier comme ça: Dir := ExtractFilePath(ParamStr(0)) + 'Images\'
iv. Donc tu obtiens ensuite FindFirst(Dir + '*.bmp', faAnyFile, SR)
v. Pour les tableaux dynamiques, c'est assez compliqué ici puisque tu ne connais pas d'avance le nombre de fichiers. Mais tu peux par contre utiliser une TStringList.
Ex:
Files := TStringList.Create;
try
{>> Remplissage }
if FindFirst(...) = 0 then
begin
repeat
Files.Add(Dir + SR.FileName);
FindClose(...);
end;
{>> Choix d'un fichier au hasard }
Randomize;
RandomFile := Files[Random(Files.Count)];
finally
Files.Free; // Libération ! Ne pas oublier !
end;
vi. J'appellerai plutôt boucle1 I pour simplifier. De façon générale, on utilise souvent I, J, K, ... comme indices de boucles for. Ça raccourcit le code est c'est plus lisible pour le coup. Si tu utilises des coordonnées comme boucles, alors ce sera X, Y, Z.
Si jamais il y a ambiguïté, tu peux utiliser quelque chose dans le genre:
for IdxLivre := 0 to NbreLivres - 1 do
begin
...
end;
vii. On évite en général de faire dépasser le code et les commentaire de la colonne 80 tout simplement parce que tout le monde n'a pas un écran de 4000x2000 px !
Cette colonne est marquée par le trait vertical dans l'éditeur tu l'auras remarqué...
Ce qui fait que bien souvent on utilise les commentaires en accolades placés avant le code correspondant, comme sur l'exemple que je t'ai donné au dessus.
viii. On ne met pas plusieurs instructions sur la même ligne ! Donc pas de "Month := 1; Day := 0;" mais deux lignes séparées.
Pourquoi? Pour s'y retrouver, on a (très) vite fait de zapper ce genre de détails.
ix. Pas de majuscules du tout aux mots réservés.
x. Au sujet de l'indentation, comme f0xi l'a expliqué (je ne sais pas si tu avais modifié quelque chose à ce sujet) on indente tout le temps APRES "begin", "repeat" et "case of".
Pour le if, ça dépend s'il y a un begin après ou non.
Ex:
begin
if MonChat.Color <> clRed then
Peindre(MonChat);
end;
begin
if MonChat.Color <> clRed then
begin
Brosser(MonChat);
Peindre(MonChat);
end;
end;
begin
if MonChat.Color <> clRed then
Peindre(MonChat)
else if MonChat.Affame then
Nourrir(MonChat);
end;
xi. On évite de mélanger anglais et français, même si parfois c'est tentant! Donc pad de variable Year et Annee, sinon comment sait-on la différence entre les deux ?
xii. Day := Day + 1 est à remplacer par Inc(Day), plus lisible et rapide en plus. De même pour l'autre et attention à ne pas les mettre sur la même ligne!
xiii. "IF (DayOfTheMonth(Annee)<> 1) THEN" => Les parenthèses autour de la comparaison sont inutiles et les mots réservés sont en majuscules... xiv. "If (Month Month1) and (Day Day1) then" => Là par contre, il ne fait pas les enlever, mai "if" s'écrit en minuscules.
xv.
# TArray1 = Record
# Num : INTEGER;
# Nom : STRING;
# END;
=> sur-utilisation des majuscules !
=> Nom du type peu explicatif, surtout que "array" signifie tableau et que tu déclares ici un enregistrement!
=> Indentation: le "end" (en minuscules) se place au même niveau que TArray1, donc deux espaces depuis la gauche.
xvi. J'ai été super-tatilleux tu l'auras remarqué, mais tout cela combiné te donnera j'en suis convaincu :
* Un code plus lisible, plus joli, plus agréable à lire
* Une audience plus attentive (car je sais pas pour les autres, mais je déteste lire un code mal écrit)
* De meilleures habitudes et donc moins de sources d'erreurs, de blocages, de bugs... bref que du positif.
Sur ce, je te laisse méditer.
A+
Flo
17 avril 2008 à 15:44
y'a longtemps qu'on as pas eu de petits nouveaux comme toi ici.
Pour ce qui est de la notation du code, tu fait comme tu le sens, mais le mieux est d'appliquer les conventions borland, comme ça, tout le monde ecrit le code de façon identique et donc lisible par tous.
L'indentation est quand a elle plus importante que la notation.
Tu peu jeter un oeuil aux sources des top 50 (DelphiProg, Florenth, GrandVizir, Cirec, Japee, Debiars, Mauricio, Caribensila etc) de DelphiFR, faire un tours dans les tutos aussi.
bon courage et bonne continuation.
17 avril 2008 à 09:03
tes critiques et commentaires vont me permettre de progresser (c'est d'ailleurs ce que je sollicitais).
Dès ce soir je m'attelle à corriger la majorité des erreurs que tu signales, bien qu'à titre personnel je préfère mettre les mots réservés en majuscule (mais si ce sont des conventions...)
Je vais également me procurer quelques livres. Pour l'instant ma seule aide (toi même mis à part) à été la touche F1 dans Delphi 6.
17 avril 2008 à 02:58
premier point, Le zip :
pas besoin des fichiers .DOF, .CFG et .DCU
deuxieme point, Les commentaires :
parfait! une source commentée, même avec un code "bancal" c'est toujours mieux!
troisieme point, TForm1.Create :
ON UTILISE JAMAIS LA VARIABLE GLOBALE DE LA FICHE (FORMx) A L'INTERIEUR DE LA CLASSE (TFORMx)!
on utilise Self ou rien tout simplement.
ce qui donne la premiere correction :
procedure TForm1.FormCreate(Sender: TObject);
begin
Top := 0;
Left := 0;
Width := Screen.Width;
Height := Screen.Height;
BorderStyle := bsNone;
end;
Quatrieme point, Indentation du code!
Un code indenté est un code lisible.
l'indentation c'est l'espace et la marge que l'on laisse entre les lignes de codes (methode dite de l'escalier) afin de delimiter chacunes des portions de codes :
procedure ....;[a la ligne]
begin[a la ligne]
[2 espaces]portion de code
[2 espaces]boucle, bloc try, begin etc
[2 espaces]+[2 espaces]portion de code du bloc
[2 espaces]end;
end;
exemple :
function UnTruc(parametres): resultat;
var
n : integer;
UnObjet : Classe;
begin
UnObjet := Classe.Create;
try
for n := 0 to 10 do
begin
UnObjet.Propriété[n] := Parametre[n];
UnObjet.MiseAJours;
end;
finally
UnObjet.Free;
end;
end;
beaucoup plus lisible que :
function UnTruc(parametres): resultat;
var n : integer; UnObjet : Classe;
begin
UnObjet := Classe.Create;
try
for n := 0 to 10 do begin
UnObjet.Propriété[n] := Parametre[n]; UnObjet.MiseAJours;
end;
finally
UnObjet.Free;
end;
end;
Cinquieme point, Les mots réservés :
For, If, Begin, End etc ne sont pas a mettre tout en majuscules!
ça rend le code illisible et ça fait mal au yeux.
exemple bon :
tout en minuscules :
for ... to/downto ... do ...
if ... then ... else ...
repeat ... until
try ... finally ... end
notation "phrase" :
For ... to/downTo ... do
If ... then ... else ...
Repeat ... until
Try ... Finally ... end
remarque la notation en "dos de chameau" du downTo.
c'est la notation la plus utilisé en Delphi, Java et ActionScript.
elle permet de mieux lire les identifiants et mots réservés du langage,
et donc le code.
exemples illisibles donc déconseillés :
networkcablestatus
NETWORKCABLESTATUS
exemples lisibles donc conseillés :
NetworkCableStatus -> notation Delphi/VB/Java
NETWORK_CABLE_STATUS -> notation C/C++/Microsoft
networkCableStatus -> notation AS
network_cable_status -> notation quelquonque mais valable.
Sixiemement, les longues imbrication de IF THEN ELSE :
on peut les remplacer la plupart du temps par un Case ... Of.
case Bcl1 of
1..3 : Ordo[Bcl1].Y := 010;
4..6 : Ordo[Bcl1].Y := 180;
7..9 : Ordo[Bcl1].Y := 350;
else
Ordo[Bcl1].Y := 520;
end;
case (Blc1 mod 3) of
1 : Ordo[Bcl1].X := Screen.Width - 555;
2 : Ordo[Bcl1].X := Screen.Width - 370;
else
Ordo[Bcl1].X := Screen.Width - 185;
end;
Les cases sont plus performantes et moins lourdes de code que les long if then else a la chaine.
Septiemement, Objet, creation/liberation en bloc sécurisé :
cela evite les Leak lors d'erreur du programme. si delphi nous mache beaucoup le travail dans les creations et liberation d'objet, il vaut toujours mieux sécuriser les blocs afin d'assurer la liberation d'objet, de reference ou de pointeur afin de laisser une memoire toujours clean aprés l'arret de notre programme.
donc :
Bmp := TBitmap.Create;
try
(... code ...)
finally
Bmp.Free; {ou FreeAndNil(Bmp) }
end;
cela nous assure la liberation de Bmp même en cas d'exception du programme.
Huitiemement, sortie "propre" du programme :
Eteindre un PC en coupant l'alimentation, ça marche. c'est bourrin mais le resultat et que le PC est eteint.
par contre, ça peut bousiller les disques durs, voir la carte mere.
Pour un programme c'est pareils. Application.Terminate c'est bien, mais c'est a réserver pour l'extinction du programme lors d'un cas d'erreur particulier (ressource manquante, condition d'execution non remplie), certe les risques materiels sont quasi-inexistant, par contre cela peut etre risqué pour les données.
Pour quitter un programme proprement, il faut appeler la methode Close de la fiche principale.
soit ici a la fin de ta routine :
Self.Close;
ou tout simplement
Close;
cela permet de conserver la chaine évènementielle de la fermeture des fiches.
pour ce qui est de ça :
DeskTopHandle := GetDeskTopWindow;
DeviceContext := GetDC(DeskTopHandle);
GetDesktopWindow renvois le handle du bureau windows, en gros, la reference a l'objet correspondant a ce dernier.
GetDC quand a lui, fournit, si il existe, la reference au contexte de dessin d'un objet selon son handle. donc la zone ou l'on peut dessiner.
on peut même dans certain cas faire abstraction d'une variable pour le handle de la fiche en faisant tout simplement :
DesktopDC := GetDC(GetDesktopWindow);