Voilà une question (difficile) que je n'ai jamais bien résolue et je ne
suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
cette garantie est impossible à donner mais on peut néanmoins mettre en
place des mesures préventives. Parmi celles-ci, l'appli essaye de
récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
question que ce mécanisme se déclenche s'il n'y a pas de connexion
active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
connexion active à Internet **et ne pas déclencher autodial**, pour mon
appli seulement bien sûr. Les réglages utilisateurs doivent rester
inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState
(WinInet) mais cette fonction n'est pas fiable et ne correspond pas au
besoin.
Merci d'avance.
--
Patrick Philippot
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Voilà une question (difficile) que je n'ai jamais bien résolue et je ne suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x, cette garantie est impossible à donner mais on peut néanmoins mettre en place des mesures préventives. Parmi celles-ci, l'appli essaye de récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de question que ce mécanisme se déclenche s'il n'y a pas de connexion active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP doit donc tout simplement échouer dans 100% des cas s'il n'y pas de connexion active à Internet **et ne pas déclencher autodial**, pour mon appli seulement bien sûr. Les réglages utilisateurs doivent rester inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState (WinInet) mais cette fonction n'est pas fiable et ne correspond pas au besoin.
Merci d'avance.
J'aborderai le problème différemment en faisant un état des lieux de la machine. Si le poste est paramétré en AutoDial, alors retrouver le profil de connexion par défaut, puis regarder si ce profil est connecté. Ensuite regarder si un des profiles de connexion est connecté. Je pense qu'une autre solution consiste à comptabiliser le nombre d'adresse IP actuellement sur la machine. Si 0 alors ne pas faire de connexion. Si >0 alors désactiver l'autodial, tenter une connexion, réactiver l'autodial (si il était actif). Si le teste est OK, alors détecter que l'adresse IP tombe, sinon détecter qu'une nouvelle adresse IP apparaît. Je ne sais pas comment fonctionne MSN Messenger mais il s'en sort assez bien pour faire cela et se connecte dès qu'Internet est disponible.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Patrick Philippot wrote:
Bonjour,
Voilà une question (difficile) que je n'ai jamais bien résolue et je
ne suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
cette garantie est impossible à donner mais on peut néanmoins mettre
en place des mesures préventives. Parmi celles-ci, l'appli essaye de
récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
question que ce mécanisme se déclenche s'il n'y a pas de connexion
active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
connexion active à Internet **et ne pas déclencher autodial**, pour
mon appli seulement bien sûr. Les réglages utilisateurs doivent rester
inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState
(WinInet) mais cette fonction n'est pas fiable et ne correspond pas au
besoin.
Merci d'avance.
J'aborderai le problème différemment en faisant un état des lieux de la
machine.
Si le poste est paramétré en AutoDial, alors retrouver le profil de
connexion par défaut, puis regarder si ce profil est connecté. Ensuite
regarder si un des profiles de connexion est connecté.
Je pense qu'une autre solution consiste à comptabiliser le nombre d'adresse
IP actuellement sur la machine. Si 0 alors ne pas faire de connexion. Si >0
alors désactiver l'autodial, tenter une connexion, réactiver l'autodial (si
il était actif). Si le teste est OK, alors détecter que l'adresse IP tombe,
sinon détecter qu'une nouvelle adresse IP apparaît.
Je ne sais pas comment fonctionne MSN Messenger mais il s'en sort assez bien
pour faire cela et se connecte dès qu'Internet est disponible.
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
Voilà une question (difficile) que je n'ai jamais bien résolue et je ne suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x, cette garantie est impossible à donner mais on peut néanmoins mettre en place des mesures préventives. Parmi celles-ci, l'appli essaye de récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de question que ce mécanisme se déclenche s'il n'y a pas de connexion active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP doit donc tout simplement échouer dans 100% des cas s'il n'y pas de connexion active à Internet **et ne pas déclencher autodial**, pour mon appli seulement bien sûr. Les réglages utilisateurs doivent rester inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState (WinInet) mais cette fonction n'est pas fiable et ne correspond pas au besoin.
Merci d'avance.
J'aborderai le problème différemment en faisant un état des lieux de la machine. Si le poste est paramétré en AutoDial, alors retrouver le profil de connexion par défaut, puis regarder si ce profil est connecté. Ensuite regarder si un des profiles de connexion est connecté. Je pense qu'une autre solution consiste à comptabiliser le nombre d'adresse IP actuellement sur la machine. Si 0 alors ne pas faire de connexion. Si >0 alors désactiver l'autodial, tenter une connexion, réactiver l'autodial (si il était actif). Si le teste est OK, alors détecter que l'adresse IP tombe, sinon détecter qu'une nouvelle adresse IP apparaît. Je ne sais pas comment fonctionne MSN Messenger mais il s'en sort assez bien pour faire cela et se connecte dès qu'Internet est disponible.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Cyrille \cns\ Szymanski
> Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x, cette garantie est impossible à donner mais on peut néanmoins mettre en place des mesures préventives. Parmi celles-ci, l'appli essaye de récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de question que ce mécanisme se déclenche s'il n'y a pas de connexion active.
Il est peut-être possible de contourner l'autodial en faisant un appel direct à TDI voire à NDIS ? Il faut espérer que l'autodial se place au dessus...
> Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
cette garantie est impossible à donner mais on peut néanmoins mettre en
place des mesures préventives. Parmi celles-ci, l'appli essaye de
récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
question que ce mécanisme se déclenche s'il n'y a pas de connexion
active.
Il est peut-être possible de contourner l'autodial en faisant un appel
direct à TDI voire à NDIS ? Il faut espérer que l'autodial se place au
dessus...
> Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x, cette garantie est impossible à donner mais on peut néanmoins mettre en place des mesures préventives. Parmi celles-ci, l'appli essaye de récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de question que ce mécanisme se déclenche s'il n'y a pas de connexion active.
Il est peut-être possible de contourner l'autodial en faisant un appel direct à TDI voire à NDIS ? Il faut espérer que l'autodial se place au dessus...
> Sinon je verai bien aussi une petite application qui se lance au démarrage de Windows et mémorise l'heure et le GetTickCount() correspondant. Ensuite si tu remarques une dérive entre l'heure et le GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer outre serait de tuer ce daemon ou de booter en DOS pour changer l'heure.
> Sinon je verai bien aussi une petite application qui se lance au
démarrage de Windows et mémorise l'heure et le GetTickCount()
correspondant. Ensuite si tu remarques une dérive entre l'heure et le
GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer
outre serait de tuer ce daemon ou de booter en DOS pour changer
l'heure.
> Sinon je verai bien aussi une petite application qui se lance au démarrage de Windows et mémorise l'heure et le GetTickCount() correspondant. Ensuite si tu remarques une dérive entre l'heure et le GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer outre serait de tuer ce daemon ou de booter en DOS pour changer l'heure.
Voilà une question (difficile) que je n'ai jamais bien résolue et je ne suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système.
Une question bête, qui voudrait d'une application qui empêche de modifier l'heure du système, en particulier pour l'heure d'été/heure d'hiver?
-- Samuel KABAK http://www.codeas.net/ http://www.2b-alive.com/
Patrick Philippot
Remi Thomas wrote:
Sinon je verai bien aussi une petite application qui se lance au démarrage de Windows et mémorise l'heure et le GetTickCount() correspondant. Ensuite si tu remarques une dérive entre l'heure et le GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer outre serait de tuer ce daemon ou de booter en DOS pour changer l'heure.
C'est ce que je fais. Cela marche bien mais cela ne protège pas d'une modif de l'heure via le BIOS ou bien d'une modif après boot sur une disquette DOS. C'est pour cela que je veux, quand c'est possible, faire une rapide mise à jour via SNTP au lancement de l'appli (qui sera un service sous NT/2000/XP).
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne contient aucune entrée de type "Remote Route", c'est que la machine n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est remise à jour dès que la connexion est rompue.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Remi Thomas wrote:
Sinon je verai bien aussi une petite application qui se lance au
démarrage de Windows et mémorise l'heure et le GetTickCount()
correspondant. Ensuite si tu remarques une dérive entre l'heure et le
GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer
outre serait de tuer ce daemon ou de booter en DOS pour changer
l'heure.
C'est ce que je fais. Cela marche bien mais cela ne protège pas d'une
modif de l'heure via le BIOS ou bien d'une modif après boot sur une
disquette DOS. C'est pour cela que je veux, quand c'est possible, faire
une rapide mise à jour via SNTP au lancement de l'appli (qui sera un
service sous NT/2000/XP).
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP
Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne
contient aucune entrée de type "Remote Route", c'est que la machine
n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette
API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est
remise à jour dès que la connexion est rompue.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Sinon je verai bien aussi une petite application qui se lance au démarrage de Windows et mémorise l'heure et le GetTickCount() correspondant. Ensuite si tu remarques une dérive entre l'heure et le GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer outre serait de tuer ce daemon ou de booter en DOS pour changer l'heure.
C'est ce que je fais. Cela marche bien mais cela ne protège pas d'une modif de l'heure via le BIOS ou bien d'une modif après boot sur une disquette DOS. C'est pour cela que je veux, quand c'est possible, faire une rapide mise à jour via SNTP au lancement de l'appli (qui sera un service sous NT/2000/XP).
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne contient aucune entrée de type "Remote Route", c'est que la machine n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est remise à jour dès que la connexion est rompue.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Philippot
Samuel KABAK wrote:
Une question bête, qui voudrait d'une application qui empêche de modifier l'heure du système, en particulier pour l'heure d'été/heure d'hiver?
Les modifs que je fais n'empêcheront pas le système de se mettre à jour au passage été / hiver. Par contre, cette appli est une appli qui est entièrement basée sur des réglages horaires. Pas question de laisser l'utilisateur modifier l'heure système de manière fantaisiste.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Samuel KABAK wrote:
Une question bête, qui voudrait d'une application qui empêche de
modifier l'heure du système, en particulier pour l'heure d'été/heure
d'hiver?
Les modifs que je fais n'empêcheront pas le système de se mettre à jour
au passage été / hiver. Par contre, cette appli est une appli qui est
entièrement basée sur des réglages horaires. Pas question de laisser
l'utilisateur modifier l'heure système de manière fantaisiste.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Une question bête, qui voudrait d'une application qui empêche de modifier l'heure du système, en particulier pour l'heure d'été/heure d'hiver?
Les modifs que je fais n'empêcheront pas le système de se mettre à jour au passage été / hiver. Par contre, cette appli est une appli qui est entièrement basée sur des réglages horaires. Pas question de laisser l'utilisateur modifier l'heure système de manière fantaisiste.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Samuel KABAK
David Scrève a écrit:
"Samuel KABAK" a écrit dans le message de news:
Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système.
Une question bête, qui voudrait d'une application qui empêche de modifier l'heure du système, en particulier pour l'heure d'été/heure d'hiver?
Au hasard : un soft de facturation de temps de connexion Internet dans un cybercafé...
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de la machine et empêcher que l'utilisateur la modifie n'est pas une solution très orthodoxe. Je ne dis pas qu'il ne faut pas l'utiliser. Je dis simplement que ce n'est pas très orthodoxe.
J'ai eu besoin de gérer la date pour mon dernier utilitaire ManSubIE http://www.codeas.net/mansubie/ shareware limité à 3 jours
J'ai préféré utiliser une date incrémentale d'accès au fichier pour deviner que l'utilisateur a changé la date. Mais je n'ai pas touché à l'heure système.
Mais il faut dire que l'informatique n'est pas, comme on pourrait le croire, une science exacte.
-- Samuel KABAK http://www.codeas.net/ http://www.2b-alive.com/
David Scrève a écrit:
"Samuel KABAK" <samuel.kabak@free.fr> a écrit dans le message de news:3F26732A.3010403@free.fr...
Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système.
Une question bête, qui voudrait d'une application qui empêche de
modifier l'heure du système, en particulier pour l'heure d'été/heure
d'hiver?
Au hasard : un soft de facturation de temps de connexion Internet dans un cybercafé...
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de
la machine et empêcher que l'utilisateur la modifie n'est pas une
solution très orthodoxe. Je ne dis pas qu'il ne faut pas l'utiliser. Je
dis simplement que ce n'est pas très orthodoxe.
J'ai eu besoin de gérer la date pour mon dernier utilitaire ManSubIE
http://www.codeas.net/mansubie/
shareware limité à 3 jours
J'ai préféré utiliser une date incrémentale d'accès au fichier pour
deviner que l'utilisateur a changé la date. Mais je n'ai pas touché à
l'heure système.
Mais il faut dire que l'informatique n'est pas, comme on pourrait le
croire, une science exacte.
--
Samuel KABAK
http://www.codeas.net/
http://www.2b-alive.com/
Je travaille actuellement sur une application (C++ / non MFC) qui doit garantir que l'utilisateur ne modifie pas l'heure système.
Une question bête, qui voudrait d'une application qui empêche de modifier l'heure du système, en particulier pour l'heure d'été/heure d'hiver?
Au hasard : un soft de facturation de temps de connexion Internet dans un cybercafé...
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de la machine et empêcher que l'utilisateur la modifie n'est pas une solution très orthodoxe. Je ne dis pas qu'il ne faut pas l'utiliser. Je dis simplement que ce n'est pas très orthodoxe.
J'ai eu besoin de gérer la date pour mon dernier utilitaire ManSubIE http://www.codeas.net/mansubie/ shareware limité à 3 jours
J'ai préféré utiliser une date incrémentale d'accès au fichier pour deviner que l'utilisateur a changé la date. Mais je n'ai pas touché à l'heure système.
Mais il faut dire que l'informatique n'est pas, comme on pourrait le croire, une science exacte.
-- Samuel KABAK http://www.codeas.net/ http://www.2b-alive.com/
Christian ASTOR
Patrick Philippot wrote:
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP doit donc tout simplement échouer dans 100% des cas s'il n'y pas de connexion active à Internet **et ne pas déclencher autodial**, pour mon appli seulement bien sûr. Les réglages utilisateurs doivent rester inchangés (ou être modifiés de manière temporaire).
EnableAutodial (registry, avant/après)
Patrick Philippot wrote:
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
connexion active à Internet **et ne pas déclencher autodial**, pour mon
appli seulement bien sûr. Les réglages utilisateurs doivent rester
inchangés (ou être modifiés de manière temporaire).
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP doit donc tout simplement échouer dans 100% des cas s'il n'y pas de connexion active à Internet **et ne pas déclencher autodial**, pour mon appli seulement bien sûr. Les réglages utilisateurs doivent rester inchangés (ou être modifiés de manière temporaire).
EnableAutodial (registry, avant/après)
Patrick Philippot
Christian ASTOR wrote:
EnableAutodial (registry, avant/après)
Christian,
Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un service tournant sous le compte SYSTEM.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Christian ASTOR wrote:
EnableAutodial (registry, avant/après)
Christian,
Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va
tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un
service tournant sous le compte SYSTEM.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un service tournant sous le compte SYSTEM.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Philippot
Samuel KABAK wrote:
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de la machine et empêcher que l'utilisateur la modifie n'est pas une solution très orthodoxe.
Il ne s'agit pas de gérer une durée. Il s'agit dans cette application de tenir compte de l'heure et de la date **réelles**. Je ne vois pas où est l'orthodoxie ou non là-dedans. Si votre application est par exemple un agenda qui rappelle des RdV à l'heure voulue, si vous décidez que faire confiance à l'heure système n'est pas une solution "orthodoxe", vous pouvez imaginer plusieurs approches qui le sont certainement plus:
1) Mettre en place un timer et sur chaque notification (disons toutes les 5 minutes), demander à l'utilisateur de consulter sa montre (imposer l'achat d'une Rolex au moment de l'acquisition du logiciel - sinon refuser a) de garantir le fonctionnement du programme et b) tout support technique), d'entrer la valeur lue dans une boîte de dialogue et faire ensuite une recherche dans la base de données pour voir si l'heure entrée n'est pas à moins de n minutes d'un RdV enregistré. Penser à inclure l'obligation de changement de la pile de la montre dans le contrat de licence.
2) Faire un dialup automatique de l'horloge parlante toutes les 5 minutes, capturer le son, l'interpréter au travers d'un module multimedia spécialisé, en déduire l'heure courante et procéder comme en (1).
3) Demander à l'utilisateur d'imprimer son agenda et lui rappeler régulièrement de le consulter, il pourrait manquer un RdV.
4) Repérer une horloge publique visible de la fenêtre du bureau de l'utilisateur, braquer sa Webcam dessus, analyser l'image en continu via un logiciel développé spécialement pour les pratiquants de l'orthodoxie horaire et procéder ensuite comme en (1).
5) Joindre à la documentation de l'application un horaire SNCF, ne la vendre qu'à des utilisateurs qui habitent près d'une voie ferrée, leur demander de bien repérer à quelle heure et dans quel sens les trains passent devant chez eux et proposer un système de positionnement des RdV de la journée en association avec les numéros des trains. Solution alternative: vendre une vache avec chaque logiciel et déléguer l'observation des trains au ruminant en question. Brancher le PC sur la vache via des capteurs installés sur ses glandes mammaires analysant sa production laitière. Enregistrer la corrélation entre cette production et le passage des trains (prévoir cette phase dans le logiciel d'installation).
:-)))
On se demande d'ailleurs pourquoi NT / 2000 / XP mettent des verrous de sécurité sur le changement de l'heure système si la modifier n'a aucun impact sur les applis "orthodoxes".
Pour conclure, vous noterez que Visual Studio, par exemple, n'est pas une appli orthodoxe de ce point de vue : si vous modifiez de manière inconsidérée l'heure système, il refusera parfois de recompiler des fichiers que vous avez pourtant modifiés. Aberrant, non? Je pense que Visual Studio, avant toute compilation et sauvegarde de fichier source, devrait émettre une requête SNTP pour mettre à jour l'horloge et si ce n'est pas possible, présenter au développeur un message d'avertissement lui demandant systématiquement de vérifier l'heure de son système.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Samuel KABAK wrote:
Pas besoin, quand le timer est lancé le délai passé est géré en
mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure
de la machine et empêcher que l'utilisateur la modifie n'est pas une
solution très orthodoxe.
Il ne s'agit pas de gérer une durée. Il s'agit dans cette application de
tenir compte de l'heure et de la date **réelles**. Je ne vois pas où est
l'orthodoxie ou non là-dedans. Si votre application est par exemple un
agenda qui rappelle des RdV à l'heure voulue, si vous décidez que faire
confiance à l'heure système n'est pas une solution "orthodoxe", vous
pouvez imaginer plusieurs approches qui le sont certainement plus:
1) Mettre en place un timer et sur chaque notification (disons toutes
les 5 minutes), demander à l'utilisateur de consulter sa montre (imposer
l'achat d'une Rolex au moment de l'acquisition du logiciel - sinon
refuser a) de garantir le fonctionnement du programme et b) tout support
technique), d'entrer la valeur lue dans une boîte de dialogue et faire
ensuite une recherche dans la base de données pour voir si l'heure
entrée n'est pas à moins de n minutes d'un RdV enregistré. Penser à
inclure l'obligation de changement de la pile de la montre dans le
contrat de licence.
2) Faire un dialup automatique de l'horloge parlante toutes les 5
minutes, capturer le son, l'interpréter au travers d'un module
multimedia spécialisé, en déduire l'heure courante et procéder comme en
(1).
3) Demander à l'utilisateur d'imprimer son agenda et lui rappeler
régulièrement de le consulter, il pourrait manquer un RdV.
4) Repérer une horloge publique visible de la fenêtre du bureau de
l'utilisateur, braquer sa Webcam dessus, analyser l'image en continu via
un logiciel développé spécialement pour les pratiquants de l'orthodoxie
horaire et procéder ensuite comme en (1).
5) Joindre à la documentation de l'application un horaire SNCF, ne la
vendre qu'à des utilisateurs qui habitent près d'une voie ferrée, leur
demander de bien repérer à quelle heure et dans quel sens les trains
passent devant chez eux et proposer un système de positionnement des RdV
de la journée en association avec les numéros des trains. Solution
alternative: vendre une vache avec chaque logiciel et déléguer
l'observation des trains au ruminant en question. Brancher le PC sur la
vache via des capteurs installés sur ses glandes mammaires analysant sa
production laitière. Enregistrer la corrélation entre cette production
et le passage des trains (prévoir cette phase dans le logiciel
d'installation).
:-)))
On se demande d'ailleurs pourquoi NT / 2000 / XP mettent des verrous de
sécurité sur le changement de l'heure système si la modifier n'a aucun
impact sur les applis "orthodoxes".
Pour conclure, vous noterez que Visual Studio, par exemple, n'est pas
une appli orthodoxe de ce point de vue : si vous modifiez de manière
inconsidérée l'heure système, il refusera parfois de recompiler des
fichiers que vous avez pourtant modifiés. Aberrant, non? Je pense que
Visual Studio, avant toute compilation et sauvegarde de fichier source,
devrait émettre une requête SNTP pour mettre à jour l'horloge et si ce
n'est pas possible, présenter au développeur un message d'avertissement
lui demandant systématiquement de vérifier l'heure de son système.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de la machine et empêcher que l'utilisateur la modifie n'est pas une solution très orthodoxe.
Il ne s'agit pas de gérer une durée. Il s'agit dans cette application de tenir compte de l'heure et de la date **réelles**. Je ne vois pas où est l'orthodoxie ou non là-dedans. Si votre application est par exemple un agenda qui rappelle des RdV à l'heure voulue, si vous décidez que faire confiance à l'heure système n'est pas une solution "orthodoxe", vous pouvez imaginer plusieurs approches qui le sont certainement plus:
1) Mettre en place un timer et sur chaque notification (disons toutes les 5 minutes), demander à l'utilisateur de consulter sa montre (imposer l'achat d'une Rolex au moment de l'acquisition du logiciel - sinon refuser a) de garantir le fonctionnement du programme et b) tout support technique), d'entrer la valeur lue dans une boîte de dialogue et faire ensuite une recherche dans la base de données pour voir si l'heure entrée n'est pas à moins de n minutes d'un RdV enregistré. Penser à inclure l'obligation de changement de la pile de la montre dans le contrat de licence.
2) Faire un dialup automatique de l'horloge parlante toutes les 5 minutes, capturer le son, l'interpréter au travers d'un module multimedia spécialisé, en déduire l'heure courante et procéder comme en (1).
3) Demander à l'utilisateur d'imprimer son agenda et lui rappeler régulièrement de le consulter, il pourrait manquer un RdV.
4) Repérer une horloge publique visible de la fenêtre du bureau de l'utilisateur, braquer sa Webcam dessus, analyser l'image en continu via un logiciel développé spécialement pour les pratiquants de l'orthodoxie horaire et procéder ensuite comme en (1).
5) Joindre à la documentation de l'application un horaire SNCF, ne la vendre qu'à des utilisateurs qui habitent près d'une voie ferrée, leur demander de bien repérer à quelle heure et dans quel sens les trains passent devant chez eux et proposer un système de positionnement des RdV de la journée en association avec les numéros des trains. Solution alternative: vendre une vache avec chaque logiciel et déléguer l'observation des trains au ruminant en question. Brancher le PC sur la vache via des capteurs installés sur ses glandes mammaires analysant sa production laitière. Enregistrer la corrélation entre cette production et le passage des trains (prévoir cette phase dans le logiciel d'installation).
:-)))
On se demande d'ailleurs pourquoi NT / 2000 / XP mettent des verrous de sécurité sur le changement de l'heure système si la modifier n'a aucun impact sur les applis "orthodoxes".
Pour conclure, vous noterez que Visual Studio, par exemple, n'est pas une appli orthodoxe de ce point de vue : si vous modifiez de manière inconsidérée l'heure système, il refusera parfois de recompiler des fichiers que vous avez pourtant modifiés. Aberrant, non? Je pense que Visual Studio, avant toute compilation et sauvegarde de fichier source, devrait émettre une requête SNTP pour mettre à jour l'horloge et si ce n'est pas possible, présenter au développeur un message d'avertissement lui demandant systématiquement de vérifier l'heure de son système.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
