Bonjour.
Je suis en train d'etudier comment utiliser les modems en windev.
Apparement, les fonctions TAPI de windev, c'est pas ideal :
trop peu documentees, on comprend rien...
par exemple :
<<
<Résultat> = telDémarreDétectionAppel(<Identifiant du service> [,
<Options>], <Nom de la procédure> [, <Paramètre personnalisé>])
(...)
<Identifiant du service> : Chaîne de caractères
Nom permettant d'identifier le service de détection d'appel.
>>
J'ai essaye avec "AttendAppel" comme dans l'exemple et ca marche.
OK...
Mais ca me fait franchement une belle jambe de savoir que l'identifiant du
service permet d'identifier le service...
Et a part ca, il sort d'ou ce "AttendAppel" ? je peux mettre quoi d'autre ?
mystere...
Donc je laisse tomber cette piste.
(en plus, c'est buggue : le parametre personnalise n'est pas envoye a la
procedure.)
(et puis si je demarre la detection d'appel et que mon modem est eteind, ca
marche quand meme alors la c'est puissant cette fonction)
Il reste donc deux pistes interessantes sur lesquelles j'hesite :
1) utiliser les APIs windows comme conseille par JFC1.
ca a l'air un peu compliqué, c'est de la programmation evenementielle, mais
ca a l'air tres complet.
un "hic" toutefois :
<<The DCE also needs configuration to make certain the DTE and DCE use the
same type of flow control. There is no mechanism provided by Win32 to set
the flow control of the DCE. DIP switches on the device, or commands sent to
it typically establish its configuration. >>
c'est a dire que de toute facon il faut gerer soi-meme les differents
profils de modems.
Donc ca j'y couperait pas...
Par contre, la detection d'appel, de raccrochage, la gestion du controle de
flux, des timeouts en lecture et ecriture etc etc, a priori on peut faire
ce qu'on veut avec, et tres finement...
Mais bon il faut passer par les appels aux API et en windev c'est vraiment
merdique alors je risque de mettre pas mal de temps a ecrire tout ca...(et
aussi a lire les tonnes de docs de visual C++ et MSDN qui traitent du sujet)
2) utiliser souvre, secrit, slit et compagnie. Tout ecrire directement en
windev.
Ca a l'avantage d'etre beaucoup plus simple a ecrire, au moins pour moi qui
maitrise ca ( j'ai ecrit la gestion des ports serie et les drivers de modems
de notre appli sous unix.)
J'y voies un gros inconvenient :
ces fonctions ne sont prevues que pour 4 ports COM !!!!!
Le jour ou on rajoute une carte multivoies, on est roulé dans la farine...
(bon j'lai jamais fait sous windows, mais ca viendra un jour ou l'autre)
et un modem USB, ca doit bien exister aussi...
Alors a votre avis, qu'est ce qui est mieux ?
notemment, les appels aux APIs sont-ils fiables ?
J'ai un gros gros doute la dessus, car si je debranche et rebranche mon
modem sous windows 2000, je suis oblige de rebooter pour pouvoir l'utiliser
a nouveau. (ou passer en administrateur et re-detecter le materiel), et ce
rien qu'en utilisant du "pur windows" c'est a dire l'acces reseau a
distance...
Les appels a souvre etc sont-ils fiables ?
Pourra-t-on un jour (pas trop lointain) ouvrir un port USB ou un port serie
autre que COM1 a COM4 ?
(y'a surement deja quelqu'unqui a posé la question a PCSOFT...)
N'y a-t-il pas de risque a les utiliser en multithreade ?
Quelle solution avez-vous adopté ?
Les APIs ? les "souvre" ? autre chose ?
Pourquoi ?
Merci d'avance a ceux qui prendront le temps de me repondre...
(pour l'instant, je penche plutot pour la solution "souvre" malgre ses
limitations car le code sera beaucoup plus simple a ecrire et comprendre,
mais la solution "DCB" m'a l'air d'etre plus "standard windows"...)
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
J'y voies un gros inconvenient : ces fonctions ne sont prevues que pour 4 ports COM !!!!!
.......
Pourra-t-on un jour (pas trop lointain) ouvrir un port USB ou un port serie autre que COM1 a COM4 ?
je n'ai pas toutes les réponses à tes questions, par contre, je peux te confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a COM9(neuf)
Cordialement
Michel
JCF1
"Fabrice Burghgraeve" a écrit dans le message de news:bk7cn2$c11$
Bonjour. Je suis en train d'etudier comment utiliser les modems en windev. Apparement, les fonctions TAPI de windev, c'est pas ideal : trop peu documentees, on comprend rien... par exemple : << <Résultat> = telDémarreDétectionAppel(<Identifiant du service> [, <Options>], <Nom de la procédure> [, <Paramètre personnalisé>])
(...)
<Identifiant du service> : Chaîne de caractères
Nom permettant d'identifier le service de détection d'appel.
>>
J'ai essaye avec "AttendAppel" comme dans l'exemple et ca marche. OK... Mais ca me fait franchement une belle jambe de savoir que l'identifiant du service permet d'identifier le service... Et a part ca, il sort d'ou ce "AttendAppel" ? je peux mettre quoi d'autre
?
mystere... Donc je laisse tomber cette piste. (en plus, c'est buggue : le parametre personnalise n'est pas envoye a la procedure.) (et puis si je demarre la detection d'appel et que mon modem est eteind,
ca
marche quand meme alors la c'est puissant cette fonction)
Il reste donc deux pistes interessantes sur lesquelles j'hesite :
1) utiliser les APIs windows comme conseille par JFC1. ca a l'air un peu compliqué, c'est de la programmation evenementielle,
mais
ca a l'air tres complet. un "hic" toutefois : <<The DCE also needs configuration to make certain the DTE and DCE use the same type of flow control. There is no mechanism provided by Win32 to set the flow control of the DCE. DIP switches on the device, or commands sent
to
it typically establish its configuration. >>
c'est a dire que de toute facon il faut gerer soi-meme les differents profils de modems. Donc ca j'y couperait pas... Par contre, la detection d'appel, de raccrochage, la gestion du controle
de
flux, des timeouts en lecture et ecriture etc etc, a priori on peut faire ce qu'on veut avec, et tres finement...
Mais bon il faut passer par les appels aux API et en windev c'est vraiment merdique alors je risque de mettre pas mal de temps a ecrire tout ca...(et aussi a lire les tonnes de docs de visual C++ et MSDN qui traitent du
sujet)
2) utiliser souvre, secrit, slit et compagnie. Tout ecrire directement en windev. Ca a l'avantage d'etre beaucoup plus simple a ecrire, au moins pour moi
qui
maitrise ca ( j'ai ecrit la gestion des ports serie et les drivers de
modems
de notre appli sous unix.) J'y voies un gros inconvenient : ces fonctions ne sont prevues que pour 4 ports COM !!!!! Le jour ou on rajoute une carte multivoies, on est roulé dans la farine... (bon j'lai jamais fait sous windows, mais ca viendra un jour ou l'autre) et un modem USB, ca doit bien exister aussi...
Alors a votre avis, qu'est ce qui est mieux ?
notemment, les appels aux APIs sont-ils fiables ? J'ai un gros gros doute la dessus, car si je debranche et rebranche mon modem sous windows 2000, je suis oblige de rebooter pour pouvoir
l'utiliser
a nouveau. (ou passer en administrateur et re-detecter le materiel), et ce rien qu'en utilisant du "pur windows" c'est a dire l'acces reseau a distance...
Les appels a souvre etc sont-ils fiables ? Pourra-t-on un jour (pas trop lointain) ouvrir un port USB ou un port
serie
autre que COM1 a COM4 ? (y'a surement deja quelqu'unqui a posé la question a PCSOFT...) N'y a-t-il pas de risque a les utiliser en multithreade ?
Quelle solution avez-vous adopté ? Les APIs ? les "souvre" ? autre chose ? Pourquoi ?
Merci d'avance a ceux qui prendront le temps de me repondre...
(pour l'instant, je penche plutot pour la solution "souvre" malgre ses limitations car le code sera beaucoup plus simple a ecrire et comprendre, mais la solution "DCB" m'a l'air d'etre plus "standard windows"...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev, sauf pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense que si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait pu marcher en WD. J'ai également testé une programmation mixte, par exemple ouverture du port com par sOuvre, puis les autres traitements avec des APIs DCB, ça fonctionne. L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un timer remplacé par la fonction/Api WaitCommEvent :
RetourFonction est un booléen hFile est un entier lpEvtMask est un entier lpOverlapped est un entier RetourFonction=API("KERNEL32","WaitCommEvent",hFile,lpEvtMask,lpOverlapped)
//Mettre ces déclarations dans le code d'initialisation (Fenêtre, Projet...) //Déclaration des structures nécessaires à la fonction de l'API <WaitCommEvent> : OVERLAPPED est une structure Internal est un entier InternalHigh est un entier Offset est un entier OffsetHigh est un entier hEvent est un entier FIN //Fin de la déclaration des structures pour <WaitCommEvent>
Pour info, DCB est une structure en C. A l'origine le port com était ouvert par la fonction C OpenComm, qui est par la suite devenue obsolète et a été remplacée par la fonction OpenFile, le port com étant alors considéré comme un fichier d'un type particulier.
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB. Par contre je ne donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
En ce qui concerne la gestion des diférends types de modems, je n'ai toujours pas trouvé de solution miracle et automatique, sauf un peu sous XP ou l'on arrive a avoir une information directe du ou des modems connectés sur le système.
"Fabrice Burghgraeve" <f_pas_de_spam_burghgraeve@computeretservices.com> a
écrit dans le message de news:bk7cn2$c11$1@news.nordnet.fr...
Bonjour.
Je suis en train d'etudier comment utiliser les modems en windev.
Apparement, les fonctions TAPI de windev, c'est pas ideal :
trop peu documentees, on comprend rien...
par exemple :
<<
<Résultat> = telDémarreDétectionAppel(<Identifiant du service> [,
<Options>], <Nom de la procédure> [, <Paramètre personnalisé>])
(...)
<Identifiant du service> : Chaîne de caractères
Nom permettant d'identifier le service de détection d'appel.
>>
J'ai essaye avec "AttendAppel" comme dans l'exemple et ca marche.
OK...
Mais ca me fait franchement une belle jambe de savoir que l'identifiant du
service permet d'identifier le service...
Et a part ca, il sort d'ou ce "AttendAppel" ? je peux mettre quoi d'autre
?
mystere...
Donc je laisse tomber cette piste.
(en plus, c'est buggue : le parametre personnalise n'est pas envoye a la
procedure.)
(et puis si je demarre la detection d'appel et que mon modem est eteind,
ca
marche quand meme alors la c'est puissant cette fonction)
Il reste donc deux pistes interessantes sur lesquelles j'hesite :
1) utiliser les APIs windows comme conseille par JFC1.
ca a l'air un peu compliqué, c'est de la programmation evenementielle,
mais
ca a l'air tres complet.
un "hic" toutefois :
<<The DCE also needs configuration to make certain the DTE and DCE use the
same type of flow control. There is no mechanism provided by Win32 to set
the flow control of the DCE. DIP switches on the device, or commands sent
to
it typically establish its configuration. >>
c'est a dire que de toute facon il faut gerer soi-meme les differents
profils de modems.
Donc ca j'y couperait pas...
Par contre, la detection d'appel, de raccrochage, la gestion du controle
de
flux, des timeouts en lecture et ecriture etc etc, a priori on peut faire
ce qu'on veut avec, et tres finement...
Mais bon il faut passer par les appels aux API et en windev c'est vraiment
merdique alors je risque de mettre pas mal de temps a ecrire tout ca...(et
aussi a lire les tonnes de docs de visual C++ et MSDN qui traitent du
sujet)
2) utiliser souvre, secrit, slit et compagnie. Tout ecrire directement en
windev.
Ca a l'avantage d'etre beaucoup plus simple a ecrire, au moins pour moi
qui
maitrise ca ( j'ai ecrit la gestion des ports serie et les drivers de
modems
de notre appli sous unix.)
J'y voies un gros inconvenient :
ces fonctions ne sont prevues que pour 4 ports COM !!!!!
Le jour ou on rajoute une carte multivoies, on est roulé dans la farine...
(bon j'lai jamais fait sous windows, mais ca viendra un jour ou l'autre)
et un modem USB, ca doit bien exister aussi...
Alors a votre avis, qu'est ce qui est mieux ?
notemment, les appels aux APIs sont-ils fiables ?
J'ai un gros gros doute la dessus, car si je debranche et rebranche mon
modem sous windows 2000, je suis oblige de rebooter pour pouvoir
l'utiliser
a nouveau. (ou passer en administrateur et re-detecter le materiel), et ce
rien qu'en utilisant du "pur windows" c'est a dire l'acces reseau a
distance...
Les appels a souvre etc sont-ils fiables ?
Pourra-t-on un jour (pas trop lointain) ouvrir un port USB ou un port
serie
autre que COM1 a COM4 ?
(y'a surement deja quelqu'unqui a posé la question a PCSOFT...)
N'y a-t-il pas de risque a les utiliser en multithreade ?
Quelle solution avez-vous adopté ?
Les APIs ? les "souvre" ? autre chose ?
Pourquoi ?
Merci d'avance a ceux qui prendront le temps de me repondre...
(pour l'instant, je penche plutot pour la solution "souvre" malgre ses
limitations car le code sera beaucoup plus simple a ecrire et comprendre,
mais la solution "DCB" m'a l'air d'etre plus "standard windows"...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup
utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev, sauf
pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense que
si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait
pu marcher en WD.
J'ai également testé une programmation mixte, par exemple ouverture du port
com par sOuvre, puis les autres traitements avec des APIs DCB, ça
fonctionne.
L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un
timer remplacé par la fonction/Api WaitCommEvent :
RetourFonction est un booléen
hFile est un entier
lpEvtMask est un entier
lpOverlapped est un entier
RetourFonction=API("KERNEL32","WaitCommEvent",hFile,lpEvtMask,lpOverlapped)
//Mettre ces déclarations dans le code d'initialisation (Fenêtre, Projet...)
//Déclaration des structures nécessaires à la fonction de l'API
<WaitCommEvent> :
OVERLAPPED est une structure
Internal est un entier
InternalHigh est un entier
Offset est un entier
OffsetHigh est un entier
hEvent est un entier
FIN
//Fin de la déclaration des structures pour <WaitCommEvent>
Pour info, DCB est une structure en C.
A l'origine le port com était ouvert par la fonction C OpenComm, qui est par
la suite devenue obsolète et a été remplacée par la fonction OpenFile, le
port com étant alors considéré comme un fichier d'un type particulier.
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la
taille) la traduction en Windev de toutes les APIs C et les structures s'y
rapportant, concernant les fonctions de communication DCB. Par contre je ne
donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je
commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
En ce qui concerne la gestion des diférends types de modems, je n'ai
toujours pas trouvé de solution miracle et automatique, sauf un peu sous XP
ou l'on arrive a avoir une information directe du ou des modems connectés
sur le système.
"Fabrice Burghgraeve" a écrit dans le message de news:bk7cn2$c11$
Bonjour. Je suis en train d'etudier comment utiliser les modems en windev. Apparement, les fonctions TAPI de windev, c'est pas ideal : trop peu documentees, on comprend rien... par exemple : << <Résultat> = telDémarreDétectionAppel(<Identifiant du service> [, <Options>], <Nom de la procédure> [, <Paramètre personnalisé>])
(...)
<Identifiant du service> : Chaîne de caractères
Nom permettant d'identifier le service de détection d'appel.
>>
J'ai essaye avec "AttendAppel" comme dans l'exemple et ca marche. OK... Mais ca me fait franchement une belle jambe de savoir que l'identifiant du service permet d'identifier le service... Et a part ca, il sort d'ou ce "AttendAppel" ? je peux mettre quoi d'autre
?
mystere... Donc je laisse tomber cette piste. (en plus, c'est buggue : le parametre personnalise n'est pas envoye a la procedure.) (et puis si je demarre la detection d'appel et que mon modem est eteind,
ca
marche quand meme alors la c'est puissant cette fonction)
Il reste donc deux pistes interessantes sur lesquelles j'hesite :
1) utiliser les APIs windows comme conseille par JFC1. ca a l'air un peu compliqué, c'est de la programmation evenementielle,
mais
ca a l'air tres complet. un "hic" toutefois : <<The DCE also needs configuration to make certain the DTE and DCE use the same type of flow control. There is no mechanism provided by Win32 to set the flow control of the DCE. DIP switches on the device, or commands sent
to
it typically establish its configuration. >>
c'est a dire que de toute facon il faut gerer soi-meme les differents profils de modems. Donc ca j'y couperait pas... Par contre, la detection d'appel, de raccrochage, la gestion du controle
de
flux, des timeouts en lecture et ecriture etc etc, a priori on peut faire ce qu'on veut avec, et tres finement...
Mais bon il faut passer par les appels aux API et en windev c'est vraiment merdique alors je risque de mettre pas mal de temps a ecrire tout ca...(et aussi a lire les tonnes de docs de visual C++ et MSDN qui traitent du
sujet)
2) utiliser souvre, secrit, slit et compagnie. Tout ecrire directement en windev. Ca a l'avantage d'etre beaucoup plus simple a ecrire, au moins pour moi
qui
maitrise ca ( j'ai ecrit la gestion des ports serie et les drivers de
modems
de notre appli sous unix.) J'y voies un gros inconvenient : ces fonctions ne sont prevues que pour 4 ports COM !!!!! Le jour ou on rajoute une carte multivoies, on est roulé dans la farine... (bon j'lai jamais fait sous windows, mais ca viendra un jour ou l'autre) et un modem USB, ca doit bien exister aussi...
Alors a votre avis, qu'est ce qui est mieux ?
notemment, les appels aux APIs sont-ils fiables ? J'ai un gros gros doute la dessus, car si je debranche et rebranche mon modem sous windows 2000, je suis oblige de rebooter pour pouvoir
l'utiliser
a nouveau. (ou passer en administrateur et re-detecter le materiel), et ce rien qu'en utilisant du "pur windows" c'est a dire l'acces reseau a distance...
Les appels a souvre etc sont-ils fiables ? Pourra-t-on un jour (pas trop lointain) ouvrir un port USB ou un port
serie
autre que COM1 a COM4 ? (y'a surement deja quelqu'unqui a posé la question a PCSOFT...) N'y a-t-il pas de risque a les utiliser en multithreade ?
Quelle solution avez-vous adopté ? Les APIs ? les "souvre" ? autre chose ? Pourquoi ?
Merci d'avance a ceux qui prendront le temps de me repondre...
(pour l'instant, je penche plutot pour la solution "souvre" malgre ses limitations car le code sera beaucoup plus simple a ecrire et comprendre, mais la solution "DCB" m'a l'air d'etre plus "standard windows"...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev, sauf pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense que si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait pu marcher en WD. J'ai également testé une programmation mixte, par exemple ouverture du port com par sOuvre, puis les autres traitements avec des APIs DCB, ça fonctionne. L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un timer remplacé par la fonction/Api WaitCommEvent :
RetourFonction est un booléen hFile est un entier lpEvtMask est un entier lpOverlapped est un entier RetourFonction=API("KERNEL32","WaitCommEvent",hFile,lpEvtMask,lpOverlapped)
//Mettre ces déclarations dans le code d'initialisation (Fenêtre, Projet...) //Déclaration des structures nécessaires à la fonction de l'API <WaitCommEvent> : OVERLAPPED est une structure Internal est un entier InternalHigh est un entier Offset est un entier OffsetHigh est un entier hEvent est un entier FIN //Fin de la déclaration des structures pour <WaitCommEvent>
Pour info, DCB est une structure en C. A l'origine le port com était ouvert par la fonction C OpenComm, qui est par la suite devenue obsolète et a été remplacée par la fonction OpenFile, le port com étant alors considéré comme un fichier d'un type particulier.
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB. Par contre je ne donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
En ce qui concerne la gestion des diférends types de modems, je n'ai toujours pas trouvé de solution miracle et automatique, sauf un peu sous XP ou l'on arrive a avoir une information directe du ou des modems connectés sur le système.
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Par contre je ne donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre et les sociétés de gagner de l'argent.
A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Bonjour,
JCF1 a écrit :
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de
la taille) la traduction en Windev de toutes les APIs C et les
structures s'y rapportant, concernant les fonctions de communication
DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Par contre je ne donne pas le mode d'emploi, j'y ai passé
beaucoup de temps et je commercialise des applis avec ces fonctions,
il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre
et les sociétés de gagner de l'argent.
A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Par contre je ne donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre et les sociétés de gagner de l'argent.
A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
JCF1
"Romain PETIT" a écrit dans le message de news:3f680888$0$20629$
Bonjour,
JCF1 a écrit :
> Si cela vous interesse, je peux vous envoyer en privé (compte tenu de > la taille) la traduction en Windev de toutes les APIs C et les > structures s'y rapportant, concernant les fonctions de communication > DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Pour la traduction des APIs DCB C/C++ vers WD, pourquoi pas, mais comment fait-on ?
> Par contre je ne donne pas le mode d'emploi, j'y ai passé > beaucoup de temps et je commercialise des applis avec ces fonctions, > il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre et les sociétés de gagner de l'argent.
Erreur, peut être pas. Il m'arrive de donner certaines de mes sources, mais pour d'autres, je tiens à les conserver d'autant plus que ces sources font parties d'applis ayant fait l'objet d'un dépot (ou en cours de dépot) pour lesquels je paie en outre des droits de dépot auprès de l'agence pour la protection des logiciels.
"Romain PETIT" <rompetit@invalidifrance.com> a écrit dans le message de
news:3f680888$0$20629$626a54ce@news.free.fr...
Bonjour,
JCF1 a écrit :
> Si cela vous interesse, je peux vous envoyer en privé (compte tenu de
> la taille) la traduction en Windev de toutes les APIs C et les
> structures s'y rapportant, concernant les fonctions de communication
> DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Pour la traduction des APIs DCB C/C++ vers WD, pourquoi pas, mais comment
fait-on ?
> Par contre je ne donne pas le mode d'emploi, j'y ai passé
> beaucoup de temps et je commercialise des applis avec ces fonctions,
> il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre
et les sociétés de gagner de l'argent.
Erreur, peut être pas. Il m'arrive de donner certaines de mes sources, mais
pour d'autres, je tiens à les conserver d'autant plus que ces sources font
parties d'applis ayant fait l'objet d'un dépot (ou en cours de dépot) pour
lesquels je paie en outre des droits de dépot auprès de l'agence pour la
protection des logiciels.
"Romain PETIT" a écrit dans le message de news:3f680888$0$20629$
Bonjour,
JCF1 a écrit :
> Si cela vous interesse, je peux vous envoyer en privé (compte tenu de > la taille) la traduction en Windev de toutes les APIs C et les > structures s'y rapportant, concernant les fonctions de communication > DCB.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Pour la traduction des APIs DCB C/C++ vers WD, pourquoi pas, mais comment fait-on ?
> Par contre je ne donne pas le mode d'emploi, j'y ai passé > beaucoup de temps et je commercialise des applis avec ces fonctions, > il faut bien que je vive. :-)
Grave erreur que de penser que le logiciel libre empêche les gens de vivre et les sociétés de gagner de l'argent.
Erreur, peut être pas. Il m'arrive de donner certaines de mes sources, mais pour d'autres, je tiens à les conserver d'autant plus que ces sources font parties d'applis ayant fait l'objet d'un dépot (ou en cours de dépot) pour lesquels je paie en outre des droits de dépot auprès de l'agence pour la protection des logiciels.
Pourquoi ne pas proposer cela en licence WD-libre sur windevasso ?
Pour la traduction des APIs DCB C/C++ vers WD, pourquoi pas, mais comment fait-on ?
Il suffit de contacter le Webmaster de Windevasso.
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Fabrice Burghgraeve
Bonjour.
"JCF1" a écrit dans le message de news:bk7usv$k03$
(...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev,
sauf
pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense
que
si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait pu marcher en WD.
Merci de cette precision... En fait, je crois que c'est ce que je vais faire.... Mais avant de me lancer a ecrire des routines qui vont surement servir tres longtemps, je prefere me renseigner pour pas partir directement sur une mauvaise piste.
J'ai également testé une programmation mixte, par exemple ouverture du
port
com par sOuvre, puis les autres traitements avec des APIs DCB, ça fonctionne. L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un timer remplacé par la fonction/Api WaitCommEvent :
(...)
Un timer pour quoi faire ?
Je pense plutot partir sur du multithreadé (les slit sont blocants), et donner le time-out dans souvre... Ca va etre (un peu) genant dans la mesure ou le time-out n'est pas le meme quand on attend un appel que quand on attend un caractere en cours de communication... A mon avis, il aurait ete beaucoup plus judicieux de mettre le time-out au niveau du slit ou secrit plutot que du souvre... (avec quand meme un time-out pour le souvre, mais qui a une signification bien differente...) En tout cas, c'est comme ca que j'ai fait dans mes programmes UNIX.
Pour info, DCB est une structure en C. A l'origine le port com était ouvert par la fonction C OpenComm, qui est
par
la suite devenue obsolète et a été remplacée par la fonction OpenFile, le port com étant alors considéré comme un fichier d'un type particulier.
Merci de cette precision. Je le savais deja, car j'ai lu la Doc MSDN, qui s'est installée avec Visual C++... (grace a vous et a Romain qui m'avez mis sur la voie...) Mais pour ceux que ca interesserait, dans "Documentation de Visual Studio .NET", il faut commencer par lire "Serial Communication in Win32" dans la partie "Windows Base Services General Technical Articles" et egalement lire "Communications Ressources" dans la partie "Platform SDK : Hardware" (puis suivre les dizaines de liens)
Au passage, la doc de Visual C++ est bien mieux que celle de windev... Beaucoup plus complete...
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB. Par contre je
ne
donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
oui je comprends :) C'est tres gentil, mais ca ne m'interesse pas dans la mesure ou je ne vais pas partir dans cette direction d'une part, et d'autre part, je l'aurais fait moi-meme si il avait fallu, car rien qu'a traduire toutes les structures et les constantes, ca aide beaucoup a la comprehension de ce que font les fonctions...
En ce qui concerne la gestion des diférends types de modems, je n'ai toujours pas trouvé de solution miracle et automatique, sauf un peu sous
XP
ou l'on arrive a avoir une information directe du ou des modems connectés sur le système.
Avec le peu de recul que j'ai sur la question, j'ai bien peur qu'il n'y ait pas de solution miracle, et que celle consistant a ecrire soi-meme les chaines d'init est surement la moins mauvaise car la plus maitrisee... Sinon, vous etes surement au courant, mais on peut tenter de recuperer des infos directement du modem en lui envoyant les commandes ATI1 à ATI4 (de memoire, a verifier)
(...)
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Bonjour.
"JCF1" <flajoulot.jean-claude@wanadoo.fr> a écrit dans le message de
news:bk7usv$k03$1@news-reader5.wanadoo.fr...
(...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup
utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev,
sauf
pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense
que
si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait
pu marcher en WD.
Merci de cette precision...
En fait, je crois que c'est ce que je vais faire....
Mais avant de me lancer a ecrire des routines qui vont surement servir tres
longtemps, je prefere me renseigner pour pas partir directement sur une
mauvaise piste.
J'ai également testé une programmation mixte, par exemple ouverture du
port
com par sOuvre, puis les autres traitements avec des APIs DCB, ça
fonctionne.
L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un
timer remplacé par la fonction/Api WaitCommEvent :
(...)
Un timer pour quoi faire ?
Je pense plutot partir sur du multithreadé (les slit sont blocants), et
donner le time-out dans souvre...
Ca va etre (un peu) genant dans la mesure ou le time-out n'est pas le meme
quand on attend un appel que quand on attend un caractere en cours de
communication...
A mon avis, il aurait ete beaucoup plus judicieux de mettre le time-out au
niveau du slit ou secrit plutot que du souvre...
(avec quand meme un time-out pour le souvre, mais qui a une signification
bien differente...)
En tout cas, c'est comme ca que j'ai fait dans mes programmes UNIX.
Pour info, DCB est une structure en C.
A l'origine le port com était ouvert par la fonction C OpenComm, qui est
par
la suite devenue obsolète et a été remplacée par la fonction OpenFile, le
port com étant alors considéré comme un fichier d'un type particulier.
Merci de cette precision. Je le savais deja, car j'ai lu la Doc MSDN, qui
s'est installée avec Visual C++...
(grace a vous et a Romain qui m'avez mis sur la voie...)
Mais pour ceux que ca interesserait, dans "Documentation de Visual Studio
.NET",
il faut commencer par lire "Serial Communication in Win32" dans la partie
"Windows Base Services General Technical Articles"
et egalement lire "Communications Ressources" dans la partie "Platform SDK :
Hardware" (puis suivre les dizaines de liens)
Au passage, la doc de Visual C++ est bien mieux que celle de windev...
Beaucoup plus complete...
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la
taille) la traduction en Windev de toutes les APIs C et les structures s'y
rapportant, concernant les fonctions de communication DCB. Par contre je
ne
donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je
commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
oui je comprends :)
C'est tres gentil, mais ca ne m'interesse pas dans la mesure ou je ne vais
pas partir dans cette direction d'une part, et d'autre part, je l'aurais
fait moi-meme si il avait fallu, car rien qu'a traduire toutes les
structures et les constantes, ca aide beaucoup a la comprehension de ce que
font les fonctions...
En ce qui concerne la gestion des diférends types de modems, je n'ai
toujours pas trouvé de solution miracle et automatique, sauf un peu sous
XP
ou l'on arrive a avoir une information directe du ou des modems connectés
sur le système.
Avec le peu de recul que j'ai sur la question, j'ai bien peur qu'il n'y ait
pas de solution miracle,
et que celle consistant a ecrire soi-meme les chaines d'init est surement la
moins mauvaise car la plus maitrisee...
Sinon, vous etes surement au courant, mais on peut tenter de recuperer des
infos directement du modem en lui envoyant les commandes ATI1 à ATI4 (de
memoire, a verifier)
(...)
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"JCF1" a écrit dans le message de news:bk7usv$k03$
(...)
Bonjour,
Les fonctions DCB, je l'ai ai (et encore un peu actuellement) beaucoup utilisées en C, C++, sous WD je préfère utiliser les fonctions Windev,
sauf
pour un cas très particulier ou j'ai employé les APIs DCB, mais je pense
que
si j'avais eu un peu plus le temps de me pencher sur le problème ça aurait pu marcher en WD.
Merci de cette precision... En fait, je crois que c'est ce que je vais faire.... Mais avant de me lancer a ecrire des routines qui vont surement servir tres longtemps, je prefere me renseigner pour pas partir directement sur une mauvaise piste.
J'ai également testé une programmation mixte, par exemple ouverture du
port
com par sOuvre, puis les autres traitements avec des APIs DCB, ça fonctionne. L'interet que j'y ai trouvé est principalement d'éviter l'utilisation d'un timer remplacé par la fonction/Api WaitCommEvent :
(...)
Un timer pour quoi faire ?
Je pense plutot partir sur du multithreadé (les slit sont blocants), et donner le time-out dans souvre... Ca va etre (un peu) genant dans la mesure ou le time-out n'est pas le meme quand on attend un appel que quand on attend un caractere en cours de communication... A mon avis, il aurait ete beaucoup plus judicieux de mettre le time-out au niveau du slit ou secrit plutot que du souvre... (avec quand meme un time-out pour le souvre, mais qui a une signification bien differente...) En tout cas, c'est comme ca que j'ai fait dans mes programmes UNIX.
Pour info, DCB est une structure en C. A l'origine le port com était ouvert par la fonction C OpenComm, qui est
par
la suite devenue obsolète et a été remplacée par la fonction OpenFile, le port com étant alors considéré comme un fichier d'un type particulier.
Merci de cette precision. Je le savais deja, car j'ai lu la Doc MSDN, qui s'est installée avec Visual C++... (grace a vous et a Romain qui m'avez mis sur la voie...) Mais pour ceux que ca interesserait, dans "Documentation de Visual Studio .NET", il faut commencer par lire "Serial Communication in Win32" dans la partie "Windows Base Services General Technical Articles" et egalement lire "Communications Ressources" dans la partie "Platform SDK : Hardware" (puis suivre les dizaines de liens)
Au passage, la doc de Visual C++ est bien mieux que celle de windev... Beaucoup plus complete...
Si cela vous interesse, je peux vous envoyer en privé (compte tenu de la taille) la traduction en Windev de toutes les APIs C et les structures s'y rapportant, concernant les fonctions de communication DCB. Par contre je
ne
donne pas le mode d'emploi, j'y ai passé beaucoup de temps et je commercialise des applis avec ces fonctions, il faut bien que je vive. :-)
oui je comprends :) C'est tres gentil, mais ca ne m'interesse pas dans la mesure ou je ne vais pas partir dans cette direction d'une part, et d'autre part, je l'aurais fait moi-meme si il avait fallu, car rien qu'a traduire toutes les structures et les constantes, ca aide beaucoup a la comprehension de ce que font les fonctions...
En ce qui concerne la gestion des diférends types de modems, je n'ai toujours pas trouvé de solution miracle et automatique, sauf un peu sous
XP
ou l'on arrive a avoir une information directe du ou des modems connectés sur le système.
Avec le peu de recul que j'ai sur la question, j'ai bien peur qu'il n'y ait pas de solution miracle, et que celle consistant a ecrire soi-meme les chaines d'init est surement la moins mauvaise car la plus maitrisee... Sinon, vous etes surement au courant, mais on peut tenter de recuperer des infos directement du modem en lui envoyant les commandes ATI1 à ATI4 (de memoire, a verifier)
(...)
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Fabrice Burghgraeve
bonjour.
"Michel Moreno" a écrit dans le message de news:bk7dpn$pvr6s$
Fabrice Burghgraeve wrote:
(...)
je n'ai pas toutes les réponses à tes questions, par contre, je peux te confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a
COM9(neuf)
Cordialement
Michel
Merci de cette precision qui me rassure... A partir de quelle version ? parce que je suis en 203m, et la doc dit COM1 a COM4
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
bonjour.
"Michel Moreno" <m.moreno@thelis.fr> a écrit dans le message de
news:bk7dpn$pvr6s$1@ID-181643.news.uni-berlin.de...
Fabrice Burghgraeve wrote:
(...)
je n'ai pas toutes les réponses à tes questions, par contre, je peux te
confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a
COM9(neuf)
Cordialement
Michel
Merci de cette precision qui me rassure...
A partir de quelle version ?
parce que je suis en 203m, et la doc dit COM1 a COM4
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Michel Moreno" a écrit dans le message de news:bk7dpn$pvr6s$
Fabrice Burghgraeve wrote:
(...)
je n'ai pas toutes les réponses à tes questions, par contre, je peux te confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a
COM9(neuf)
Cordialement
Michel
Merci de cette precision qui me rassure... A partir de quelle version ? parce que je suis en 203m, et la doc dit COM1 a COM4
a partir de WD5.5 :D
en 7.5 j'ai pas fait l'essai
Michel
Fabrice Burghgraeve
Bonjour.
"Michel Moreno" a écrit dans le message de news:bkbm3u$riglf$ (...)
>>je n'ai pas toutes les réponses à tes questions, par contre, je peux te >>confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a > > COM9(neuf) > >>Cordialement >> >>Michel > > > Merci de cette precision qui me rassure... > A partir de quelle version ? > parce que je suis en 203m, et la doc dit COM1 a COM4 > > a partir de WD5.5 :D
en 7.5 j'ai pas fait l'essai
Michel
:)
Je viens de telecharger la doc 206e. Dedans, c'est egalement ecrit COM1 a COM4. Mais j'ai pas essaye non plus... A l'occasion quand j'aurais plus avance dans mes histoires de modems, je mettrai une carte multivoies dans mon PC pour voir ce que ca fait.
En tout cas, sur rmon PC ou il n'y a quun port COM, le code : SI PAS sOuvre(1,2000,2000) ALORS Erreur(ErreurInfo()) SINON Info("COM1 ouvert"); sFerme(1) FIN
(puis pareil pour COM4 et COM8)
me dit que COM1 est ouvert, et pour com4 et com8, le meme message d'erruer : <<Le mécanisme de sécurité du W-Langage a détecté une erreur sur le port. Détail de l'erreur système :Le fichier spécifié est introuvable.>>
Donc le fait de lui demander d'ouvrir COM8 alors que c'est pas prevu (par la doc ;-) ) ne lui pose pas plus de problemes que de lui demander d'ouvrir COM4, ce qui est prevu. (alors que COM4 n'existe pas)
La question reste momentanement en suspend...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Bonjour.
"Michel Moreno" <m.moreno@thelis.fr> a écrit dans le message de
news:bkbm3u$riglf$1@ID-181643.news.uni-berlin.de...
(...)
>>je n'ai pas toutes les réponses à tes questions, par contre, je peux te
>>confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a
>
> COM9(neuf)
>
>>Cordialement
>>
>>Michel
>
>
> Merci de cette precision qui me rassure...
> A partir de quelle version ?
> parce que je suis en 203m, et la doc dit COM1 a COM4
>
>
a partir de WD5.5 :D
en 7.5 j'ai pas fait l'essai
Michel
:)
Je viens de telecharger la doc 206e.
Dedans, c'est egalement ecrit COM1 a COM4.
Mais j'ai pas essaye non plus...
A l'occasion quand j'aurais plus avance dans mes histoires de modems, je
mettrai une carte multivoies dans mon PC pour voir ce que ca fait.
En tout cas, sur rmon PC ou il n'y a quun port COM,
le code :
SI PAS sOuvre(1,2000,2000) ALORS
Erreur(ErreurInfo())
SINON
Info("COM1 ouvert");
sFerme(1)
FIN
(puis pareil pour COM4 et COM8)
me dit que COM1 est ouvert, et pour com4 et com8, le meme message d'erruer
:
<<Le mécanisme de sécurité du W-Langage a détecté une erreur sur le port.
Détail de l'erreur système :Le fichier spécifié est introuvable.>>
Donc le fait de lui demander d'ouvrir COM8 alors que c'est pas prevu (par la
doc ;-) ) ne lui pose pas plus de problemes que de lui demander d'ouvrir
COM4, ce qui est prevu. (alors que COM4 n'existe pas)
La question reste momentanement en suspend...
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Michel Moreno" a écrit dans le message de news:bkbm3u$riglf$ (...)
>>je n'ai pas toutes les réponses à tes questions, par contre, je peux te >>confirmer que les fonctions sOuvre,sLit,.... fonctionnent jusqu'a > > COM9(neuf) > >>Cordialement >> >>Michel > > > Merci de cette precision qui me rassure... > A partir de quelle version ? > parce que je suis en 203m, et la doc dit COM1 a COM4 > > a partir de WD5.5 :D
en 7.5 j'ai pas fait l'essai
Michel
:)
Je viens de telecharger la doc 206e. Dedans, c'est egalement ecrit COM1 a COM4. Mais j'ai pas essaye non plus... A l'occasion quand j'aurais plus avance dans mes histoires de modems, je mettrai une carte multivoies dans mon PC pour voir ce que ca fait.
En tout cas, sur rmon PC ou il n'y a quun port COM, le code : SI PAS sOuvre(1,2000,2000) ALORS Erreur(ErreurInfo()) SINON Info("COM1 ouvert"); sFerme(1) FIN
(puis pareil pour COM4 et COM8)
me dit que COM1 est ouvert, et pour com4 et com8, le meme message d'erruer : <<Le mécanisme de sécurité du W-Langage a détecté une erreur sur le port. Détail de l'erreur système :Le fichier spécifié est introuvable.>>
Donc le fait de lui demander d'ouvrir COM8 alors que c'est pas prevu (par la doc ;-) ) ne lui pose pas plus de problemes que de lui demander d'ouvrir COM4, ce qui est prevu. (alors que COM4 n'existe pas)
La question reste momentanement en suspend...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
