AutoIt Français

Bonjour.

Je voudrais créer un logiciel qui me permettrait de voir une Webcam distante.
Je sais très bien qu'il me fraudais surement crée deux Exécutable, Un serveur, et un client.
Mais je voudrais avoir bien plus d'information sur le sujet, vue que je ne mit connait pas du tous en serveur, et tous se qui suit.

Je ne vous demande pas le script complet, mais des explication, avec pourquoi pas des exemple simple.

Je vous remercie.
Cordialement !

http://www.autoitscript.com/forum/topic ... nt-driven/
C'est la clef!

Merci, mais une question me reste sans réponce
Comment je fait pour activer la webcam, envoyer les donnée, et quel objet je met dans la fenêtre pour l'afficher :s

Bon bah déja, t'aurais pu faire une recherche sur le forum avec tout simplement "Webcam"!
Mais comme je suis de bonne humeur (et heureusement que Tlem n'est pas la!!! ), je te donne le lien vers un UDF que je vien de poster, c'est un N'ème UDF de Webcam, mais je pense que c'est le meilleur de tous ce que j'ai pu trouver jusque la.
http://www.autoitscript.fr/forum/viewto ... =21&t=6258

Si, si, je suis là.
Mais parfois, je suis las.
Donc j'arrête là.

j'avais fait une recherche mais je n'ai pas trouver d'UDF :s

Merci bien, mais j'aurais encore une dernière question

L'UDF permet d'afficher une webcam local, mais en distant, je fait comment ?
Je change d'ID de la webcam ? par quoi ? Une valeur retourner par l’exécutable serveur ?

Et avec UDF de TPC, je n'ai pas reusis a trouver le moyen pour envoyer la Webcam.
J'ai trouver comment Envoyer/recevoir des information, mais comment j'envoi une webcam si je peut dire ?

Bah franchement moi aussi j'en sais rien!

Ya surement un moyen de faire du streaming direct, mais je le connais pas.

Sinon tu peut toujours faire prendre à ton serveur un photo de la cam toutes les 5 secondes par exemple, et l'envoyé par tcp au client, ou alors, pourquoi réinventer la roue Lien

Merci, Bien, je vais donc adapter le script pour mes besoin

Mais encore une dernière chose :p

Quel est le code PHP pour renvoyer l'IP, de manière que on est pas a rentré l'IP dans un InputBox.
Ou alors quel est le Code Autoit, mais as ma connaissance y'en as pas :s

Merci

Juste pour info :

L'utilisation de l'UDF TCP.au3 est à proscrire.

Je trouve qu'il est assez bugé
- crash si tous les clients se déconnectent
- Plus de connexionis possible quand au moins un client se déconnect.
- Et j'en passe..

L'utilisation des fonctions de base TCPConnect(), TCPSend(), TCPRecv(), ... sont bien plus stables et pas si compliquées que ça au final.

PS : Si je vous dit cela, c'est parceque je me suis lancé dans un programme utilisant cet UDF ... et j'ai bien été déçu quand j'ai découvert tous ces bug... et j'ai du changer une bonne partie du code source.

C'est vrai qu'il contient quelques bugs, mais aucun de ceux dont tu parle (ni crash, ni impossibilité de se reconnecter)

Je travaille en ce moment sur un tchat TCP, je sais que je l'ai déjà fait mais cette fois, c'est en mieux! (Liste de contactes, messages privés, fenêtre en HTML pour que ce soit plus joli...)

Le seul bug qui me (m'a) tracassé c'est le fait que des fois, quand plusieurs messages sont reçus en même temps, il sont imbriques tout ensemble, et comme mon programme utilise des commandes bien spécifique qui doivent être au début du message, bah la première commande est prise en compte, alors que la 2e est zappée!

Pour régler ça, j'ai ajouté un balise de fin de transmission (genre ##FIN##) et un fonction qui fait un StringSplit pour séparer les messages et les envoyer un à un à la fonction qui les traite.

Je veut le finaliser avant de le poster, et c'est pour bientôt!

La concaténation des chaînes est "normale" (pas considéré comme un bug).
En effet, il me semble que tant que vous ne lisez pas (TCPRecv), et que vous recevez des requêtes (TCPSend), le tout est stocké dans un buffer. Et lorsque 2 requêtes sont envoyée dans un interval de temps relativement faible, vous n'avez pas le temps de faire un TCPRecv() et donc au prochain TCPRecv, vous recevez le tout en un seul bloc. J'ai aussi opté pour une suite de caractères pour délimiter mes requêtes.

Cela fait longtemps que je n'ai pas utilisé l UDF (peut être qu'il à été mis à jour)

Je me souviens que ce cas plantait :
- Connexion du client 1
- Connexion du client 2
- Faire parler les 2 clients (ca marche)
- Déconnexion du client 2
- Connexion du client 3
- Faire parler le client 3 (ne marche pas)

Ainsi que celui ci :
- Connexion client 1
- Connexion client 2
- Déconnexion du client 1
- Déconnexion du client 2
- Plantage de l'appli

PS : l'utilisation des commandes TCP d'autoit restent relativement simples, cela associé à un tableau (pour ranger les socket) et vous pouvez facilement "recréer" l'UDF. Après, si l'UDF ne contient plus de bug, utilisez le ^^.

J'ai testé les "étapes" qui boguent chez vous, et pour moi ça marche normalement.
Soit l'UDF a été mis à jour, soit y'a un truc que vous ne faisiez pas bien.

Et maintenant, stop au floud!

Juste à propos de l'UDF TCP du forum anglais:
- c'est vrai qu'il bug, mais j'ai trouvé d'ou ça vient:
Regarder mon message sur le post de l'UDF: Lien

J'y dis pour faire court, que la fonction _arrayDelete parfois, rend le Array qui stock les connections ($__TCK_SOCKETS) en string vide (""), ce qui fait buguer le script.
J'ai donc commenté la ligne responsable, et je crois que maintenant, l'UDF fonctionne très bien!

PS: j'attends toujours la réponse de l'auteur de l'UDF