Discussion :

[hunteshiva]

Bonjour,

je passe par une fonction qui à certains moments prend du temps *10-20 sec*.
Le soucis c'est qu'elle bloque mon appli, je ne peux plus rien en faire...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Etat_Chambre = ConnexionAutomate(Communication.Ethernet, "192.168.0.1")
' bloque mon programme le temps de voir que l'automate n'est pas connecté

j'aimerais savoir si on ne peux pas éviter le freeze de l'appli.
j'ai essayé avec un "Aplication.DoEvents()"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Application.DoEvents()
Etat_Chambre = ConnexionAutomate(Communication.Ethernet, "192.168.0.1") 
Application.DoEvents()

mais pas concluent comme résultat

[asmduty]

Bonjour,

jette un oeil sur l'utilisation de background worker ou thread

[mactwist69]

Bonjour,

Application.DoEvents ne te sert à rien dans ton cas. D'une part il ne sert pas à "fluidifier" le programme, et de plus comme le code est itératif, le code va arriver sur la ligne qui "freeze", il va freezé, et après seulement il passe a la ligne suivante.

Donc comme l'a dit notre ami, fait des recherches du coté des threads.
Soit tu te le créer tout seul (plus compliqué), soit tu utilises le backgroundworker (c'est un thread facile d'utilisation).

Par contre si tu utilises le backgroundworker, et que le traitement qu'il a a faire est lourd... sache que ton PC va freezer quand même. Car windows alloue beaucoup trop de mémoire ram au background worker, et au final, ca va freezer quand même. Mais si le traitement est léger alors c'est bon.

[DonQuiche]

Par contre si tu utilises le backgroundworker, et que le traitement qu'il a a faire est lourd... sache que ton PC va freezer quand même. Car windows alloue beaucoup trop de mémoire ram au background worker, et au final, ca va freezer quand même. Mais si le traitement est léger alors c'est bon.

D'où sors-tu cela ?
Le taille par défaut de la pile est de 1Mo. En quoi cela va t-il faire ramer le programme ? Et quel rapport avec la durée d'exécution du thread ?
Je crois que tu as de fausses idées sur le background worker et que tu es assez confus.

[hunteshiva]

Merci pour l'idée asmduty

j'ai regardé pour faire un petit Thread,
ça l'air de pas mal tourner maintenant

Voila le petit bout de code qui va bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Imports System.Threading

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Public Sub ProcLectureAPI()
    'Code pour l'exécution
    Etat_Chambre = Nothing
    Etat_Chambre.Redim_DB_Bits(7)
    Etat_Chambre = ConnexionAutomate(Communication.Ethernet, "192.168.0.1")
End Sub

J'appel le code à exécuter dans le thread qui va bien
*pour moi c'est à chaque Tick du Timer*

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
' Appel du Thread
Dim ThreadLectureAPI As New Thread(AddressOf ProcLectureAPI)
ThreadLectureAPI.Start()

[mactwist69]

D'où sors-tu cela ?
Le taille par défaut de la pile est de 1Mo. En quoi cela va t-il faire ramer le programme ? Et quel rapport avec la durée d'exécution du thread ?
Je crois que tu as de fausses idées sur le background worker et que tu es assez confus.

Et bien par expérience... J'avais un traitement d'adresse (plusieurs centaines de millions de lignes), j'ai dans un premier temps utiliser le background worker, et ça a donné le résultat que j'ai dis.

J'ai essayer avec un thread normal... mon appli ne freezai plus du tout.

Alors peut être que je m’égare, tout du moins que mes conclusions sont faussent, mais le résultat de l’expérience fut là.

[DonQuiche]

Alors peut être que je m’égare, tout du moins que mes conclusions sont faussent, mais le résultat de l’expérience fut là.

A mon avis le problème devait effectivement être ailleurs. Pour ce que j'en sais un background worker n'est qu'un thread comme les autres.