VERROUILLEUR D'APPLICATION
cs_jeanr
Messages postés
17
Date d'inscription
vendredi 25 avril 2003
Statut
Membre
Dernière intervention
12 juin 2008
-
5 mai 2006 à 21:00
WhiteHippo Messages postés 1154 Date d'inscription samedi 14 août 2004 Statut Membre Dernière intervention 5 avril 2012 - 25 mai 2006 à 01:37
WhiteHippo Messages postés 1154 Date d'inscription samedi 14 août 2004 Statut Membre Dernière intervention 5 avril 2012 - 25 mai 2006 à 01:37
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/37454-verrouilleur-d-application
https://codes-sources.commentcamarche.net/source/37454-verrouilleur-d-application
25 mai 2006 à 01:37
Je vais creuser l'idée d'un éditeur, histoire de voir ce que je peux en tirer.
Cordialement.
25 mai 2006 à 01:35
Cordialement.
25 mai 2006 à 01:33
J'ai mis à jour le code du composant pour corriger le bug.
Cordialement.
24 mai 2006 à 10:34
si je met toucheswindows--> true et rien d'autre
lors de l'exécution de la fiche si on met l'instructions suivantes:
verouilleur1.active:=true;
ça ne marche pas
que faire???? car quand ont met total ça fonctionne???
merci
13 mai 2006 à 23:08
Super et simple ce composant.
Je place des points au maximum.
Bizzz...
Michèle.
7 mai 2006 à 22:52
Un peut comme la propriété VisibleAtRuntime des dummycube de GLScene, tu pourrait mettre une prop EnabledAtConception ou dans le genre ...
je pense que ce serais vraiment mieux, surtout que la plupart du temps, quand on elabore un programme, il n'est pas rare de devoir "killer" le processus et donc dans ce cas, certain verroux (CtrlAltSup) pourraient rester actif ... ce qui peut etre un probleme.
7 mai 2006 à 06:13
ouai desolé pour les remarques, comme tu le dis, c'est surtout une histoire de conventions ...
tu as les tiennes ... c'est bien ... aprés tout pourquoi pas ... je ne te force en rien ... juste que c'est une mauvaise habitude que tu a pris ... toute proportions gardées. ^^
pour la methodologie hazardeuse, c'etait peut etre un bien grand mots pour definir ce que j'entend par la ... en fait ... il me semble que meme si le probleme est geré efficacement il manque un ... je ne sais quoi ... qui fait que ... peut etre ton indentation de code qui me donne cette inpression... je ne saurais l'expliquer clairement.
pour le registre oui, ça m'a sauter au yeux tout de suite, car j'ai du me demener plusieurs fois contre des virus et trojan qui utilisés cette valeur du registre... donc la connaissant bien et surtout connaissant son effet sur le systeme (blocage non seulement du taskmanager mais egalement de l'adminbox), j'ai tout de suite remarquer que tu n'avais fait aucun control dessus, point trés important qui me semblais urgent de signaler.
Pour les evenements alors, ok, je comprend mieux ton approche et pourquoi tu n'a pas choisi ce genre de methode qui en effet, sont totalement inutile car tout est definit en conception et non en execution (quoique un peu, au moins a la creation et destruction).
Pour la traduction, la on ne serat pas d'accord et il serait dommage de partir sur un troll sans fin avec la fameuse question "write your code in english or not ?"
Mais loin de moi l'idée de faire une apologie elitiste de la langue anglaise dans le code.
C'est jsute peut etre que pour moi l'internationalisation voulue par internet est importante donc j'essaye de traduire au mieux mes identifiant en anglais ... Et si la traduction pose probleme, j'ajoute des explication complete et une trad en commentaire dans les sources de toute façon ... ce qui resoud en partie le probleme des non-anglophones ...
c'est juste qu'on soit francais, allemand, russe ou quoi, l'anglais "de base" et/ou "informatique" est assé comprehensibleet simple...
Tu m'aurais vus sur une Doc TurboPascal sur le ModeX commentée en Allemand avec des identifiant en Allemand egalement ... Doc Rare, introuvable presque ... j'ai du me resigné a ne pas l'utilisée... comme quoi ... et c'est aussi que l'anglais est composé de mots court et simple a retenir qui permettent donc d'ecrire des identifiant court et facilement comprehensible, SetValue, GetValue, ReturnValue, AddItem etc... comme je le dis souvent, imagine en français ou en bielo-russe ... DefinirValeur, RecupererValeur, RenvoyerValeur, AjouterElement ... BERK!
en plus ça rend le code Long et fastidieux a taper et plus c'est long, plus ça augmente les chances de fautes de frappes. Bref que des désaventage d'ecrire des identifiant en une langue autre que l'anglais.
mais bon ... ça ... c'est un soucis personnel ... comme la religion ou le sexe.
Pour ton indentation de code ... ben ... oui ... c'est la tienne quoi ... ^^
Pour le type TVerrou et TVerrous (Set) la aussi c'est une histoire de convention ... libre aprés de suivre ou pas...
les deux methodes fonctionne ... mais n'offre pas le meme lot depossibilitée ...
TFontStyle = (fsBold,fsItalic,fsUnderline,fsStrikeOut);
TFontStyles = set of TFontStyle;
TAsyncStyle =(asRead,asWrite,asOOB,asAccept,asConnect,asClose);
TAsyncStyles = set of TAsyncStyle;
ce qui permet par exemple d'ecrire des methodes de ce genre :
methode(FST : TFontStyle)
methode(ASYN: TAsyncStyle)
un peu comme quand on ecrit :
TCharArray = array of char;
TCharMatrix= array of TCharArray;
et
TCharMatrix = array of array of char;
dans la premiere declaration on pourras utilise le type TCharArray pour traiter les donnée ... dans la deuxieme declaration ... on devras travailler sur toute la matrice.
tu comprend pourquoi j'essaye de te demontrer l'importance de cela (bien que je pense que tu le sache deja).
et donc l'erreur, qui n'est effectivement pas une erreur de compil ou d'execution mais une "erreur" de declaration de type qui oblige une certaine façon d'ecrire le code et de traiter les donnée qui serat donc peu souple...
bien sur, si je dis tout cela, c'est dans le but de mieux comprendre pourquoi tu as fait comme cela mais egalement te donner un avis exterieur qui pourrais te donner des idées ...
voila.
sinon, cela reste bien sur un trés bon code et c'est pour cela que je m'y interresse tant et donc que j'ecris autant de "conneries" sur cette page... ^^
6 mai 2006 à 12:05
Cordialement.
6 mai 2006 à 11:59
je partage l'idée de Emandhal.Les verrous sont aussi fonctionnels dans le concepteur de fiches, ce qui est un problème.
6 mai 2006 à 10:26
FOXI, FOXI, FOXI .... ;P
"correction d'une petite erreur sur le type TVerrous"
- Une erreur !! Le code compile pas ???? Sinon, c'est qu'il n'y a pas d'erreurs :P
"cela permet d'avoir d'un coté les valeurs TVerrou et un Set de ces valeur."
- J'ai VOLONTAIREMENT défini un type ensemble TVerrous pour les verrous !!!
- Quel serait l'intérêt de définir ICI un type TVerrou ? Ils n'ont d'intéret que réunis dans un ensemble.
"ce qui nous permet de faire des tests de ce type : if vAltEsc in Lockers then ..."
- Là tu utilises l'opérateur "in" pour tester l'appartenance, et ??? je le fais déjà dans mon code : "SetVerrouillageAltEsc ( vAltEsc in FVerrous ) ;"
"ps : on ne commence jamais une phrase par une virgule meme en code"
- ça fait longtemps que je n'ai pas participé à la dictée de Pivot. ;P
- Si le code à été formatté de cet façon, il y a, là encore, des raisons. Notamment la clarté, la facilité de modification, etc ...
Je code depuis assez longtemps pour connaitre les conventions dont tu parles, mais au vu de mon experience et d'un codage quasi journalier j'ai fini par adopter MES PROPRES CONVENTIONS de formattage de code.
N.B. Même si je sais que m?opposer à la convention risque de me marginaliser, je le fais à bon escient. Tant pis pour ceux à qui ça ne plait pas.
"ensuite on traduit correctement" :
- Je n'ai rien traduit dans mon code ??? Ce qui est en anglais, reste en anglais, les mots clés, les méthodes héritées, les constantes déjà définies, etc... les SetVerrous et GetVerrous par exemple font partis de MES PROPRES CONVENTIONS de codage ( Je prefere à LireVerrous et EcrireVerrous, c'est tout :)
- L'utilisation de l'anglais dans le code, là encore vaste débat. Je code souvent les méthodes que je rajoute en français, ce qui ne pénalise en rien le code. Ici, on est sur un forum français, ne laissons pas le code à une élite anglophile. De nos jours il y a toujours des gens qui ne pratiquent pas ou alors très mal l'anglais.
"aucune gestion de l'evenementiel"
- Cette remarque je l'attendais :D
- Ce composant est un composant dit "Bas niveau" (pour ce qu'il fait), donc son code est à son effigie. Il n'est pas alourdi par des méthodes qui ne me semblent pas nécessaire.
A chaque fois que je l'ai utilisé, les verrous ont été fixés dans le concepteur et seule l'activation était faite dans le code. On ne passe pas son temps dans une application à modifier les verrous (Basculer le verrouillage du ALT-TAB ou faire apparaitre/disparaitre la barre de tâche) Donc NON pas d'évenements !!!
N.B. Il est cependant facilement modifiable pour vos propres besoins, c'est pour ça qu'il dérive du TComponent ;)
"une methodologie hazardeuse..."
- Le hasard n'a rien à faire dans la programmation, mis à part peut être dans les programmes génétiques.
"bref ... y'a encore du boulot ..." :
- Ca je sais pas trop comment l'interpréter :)
"verifier a la destruction qu'on restaure correctement l'etat du registre pour le taskmanager"
- Entierement d'accord avec toi.
- Pour ma défense, je ne l'ai pas fait car la clé utilisée n'est pas une clé standard de la base de registre, c'est à dire qu'elle n'existe pas d'origine, il faut la créer. Partant de cette idée, je n'ai effectivement pas pensé au cas où elle serait déjà présente. Je vais y remédier.
Cordialement.
6 mai 2006 à 06:16
par exemples :
private
fLockers : TKeyLockers;
fLockAltEsc : boolean
fLockAltTab : boolean
procedure SetLocker(index : integer; value : boolean);
protected
procedure ChangeLockers; virtual;
published
property LockAltEsc : boolean index 0 read fLockAltEsc write SetLocker;
property LockAltTab : boolean index 1 read fLockAltTad write SetLocker;
procedure TClasse.ChangeLockers;
begin
... traitements des verroux ...
end;
procedure TClasse.SetLocker(index : integer; value : boolean);
procedure _Lock(lck : TLockers; Adding : boolean);
begin
if Adding then
fLockers := fLockers + [lck]
else
fLockers := fLockers - [lck];
end;
begin
case Index of
0 : if fLockAltEsc <> Value then
fLockAltEsc := Value;
_Lock(vAltEsc, fLockAltEsc);
ChangeLockers;
end;
1 : if fLockAltTab <> Value then
_Lock(vAltTab, fLockAltTab);
ChangeLockers;
end;
end;
end;
et un dernier truc, bien verifier a la destruction qu'on restaure correctement l'etat du registre pour le taskmanager...
donc il faut sauvegarder son etat avant toute chose et restaurer cet etat tel qui doit l'etre quand on detruit le composant.
6 mai 2006 à 05:59
TKeyLock = (vAltEsc, vAltTab, vCtrlEsc, vCtrlAltSup, vBarreDesTaches, vTouchesMicrosoft);
{ ps : on ne commence jamais une phrase par une virgule meme en code }
TKeyLockers = set of TKeyLock
cela permet d'avoir d'un coté les valeurs TVerrou et un Set de ces valeur.
ce qui nous permet de faire des tests de ce type :
if vAltEsc in Lockers then ...
ensuite on traduit correctement :
(vAltEsc, vAltTab, vCtrlEsc, vCtrlAltSup, vSysTray, vMicrosoftKey);
SetVerrouillageBarreDesTaches > SetLockSysTray
SetVerrouillageTouchesMicrosoft > SetLockMicrosoftKey
SetActif > SetActive
SetVerrouillageTotal > SetLockAll
SetVerrous > SetLockers
pas mal de chose qui ne vont pas, par exemple aucune gestion de l'evenementiel qui pourtant faciliterais le declanchement des methodes, des noms de methode a ralonge (UTILISEZ L'ANGLAIS!)
une methodologie hazardeuse ... bref ... y'a encore du boulot ...
6 mai 2006 à 01:52
J'ajouterai cette ligne au tout début de chaque procedures et fonctions qui créent ce vérrouillage :
If (csDesigning in ComponentState) Then Exit;
Normalement après les touches fonctionneront quand on est dans le concepteur et plus du tout à l'exécution.
5 mai 2006 à 23:21
Cordialement.
5 mai 2006 à 21:32
ce composant ma aide dans mon logiciel de cyber
merci
5 mai 2006 à 21:00