Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Attendre un moment

13 réponses
Avatar
Annie L.
Je cherche à faire attendre mon application pendant un certain temps
(secondes, centième ou millième de secondes)

Pas de thread car j'attends que quelques secondes!

Quelqu'un aurait-il une solution ?

Merci de vos réponses!

3 réponses

1 2
Avatar
Guillaume Davion
On 12 fév, 20:39, Annie L. wrote:
En éseau je ne peux pas travailler avec une "très faible probabilité de
collision" parce que cela va engendrer des erreurs d'enregistrements et qu e
des clients mécontents vont appeler pour se plaindre et il faut éviter cela à
tout prix.
Ma méthode repose sur des centièmes et des millièmes de seconde pour générer
mes CodeID et je n'ai jamais eu de problèmes auparavant (pendant 5 ans) !!!!
On ne me signale aucuns problèmes concernant ma version réseau, aucune
collision, même pratiquement aucun traffic réseau!!

Ce que je voulais dans ce "post" ne concerne même pas ce que j'ai décr it
ci-haut!!
Ce que je voulais c'est d'attendre un certain temps avant de poursuivre un
traitement et que "Threading..." me cause des problèmes selon l'utilisat ion
que je veux en faire !!! J'ai décidé de conserver ma méthode qui fon ctionne
très bien même s'il y a des façons plus élégante de le faire mai s cela ne
fonctionne pas dans mon cas !

Merci !



"Patrice" wrote:
> D'où justement l'intérêt du GUID qui permet de créer des identif iants à
> n'importe quel moment, à n'importe quel endroit (avec en pratique une
> probabilité de collision quasi nulle)
> (http://msdn2.microsoft.com/fr-fr/library/system.guid.aspx).

> Après ton approche fonctionnera sans doute aussi très bien avec sans doute
> une très faible probabilité de collision.

> Thread.Sleep pause le thread courant. Attention à DoEvents qui pourrai t
> avoir des effets également (en laissant d'autres évènements être traités).

> --
> Patrice

> "Annie L." a écrit dans le message de
>news: E10A3293-160F-4E7D-89AD-0769D8396__BEGIN_MASK_n#9g02mG7!__...__END_ MASK_i?a63jfAD$
> > Il faut vivre le problème pour comprendre pourquoi je me base sur la date
> > et
> > l'heure pour créer des "CodeID" Si je te parle d'une version résea u avec
> > plus
> > de 20 postes qui font des factures en même temps !!!!!!!!!!
> > Récupérer des numéros pour savoir où on est rendu dans le code Id et durant
> > ce temps quelqu'un d'autre a déjà pris ce numéro (EN RÉSEAU) ! !!!!

> > Je viens de me rendre compte que "Threading.Thread.Sleep" me cause
> > d'autres
> > problèmes!!!! Je me dois de revenir à mon ancienne méthode qui d 'ailleurs
> > fonctionne très bien et ne me cause pas de problèmes!!!  (voir p ost plus
> > haut)

> > Merci!

> > "Patrice" wrote:

> >> Difficile à dire sans voir le code *minimum* qui montre le problè me.

> >> Exemple :

> >>   For i As Integer = 0 To 10
> >>             Debug.WriteLine(Date.Now.Ticks)
> >>             System.Threading.Thread.Sleep(1000)
> >>         Next

> >> Personnellement je ne me baserais pas sur la date et l'heure mais sur un
> >> compteur ou un GUID pour pouvoir créer ces lignes aussi rapidement que
> >> possible..

> >> --
> >> Patrice

> >> "Annie L." a écrit dans le messa ge de
> >>news: 34FA4C70-5F66-4302-B4D4-68599749A__BEGIN_MASK_n#9g02mG7!__...__E ND_MASK_i?a63jfAD$
> >> > Donc, si je comprends bien, je veux attendre 1 seconde =
> >> > Threading.Thread.Sleep(1000)      tout simplement !!!!

> >> > Et pourtant après avoir fait des tests, cela ne fonctionne pas pa r
> >> > rapport
> >> > à
> >> > ce que je veux faire!!!!! Je m'explique :  lorsque j'ajoute des
> >> > produits
> >> > dans
> >> > une facture, je crée un "CodeID" qui se sert de l'heure système et date
> >> > du
> >> > jour et j'appelle la fonction ci-dessous "AttendreDelai" sinon il y a
> >> > plusieurs produits qui ont le même "CodeID" car l'ordinateur est très
> >> > rapide.
> >> > C'est pourquoi avec cette fonction "AttendreDelai = 0.01" fait qu e tous
> >> > mes
> >> > "CodeID" sont tous différents!
> >> > J'essai le même procédé avec "Threading.Thread.sleep(1000)" e t tous mes
> >> > "CodeID" de produits sont presque identiques!!!
> >> > Voilà pourquoi cela ne fonctionne pas !!!!   Pourquoi donc ???? ??

> >> > Merci de vos réponses!

> >> > "Bill2" wrote:

> >> >> Annie L. wrote:
> >> >> > Voici ce que j'ai trouvé :
> >> >> >   Public Sub AttendreDelai(ByVal TempsSeconde As Double)
> >> >> >      Dim dblTempsAttente As Double = 0
> >> >> >      dblTempsAttente = Environment.TickCount + TempsSeco nde
> >> >> >      While Environment.TickCount < dblTempsAttente
> >> >> >         Application.DoEvents()
> >> >> >      End While
> >> >> >   End Sub

> >> >> > Mais cette méthode me cause certain problème, et elle est co nçu en
> >> >> > VB
> >> >> > 2003 !! Voici la même méthode conçu en VB 2005 :

> >> >> >   Public Sub AttendreDelai(ByVal TempsSeconde As Double)
> >> >> >      Dim dblTempsAttente As Double = 0
> >> >> >      dblTempsAttente = My.Computer.Clock.TickCount + Tem psSeconde
> >> >> >      While My.Computer.Clock.TickCount < dblTempsAttente
> >> >> >         My.Application.DoEvents()
> >> >> >      End While
> >> >> >   End Sub

> >> >> > Il y a juste un hic!!! il me donne une erreur sur "DoEvents" !!!
> >> >> > Est-ce qu'il me manque une un "Imports" ?  Pourtant j'ai essay é
> >> >> > différentes options et cela ne fonctionne pas du tout avec
> >> >> > "DoEvents"


Je pense qu'il y a plus de chance qu'un client gagne le gros lot à
l'Euromillion qu'il y ait une collision entre deux guid identiques...
Après, si cela représente malgré tout un trop gros risque,
effectivement ok.


> >> >> > Merci de vos réponses!

> >> >> pourquoi réinventer la roue ?
> >> >> il y a Threading.Thread.sleep()
> >> >> qui prend en paramètre un nb de millisecondes ...
> >> >> ça devrait faire l'affaire, non ?

> >> >> --
> >> >> Bill2
> >> >> Utilisez Process Manager, gestionnaire de processus automatique :
> >> >>http://www.bill2-software.com/processmanager/- Masquer le texte des messages précédents -

- Afficher le texte des messages précédents -


Avatar
Patrice
Quand je dis très faible c'est pour un mathématicien. Pour le commun des
mortels, elle est nulle... Enfin peu importe comme ta solution fonctionne.

Je voulais en fait plutôt mettre l'accent sur l'utilisation du DoEvents dans
cette fameuse boucle ce qui autorise les évènements à être traités (mais
c'est peut-être pour cela que tu la place dans ta boucle d'attente). Si ce
n'est pas fait justement pour cela, note que si l'utilisateur clique par
exemple sur un bouton, cet évènement pourra être éventuellement traité
pendant l'appel à DoEvents.

--
Patrice


"Annie L." a écrit dans le message de
news:
En éseau je ne peux pas travailler avec une "très faible probabilité de
collision" parce que cela va engendrer des erreurs d'enregistrements et
que
des clients mécontents vont appeler pour se plaindre et il faut éviter
cela à
tout prix.
Ma méthode repose sur des centièmes et des millièmes de seconde pour
générer
mes CodeID et je n'ai jamais eu de problèmes auparavant (pendant 5 ans)
!!!!
On ne me signale aucuns problèmes concernant ma version réseau, aucune
collision, même pratiquement aucun traffic réseau!!

Ce que je voulais dans ce "post" ne concerne même pas ce que j'ai décrit
ci-haut!!
Ce que je voulais c'est d'attendre un certain temps avant de poursuivre un
traitement et que "Threading..." me cause des problèmes selon
l'utilisation
que je veux en faire !!! J'ai décidé de conserver ma méthode qui
fonctionne
très bien même s'il y a des façons plus élégante de le faire mais cela ne
fonctionne pas dans mon cas !

Merci !

"Patrice" wrote:

D'où justement l'intérêt du GUID qui permet de créer des identifiants à
n'importe quel moment, à n'importe quel endroit (avec en pratique une
probabilité de collision quasi nulle)
(http://msdn2.microsoft.com/fr-fr/library/system.guid.aspx).

Après ton approche fonctionnera sans doute aussi très bien avec sans
doute
une très faible probabilité de collision.

Thread.Sleep pause le thread courant. Attention à DoEvents qui pourrait
avoir des effets également (en laissant d'autres évènements être
traités).

--
Patrice

"Annie L." a écrit dans le message de
news:
> Il faut vivre le problème pour comprendre pourquoi je me base sur la
> date
> et
> l'heure pour créer des "CodeID" Si je te parle d'une version réseau
> avec
> plus
> de 20 postes qui font des factures en même temps !!!!!!!!!!
> Récupérer des numéros pour savoir où on est rendu dans le codeId et
> durant
> ce temps quelqu'un d'autre a déjà pris ce numéro (EN RÉSEAU) !!!!!
>
> Je viens de me rendre compte que "Threading.Thread.Sleep" me cause
> d'autres
> problèmes!!!! Je me dois de revenir à mon ancienne méthode qui
> d'ailleurs
> fonctionne très bien et ne me cause pas de problèmes!!! (voir post
> plus
> haut)
>
>
> Merci!
>
>
> "Patrice" wrote:
>
>> Difficile à dire sans voir le code *minimum* qui montre le problème.
>>
>> Exemple :
>>
>> For i As Integer = 0 To 10
>> Debug.WriteLine(Date.Now.Ticks)
>> System.Threading.Thread.Sleep(1000)
>> Next
>>
>>
>> Personnellement je ne me baserais pas sur la date et l'heure mais sur
>> un
>> compteur ou un GUID pour pouvoir créer ces lignes aussi rapidement que
>> possible..
>>
>> --
>> Patrice
>>
>> "Annie L." a écrit dans le message
>> de
>> news:
>> > Donc, si je comprends bien, je veux attendre 1 seconde >> >> > Threading.Thread.Sleep(1000) tout simplement !!!!
>> >
>> > Et pourtant après avoir fait des tests, cela ne fonctionne pas par
>> > rapport
>> > à
>> > ce que je veux faire!!!!! Je m'explique : lorsque j'ajoute des
>> > produits
>> > dans
>> > une facture, je crée un "CodeID" qui se sert de l'heure système et
>> > date
>> > du
>> > jour et j'appelle la fonction ci-dessous "AttendreDelai" sinon il y
>> > a
>> > plusieurs produits qui ont le même "CodeID" car l'ordinateur est
>> > très
>> > rapide.
>> > C'est pourquoi avec cette fonction "AttendreDelai = 0.01" fait que
>> > tous
>> > mes
>> > "CodeID" sont tous différents!
>> > J'essai le même procédé avec "Threading.Thread.sleep(1000)" et tous
>> > mes
>> > "CodeID" de produits sont presque identiques!!!
>> > Voilà pourquoi cela ne fonctionne pas !!!! Pourquoi donc ??????
>> >
>> > Merci de vos réponses!
>> >
>> > "Bill2" wrote:
>> >
>> >> Annie L. wrote:
>> >> > Voici ce que j'ai trouvé :
>> >> > Public Sub AttendreDelai(ByVal TempsSeconde As Double)
>> >> > Dim dblTempsAttente As Double = 0
>> >> > dblTempsAttente = Environment.TickCount + TempsSeconde
>> >> > While Environment.TickCount < dblTempsAttente
>> >> > Application.DoEvents()
>> >> > End While
>> >> > End Sub
>> >> >
>> >> > Mais cette méthode me cause certain problème, et elle est conçu
>> >> > en
>> >> > VB
>> >> > 2003 !! Voici la même méthode conçu en VB 2005 :
>> >> >
>> >> > Public Sub AttendreDelai(ByVal TempsSeconde As Double)
>> >> > Dim dblTempsAttente As Double = 0
>> >> > dblTempsAttente = My.Computer.Clock.TickCount + TempsSeconde
>> >> > While My.Computer.Clock.TickCount < dblTempsAttente
>> >> > My.Application.DoEvents()
>> >> > End While
>> >> > End Sub
>> >> >
>> >> > Il y a juste un hic!!! il me donne une erreur sur "DoEvents" !!!
>> >> > Est-ce qu'il me manque une un "Imports" ? Pourtant j'ai essayé
>> >> > différentes options et cela ne fonctionne pas du tout avec
>> >> > "DoEvents"
>> >> >
>> >> > Merci de vos réponses!
>> >> >
>> >>
>> >> pourquoi réinventer la roue ?
>> >> il y a Threading.Thread.sleep()
>> >> qui prend en paramètre un nb de millisecondes ...
>> >> ça devrait faire l'affaire, non ?
>> >>
>> >> --
>> >> Bill2
>> >> Utilisez Process Manager, gestionnaire de processus automatique :
>> >> http://www.bill2-software.com/processmanager/
>> >>
>> >>
>> >>
>>
>>
>>







Avatar
jerome crevecoeur
Bizarre cette façon de faire.
Même si ça marche dans le meilleur des mondes.

J'aurais préconisé soit un numéro auto dans la base de données. ( 20
utilisateurs, y a bien une base de données hein?)

Soit d'imputer la clé primaire sur deux champ:
NumeroFacture + NumeroligneFacture
FA0001 : 1
FA0001 : 2
FA0001 : 3

FA0002 : 1
FA0002 : 2

Je ne vois pas dans quel cas ces deux solutions ne marche pas...





Patrice a écrit :
Quand je dis très faible c'est pour un mathématicien. Pour le commu n des
mortels, elle est nulle... Enfin peu importe comme ta solution fonction ne.

Je voulais en fait plutôt mettre l'accent sur l'utilisation du DoEven ts dans
cette fameuse boucle ce qui autorise les évènements à être trai tés (mais
c'est peut-être pour cela que tu la place dans ta boucle d'attente). Si ce
n'est pas fait justement pour cela, note que si l'utilisateur clique pa r
exemple sur un bouton, cet évènement pourra être éventuellement traité
pendant l'appel à DoEvents.

--
Patrice


"Annie L." a écrit dans le message de
news:
En éseau je ne peux pas travailler avec une "très faible probabili té de
collision" parce que cela va engendrer des erreurs d'enregistrements e t
que
des clients mécontents vont appeler pour se plaindre et il faut év iter
cela à
tout prix.
Ma méthode repose sur des centièmes et des millièmes de seconde pour
générer
mes CodeID et je n'ai jamais eu de problèmes auparavant (pendant 5 a ns)
!!!!
On ne me signale aucuns problèmes concernant ma version réseau, au cune
collision, même pratiquement aucun traffic réseau!!

Ce que je voulais dans ce "post" ne concerne même pas ce que j'ai dé crit
ci-haut!!
Ce que je voulais c'est d'attendre un certain temps avant de poursuivr e un
traitement et que "Threading..." me cause des problèmes selon
l'utilisation
que je veux en faire !!! J'ai décidé de conserver ma méthode qui
fonctionne
très bien même s'il y a des façons plus élégante de le faire mais cela ne
fonctionne pas dans mon cas !

Merci !

"Patrice" wrote:

D'où justement l'intérêt du GUID qui permet de créer des iden tifiants à
n'importe quel moment, à n'importe quel endroit (avec en pratique u ne
probabilité de collision quasi nulle)
(http://msdn2.microsoft.com/fr-fr/library/system.guid.aspx).

Après ton approche fonctionnera sans doute aussi très bien avec s ans
doute
une très faible probabilité de collision.

Thread.Sleep pause le thread courant. Attention à DoEvents qui pour rait
avoir des effets également (en laissant d'autres évènements ê tre
traités).

--
Patrice

"Annie L." a écrit dans le messa ge de
news:
Il faut vivre le problème pour comprendre pourquoi je me base sur la
date
et
l'heure pour créer des "CodeID" Si je te parle d'une version rés eau
avec
plus
de 20 postes qui font des factures en même temps !!!!!!!!!!
Récupérer des numéros pour savoir où on est rendu dans le co deId et
durant
ce temps quelqu'un d'autre a déjà pris ce numéro (EN RÉSEAU) !!!!!

Je viens de me rendre compte que "Threading.Thread.Sleep" me cause
d'autres
problèmes!!!! Je me dois de revenir à mon ancienne méthode qui
d'ailleurs
fonctionne très bien et ne me cause pas de problèmes!!! (voir p ost
plus
haut)


Merci!


"Patrice" wrote:

Difficile à dire sans voir le code *minimum* qui montre le problè me.

Exemple :

For i As Integer = 0 To 10
Debug.WriteLine(Date.Now.Ticks)
System.Threading.Thread.Sleep(1000)
Next


Personnellement je ne me baserais pas sur la date et l'heure mais s ur
un
compteur ou un GUID pour pouvoir créer ces lignes aussi rapidemen t que
possible..

--
Patrice

"Annie L." a écrit dans le mes sage
de
news:
Donc, si je comprends bien, je veux attendre 1 seconde =
Threading.Thread.Sleep(1000) tout simplement !!!!

Et pourtant après avoir fait des tests, cela ne fonctionne pas p ar
rapport
à
ce que je veux faire!!!!! Je m'explique : lorsque j'ajoute des
produits
dans
une facture, je crée un "CodeID" qui se sert de l'heure systèm e et
date
du
jour et j'appelle la fonction ci-dessous "AttendreDelai" sinon il y
a
plusieurs produits qui ont le même "CodeID" car l'ordinateur est
très
rapide.
C'est pourquoi avec cette fonction "AttendreDelai = 0.01" fait q ue
tous
mes
"CodeID" sont tous différents!
J'essai le même procédé avec "Threading.Thread.sleep(1000)" et tous
mes
"CodeID" de produits sont presque identiques!!!
Voilà pourquoi cela ne fonctionne pas !!!! Pourquoi donc ????? ?

Merci de vos réponses!

"Bill2" wrote:

Annie L. wrote:
Voici ce que j'ai trouvé :
Public Sub AttendreDelai(ByVal TempsSeconde As Double)
Dim dblTempsAttente As Double = 0
dblTempsAttente = Environment.TickCount + TempsSeconde
While Environment.TickCount < dblTempsAttente
Application.DoEvents()
End While
End Sub

Mais cette méthode me cause certain problème, et elle est co nçu
en
VB
2003 !! Voici la même méthode conçu en VB 2005 :

Public Sub AttendreDelai(ByVal TempsSeconde As Double)
Dim dblTempsAttente As Double = 0
dblTempsAttente = My.Computer.Clock.TickCount + TempsSeco nde
While My.Computer.Clock.TickCount < dblTempsAttente
My.Application.DoEvents()
End While
End Sub

Il y a juste un hic!!! il me donne une erreur sur "DoEvents" !!!
Est-ce qu'il me manque une un "Imports" ? Pourtant j'ai essayé
différentes options et cela ne fonctionne pas du tout avec
"DoEvents"

Merci de vos réponses!



pourquoi réinventer la roue ?
il y a Threading.Thread.sleep()
qui prend en paramètre un nb de millisecondes ...
ça devrait faire l'affaire, non ?

--
Bill2
Utilisez Process Manager, gestionnaire de processus automatique :
http://www.bill2-software.com/processmanager/























1 2