Hello Guyt
a tu testé ton composant sous Seven 32 et 64 bits ?ça me surprend ce que me dis. les deux fonctions que j'utilise sont les mêmes que celles que j'utilise pour mon timer (MMTimer) et que j'ai développé sous XP.
cdlt
Hello Guyt
a tu testé ton composant sous Seven 32 et 64 bits ?ça me surprend ce que me dis. les deux fonctions que j'utilise sont les mêmes que celles que j'utilise pour mon timer (MMTimer) et que j'ai développé sous XP.
cdlt
Salut Guyt
Malheureusement ton Composant ne compile pas avec RadStudio 2010 sous seven
comme indiqué dans mon précédent Post le fonctions employées timeKillEvent et timeSetEvent ne sont pas compatibles et provoquent un échec lors de la compilation
je te conseille d'utiliser les coposnats de Fracnçois Piette (OverByte) qui sont à mon point de vue supérieur à Indy et qui sont par ailleurs compatibles avec les nouvelles versions de MS
cdlt
Quand même curieux que ça fonctionne pour moi en Codegear 2009 sous XP et XE2 sous Windows 7 (faut pas oublier d'inclure ws2_32.lib). Mais bon, j'en ferai pas une croisade, si tu dis que ça marche pas en 2010, je te crois, c'est toi l'expert.
DjmSoftware, ce que je veux c'est de comprendre comment fonctionnent la chose qui m'intéresse, soit la programmation de bas niveau. Mon but n'est donc pas d'avoir une composant UDP, y en a déjà des tonnes, c'est de l'écrire, pour le simple plaisir. Indy, je connais, je m'en servais déjà. Et j'ai pas de doutes que le UDP de François Piette est mieux que le mien.
Là, je suis content, je comprends un peu mieux les sockets et me rapproche un peu plus du but que je me suis fixé, me faire mon propre composant bluetooth. Que ça existe déjà, je m'en balance, j'ai du plaisir à le faire, c'est tout ce que je veux.
Au plaisir!
Salut Guyt,
ton composant compile maintenant en ajoutant les fichiers include Manquant
j'ai testé ton composant,il fonctionne mais nécessite quelques corrections:
- Buffer créer avec [] doit être également être détruit par delete [] xx
- déclenchement d'exception pas compatible avec la VCL
- Changement de Port non pris en compte
cette liste n'est pas exhaustive
bon courage pour les corrections
Merci pour les bugs.
Pour 1:
Là, tu m'apprends quelque chose. Je fais bien un delete fRxBuf, je savais pas qu'il fallait spécifier les "[]".
Un point pour Java tout de même, y ont pas de "delete"
Pour 2:
Pour les exceptions, je savais pas non plus. Aussi, y a comme une ambiguïté dans mon traitement d'erreurs critiques., faut que je repense ça.
Pour 3:
Je vais revérifier mon code, mais il me semble que je réinitialise le hardware quand change le "ListenPort" (via la méthode SetListenPort).
Encore merci!
Salut
on fait un delete pour libérer la mémoire demandée par un newPour 1:
Là, tu m'apprends quelque chose. Je fais bien un delete fRxBuf, je savais pas qu'il fallait spécifier les "[]".
dans le cas d'un tableau
initiliaisation char * Buffer= new char[1024];
Libération delete []Buffer;
le problème vient du fait que ta méthode RXBuffer est appelée continuellement par ton timer --> Erreur de socket lors d'un changement de portJe vais revérifier mon code, mais il me semble que je réinitialise le hardware quand change le "ListenPort" (via la méthode SetListenPort).
tu dois donc tuer ton timer , Changer le Port, Recréer le Timer
cdlt
Bon, j'ai repensé mon approche en ce qui a trait à l'initialisation du socket de réception (qui se fait maintenant seulement au lancement de l'application) ainsi que la gestion d'erreurs lors d'initialisation du socket de réception.
Au bout du compte, le code est plus simple, mais introduit peut être un bug si le composant est créé dynamiquement (je ne suis pas certain que "Loaded" est appellé, ça reste à vérifier.
Le code de "TUdpSockit" présenté auparavant reflète la version courante.
Bon, je vais aller prendre de l'air, y a un beau gros soleil qui m'attend
Salut
le Composant est toujours chargé dynamiquement, la form sur laquelle est déposé ton composant appelle le constructeur de ton composantBon, j'ai repensé mon approche en ce qui a trait à l'initialisation du socket de réception (qui se fait maintenant seulement au lancement de l'application) ainsi que la gestion d'erreurs lors d'initialisation du socket de réception.
Au bout du compte, le code est plus simple, mais introduit peut être un bug si le composant est créé dynamiquement (je ne suis pas certain que "Loaded" est appellé, ça reste à vérifier.
Le code de "TUdpSockit" présenté auparavant reflète la version courante
ton Composant pourrait par exemple se référer au composant Standard de la VCL en intégrant une property Active qui te permettrait d'initialiser ton socket et le Timer pour ton Polling
une manière simple de créer des exceptions est la suivante:
cdlt
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 throw (Exception("Mon Message d'erreur"));
Salut
Je ne sais pas si on parle de la même chose.
Je me demandais si la méthode "Loaded" de TComponent est appelée quand même si le composant est créé dynamiquement plutôt que d'être déposé sur la forme, i.e.:
Je viens de vérifier et la réponse est non.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 TUdpSocket* socket = new TUdpSocket(this) ;
Donc, j'ai un petit correctif à effectuer.
[/code]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager