Salut à tous !

bon en fait voila j´ai fais un programme, je l´ai proteger par mot de passe.

Admettons que l´utilisateur soit enregistré, on creer une clé d

dsl j´ai appuuer sur ENTER avant d´avoir fini le mss.

bon je continue :
Admettons que l´utilisateur soit enregistré, on creer une clé dans le registre patati . ...

Mais maintent fo que quand il relance le programme le statut soit ´ ENREGISTRE ´.

Mais comment faire pour que le programme sache qui l´est enregistré ?

Fo qu´e je mette en Oncreate le evénements qui vérifient si on est enregistré ? ( lequels je sais pas ! mais a part voir si la clé existe avec filesexist je sais pas quoi faire mais je pense que ma maniere est nulle ! si vous en avez d´autres . .. )

et qu´a chaque fois qu´il clique sur une fonction du programme que je mette :

Si il n´est pas enregistré alors on affiche un message mais si il l´est alors on effectue c´ette action ? ?

ya pas un autre moyeN ? ?

illuzmax@free.fr - ou sur le forum @+

à la base non,
il doit y avoir un fichier quelquepart ( ou une clef dans la base des registres) qui dise au programme qu´il est enregistré ( certain programme se modifie eux même aussi).

ensuite le plus simple est de désactiver tout toutes les fonctions qui en peuvent pas servir si le programme n´est pas enregistré ( mettre les menu en gris quoi) pour pas avoir besoin de gérer ça.

Nico,

Il y a autant de manières de vérifier le bon enregistrement d´un password qu´il y a de programmeurs.... Chacun sa méthode.
Par contre, plutôt que d´appeler une procédure à chaque action de l´utilisateur, tu peux te créer une procedure quelconque et utiliser le TApplication.Idle qui est appellé à chaque temps mort de l´application et donc dans ton TForm.OnCreate, tu places Application.OnIdle:= ta_procedure.

et ça sers à quoi une procédure qui s´appelle au temps mort ?

ce que nico voulait c´est un truc qui vérifie à chaque action si elle peut être exécuté.

dnob, plutôt que de gérer chaque évènement de l´utilisateur, ce qui peut s´avérer lourd en fonction de l´application, il est plus pratique d´utiliser les temps morts de celles-ci ce qui permet au programmeur de ne gérer qu´un seul évènement ( TApplication.OnIdle), le programme se chargeant des multiples appels lui même.

dans la vraie vie t´es un politicien ?

je veux dire, je sais ce que c´est que le multithreading, je sais poruquoi on peut vouloir exploiter le " temps mort" d´une applicacation, mais là, avec ce problème d´enregistrement, quel est le rapport ?

Nico à demandé:
---------------
et qu´a chaque fois qu´il clique sur une fonction du programme que je mette :

Si il n´est pas enregistré alors on affiche un message mais si il l´est alors on effectue c´ette action ? ?

ya pas un autre moyeN ? ?
----------------
En gros, je réponds à sa question " Oui il y a un autre moyen".

ce que je te demande c´est en gros, quel est le rapport, disont que l´utilisateurs clique sur une fonction qu´il n´a pas le droit d´utiliser. que se passe-t-il ?

En plus, je ne suis pas sur de ce que j´avance mais, j´aurais tendance à penser qu´une personne qui s´amuserait à tracer le programme aurait plus de facilité à repérer les endroits de tests si ceux-ci sont à des endroits fixes, style déclenchés par un évènement utilisateur.

tu ne répond pas à ma question,

peut tu m´expliquer ( juste par ce que je ne comprend pas ce que tu veux dire) le rapport entre la question et ta solution.

que ce passe-t-il lorsque l´utilisateur clique sur une fonction à laquel il n´a pas le droti d´acceder et qu´une fenêtre doit s´ouvrir pour le lui notifier ?

Remettons les pendules à l´heure, toi tu pars de la solution proposée par Nico ( Signifier à l´utilisateur qu´il n´a pas le droit d´utiliser une option mais lui laisser tout de même la liberté de cliquer sur l´option).
Moi je pars d´une solution qui est de bloquer les fonctions interdites à l´utilisateur ( en grisant les items du menu ou les boutons de la barre d´outils).
Comme on ne parle pas de la même solution, il est clair qu´il n´y a pas de rapport entre la tienne et la mienne si ce n´est la vérification des droits.
En résumé, pour répondre à ta question, ben quand l´utilisateur clique sur une fonction à laquelle il n´a pas le droit, il ne se passe rien avec ma solution ou alors il faudrait déclencher un appel forcé à l´Idle ce qui est franchement nase.

ah ok, en fait on disait à peu près la même chose, seuf que je lui est conseillé de grisé les menu dans le TForm.OnCreate ce qui est me semble-t-il plus logique que dans une procédure dont on ne sait pas quand est ce qu´elle va s´exécuter.

surtout que ce genre de procédure est faite pour des tâche de fonc pendant toute la durée de vie du programme.
Une fois qu´on a grisée les menu cette procédure est devenu inutile.

J´avais l´impression que tu parlais d´informer l´utilisateur lorsqu´il cliquait sur une option interdite.

ben si elle sont grisé, tu ne peut pas car aucun événement ne se produit lorsqu´on clique dessus ( fonction Idle ou pas fonction Idle).

Mais si elle ne sont pas grisée dans ce cas là, je ne vois toujours pas le rapport entre ( le clique sur une fonction qui ne s´exécutera pas) et ( la fonction idle) ( enfin celle qui s´exécute pendant le temps mort).

Oui justement je sais bien qu´un composant dont la propriété Enabled est à false n´est pas cliquable et donc je ne vois pas comment informer l´utilisateur comme le souhaitait Nico enfin j´ai l´impression que l´on tourne en rond tous les 2 sur ce coup là.
Quoiqu´il en soit avec tout ça je pense que Nico aura compris 2 des multiples possibilités.

MAIS NON JUSTEMENT ! !!!! ( enfin, oui, on tourne en rond, mais non, moi en tout cas j´ai pas compris ta méthode)

Pour l´instant tu n´a pas encore dit UNE SEULE FOIS ce que tu voulais faire avec ta procédure OnIdle, ou alors tu voulais griser les menu avec ( ce qui ne sers à rien, il vaut mieux le faire dans OsCreate) ?

je ne me fache pas, j´essaye juste d´être clair car tu répond à coté de ma question depuis a peu près 15 post.

la question est donc :
que fait la procédure OnIdle dans ton exemple ( pas en général, mais dans ce problème bien particulier).

Plutot que de vérifier à chaque action si l´utilisateur est enregistré,pourquoi ne pas faire le test au démarrage de l´appli , et passer le résultat de ce test(un booléen) sous forme de property à la forme principale,il n´y aurai alors qu´à tester ce booléen et le passer en property aux autres formes qui auraient besoin de ce test.

Le test proprement dit n´est fait qu´une seule , et c´est juste le résultat qui est propagé et testé.

Dnob, pour en finir sur ce sujet, l´Idle dans cet exemple sert à tester l´enregistrement ou non de l´utilisateur et ce de manière aléatoire à l´instar de certains softs.
C´est une méthode de protection comme une autre.
Nico parlait d´une méthode qui fait le test lors d´une action utilisateur / Moi j´utilise l´Idle pour le faire de manière intempestive ce qui est bien évidemment inutile ( pour te rejoindre) si Nico opte pour la solution de figer les options au lancement de l´application.

ba merci vous 3 ! mais y´avais pas a se tirer la bourre !