il y a t il un moyen dans une page asp.net, côté client, de faire des
appels à une DLL ? Je ne pense pas mais je demande à tout zazard.
Dans le cas où la réponse est non, ce qui me semble être probable, quel
est le moyen le plus simple pour appeler un activeX côté client et
transmettre les infos au serveur ?
Tout le code Asp est executer coté serveur est ne peut pas être executer coté client , sinon on pourrait utiliser l'attribut runat="client" :d
Le moyen le plus simple pour transmettre des données aux serveurs et d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
-- Cordialement
Reviens nous dire si cela a marché. @++
------------------------------------------------------------------ Pierre http://wikims.free.fr/phpBB2/index.php - http://wikims.free.fr/blog/ - http://communautes-ms.akro-net.org - http://wikims.free.fr "Merlin" a écrit dans le message de news:
il y a t il un moyen dans une page asp.net, côté client, de faire des appels à une DLL ? Je ne pense pas mais je demande à tout zazard. Dans le cas où la réponse est non, ce qui me semble être probable, quel est le moyen le plus simple pour appeler un activeX côté client et transmettre les infos au serveur ?
Tout le code Asp est executer coté serveur est ne peut pas être executer
coté client , sinon on pourrait utiliser l'attribut runat="client" :d
Le moyen le plus simple pour transmettre des données aux serveurs et
d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
--
Cordialement
Reviens nous dire si cela a marché.
@++
------------------------------------------------------------------
Pierre
http://wikims.free.fr/phpBB2/index.php - http://wikims.free.fr/blog/ -
http://communautes-ms.akro-net.org - http://wikims.free.fr
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.ebbe7d590879854d.18651@LesFees.Net...
il y a t il un moyen dans une page asp.net, côté client, de faire des
appels à une DLL ? Je ne pense pas mais je demande à tout zazard.
Dans le cas où la réponse est non, ce qui me semble être probable, quel
est le moyen le plus simple pour appeler un activeX côté client et
transmettre les infos au serveur ?
Tout le code Asp est executer coté serveur est ne peut pas être executer coté client , sinon on pourrait utiliser l'attribut runat="client" :d
Le moyen le plus simple pour transmettre des données aux serveurs et d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
-- Cordialement
Reviens nous dire si cela a marché. @++
------------------------------------------------------------------ Pierre http://wikims.free.fr/phpBB2/index.php - http://wikims.free.fr/blog/ - http://communautes-ms.akro-net.org - http://wikims.free.fr "Merlin" a écrit dans le message de news:
il y a t il un moyen dans une page asp.net, côté client, de faire des appels à une DLL ? Je ne pense pas mais je demande à tout zazard. Dans le cas où la réponse est non, ce qui me semble être probable, quel est le moyen le plus simple pour appeler un activeX côté client et transmettre les infos au serveur ?
Bonjour, La réponse est non. Tout le code Asp est executer coté serveur est ne peut pas être executer coté client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
Le moyen le plus simple pour transmettre des données aux serveurs et d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être assez clair... Le problème c'est de lancer un activeX coté client depuis une page aspx pour faire différentes choses et transmettre au serveur les infos collectées par l'activex. C'est la partie activation de l'activex sur le client et une fois son job fini l'envoie des infos sur le serveur qui m'interresse ici.
Bonjour,
La réponse est non.
Tout le code Asp est executer coté serveur est ne peut pas être executer coté
client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera
exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
Le moyen le plus simple pour transmettre des données aux serveurs et
d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être
assez clair...
Le problème c'est de lancer un activeX coté client depuis une page aspx
pour faire différentes choses et transmettre au serveur les infos
collectées par l'activex.
C'est la partie activation de l'activex sur le client et une fois son
job fini l'envoie des infos sur le serveur qui m'interresse ici.
Bonjour, La réponse est non. Tout le code Asp est executer coté serveur est ne peut pas être executer coté client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
Le moyen le plus simple pour transmettre des données aux serveurs et d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être assez clair... Le problème c'est de lancer un activeX coté client depuis une page aspx pour faire différentes choses et transmettre au serveur les infos collectées par l'activex. C'est la partie activation de l'activex sur le client et une fois son job fini l'envoie des infos sur le serveur qui m'interresse ici.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve ???).
WikiPierre a écrit : > Bonjour, > La réponse est non. > Tout le code Asp est executer coté serveur est ne peut pas être executer
coté
> client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
> Le moyen le plus simple pour transmettre des données aux serveurs et > d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être assez clair... Le problème c'est de lancer un activeX coté client depuis une page aspx pour faire différentes choses et transmettre au serveur les infos collectées par l'activex. C'est la partie activation de l'activex sur le client et une fois son job fini l'envoie des infos sur le serveur qui m'interresse ici.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en
HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve
???).
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de
news:mn.ec8b7d59ab5108d9.18651@LesFees.Net...
WikiPierre a écrit :
> Bonjour,
> La réponse est non.
> Tout le code Asp est executer coté serveur est ne peut pas être executer
coté
> client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera
exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
> Le moyen le plus simple pour transmettre des données aux serveurs et
> d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être
assez clair...
Le problème c'est de lancer un activeX coté client depuis une page aspx
pour faire différentes choses et transmettre au serveur les infos
collectées par l'activex.
C'est la partie activation de l'activex sur le client et une fois son
job fini l'envoie des infos sur le serveur qui m'interresse ici.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve ???).
WikiPierre a écrit : > Bonjour, > La réponse est non. > Tout le code Asp est executer coté serveur est ne peut pas être executer
coté
> client , sinon on pourrait utiliser l'attribut runat="client" :d
Ce n'est pas exact. On peut injecter du Jscript dans une page qui sera exécuté côté client. Et heureusement. Donc tout n'est pas côté serveur.
> Le moyen le plus simple pour transmettre des données aux serveurs et > d'utiliser les fichier XML ou un SGDB comme SQL Server par exemple.
c'est pas la transmission qui me gêne, bien entendu. J'ai pas du être assez clair... Le problème c'est de lancer un activeX coté client depuis une page aspx pour faire différentes choses et transmettre au serveur les infos collectées par l'activex. C'est la partie activation de l'activex sur le client et une fois son job fini l'envoie des infos sur le serveur qui m'interresse ici.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve ???).
non pas exactement. Le but du jeu est très simple : dans une page côté client je veux appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que l'activeX en question possède quelques propriétés à initialiser et une méthode "execute" durant laquelle il va chercher disons la liste des fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé, la liste se trouve dans une autre propriété. Côté client je dois détecter la fin de execute et envoyer la liste au serveur, c'est à dire à la page asxp côté serveur.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en
HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve
???).
non pas exactement.
Le but du jeu est très simple : dans une page côté client je veux
appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que
l'activeX en question possède quelques propriétés à initialiser et une
méthode "execute" durant laquelle il va chercher disons la liste des
fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé,
la liste se trouve dans une autre propriété. Côté client je dois
détecter la fin de execute et envoyer la liste au serveur, c'est à dire
à la page asxp côté serveur.
Si c'est comme pour Java et .NET, à priori le contrôle ActiveX communique en HTTP avec le serveur (uniquement celui qui héberge la page où il se trouve ???).
non pas exactement. Le but du jeu est très simple : dans une page côté client je veux appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que l'activeX en question possède quelques propriétés à initialiser et une méthode "execute" durant laquelle il va chercher disons la liste des fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé, la liste se trouve dans une autre propriété. Côté client je dois détecter la fin de execute et envoyer la liste au serveur, c'est à dire à la page asxp côté serveur.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit : > Si c'est comme pour Java et .NET, à priori le contrôle ActiveX
communique en
> HTTP avec le serveur (uniquement celui qui héberge la page où il se
trouve
> ???).
non pas exactement. Le but du jeu est très simple : dans une page côté client je veux appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que l'activeX en question possède quelques propriétés à initialiser et une méthode "execute" durant laquelle il va chercher disons la liste des fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé, la liste se trouve dans une autre propriété. Côté client je dois détecter la fin de execute et envoyer la liste au serveur, c'est à dire à la page asxp côté serveur.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la
fin via HTTP avec un POST vers le serveur...
--
Patrice
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de
news:mn.ed6b7d59a2b6033c.18651@LesFees.Net...
Patrice a écrit :
> Si c'est comme pour Java et .NET, à priori le contrôle ActiveX
communique en
> HTTP avec le serveur (uniquement celui qui héberge la page où il se
trouve
> ???).
non pas exactement.
Le but du jeu est très simple : dans une page côté client je veux
appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que
l'activeX en question possède quelques propriétés à initialiser et une
méthode "execute" durant laquelle il va chercher disons la liste des
fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé,
la liste se trouve dans une autre propriété. Côté client je dois
détecter la fin de execute et envoyer la liste au serveur, c'est à dire
à la page asxp côté serveur.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit : > Si c'est comme pour Java et .NET, à priori le contrôle ActiveX
communique en
> HTTP avec le serveur (uniquement celui qui héberge la page où il se
trouve
> ???).
non pas exactement. Le but du jeu est très simple : dans une page côté client je veux appeler un activeX. Disons pour simplifier, mais ce n'est pas çà, que l'activeX en question possède quelques propriétés à initialiser et une méthode "execute" durant laquelle il va chercher disons la liste des fichiers du répertoire (c'est un ex bidon). Une fois "execute" terminé, la liste se trouve dans une autre propriété. Côté client je dois détecter la fin de execute et envoyer la liste au serveur, c'est à dire à la page asxp côté serveur.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la
fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je
préfèrerais trouver un procédé qui reste dans le cycle des postbacks
pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté
client, quelle est la meilleure façon de le déployer de façon
transparente lors de la première connexion à la page, comment le mettre
à jour tout aussi automatiquement s'il est updaté, comment l'intialiser
dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net
en fait.
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Il y a la toujours la solution d'utiliser une applet java communiquant avec l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y a plus simple.
F.
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.f29b7d5985209bc3.18651@LesFees.Net...
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en
fait.
Il y a la toujours la solution d'utiliser une applet java communiquant avec
l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A
l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y
a plus simple.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Il y a la toujours la solution d'utiliser une applet java communiquant avec l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y a plus simple.
F.
Patrice
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et de placer le résultat dans un champ caché. Tu récupères donc les données dans le cycle normal de la page.
Pour la mise à jour c'est à priori automatique (la balise "object" pointe vers la DLL concernée, je crois que la version peut-être indiquée aussi ce qui permet à IE de récupérer la bonne version si nécessaire). Attention aussi à la sécurité (il faudra signer le contrôle notamment). A la première utilisation, l'utilisateur devra approuver l'installation du contrôle. Il peut aussi "toujours faire confiance à l'editeur" ce qui permet sans doute de mettre à jour ou installer les autres contrôle signés avec le même certificat sans autre question...
Voir par exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vccore/html/_core_upgrading_an_existing_activex_control_to_be_used_on_the_internet.asp
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple upload multiple avec drag and drop cela doit exister).
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit : > Quelle est le point qui diffère ? Pour moi la transmission se ferait à
la
> fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner
la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et
de placer le résultat dans un champ caché.
Tu récupères donc les données dans le cycle normal de la page.
Pour la mise à jour c'est à priori automatique (la balise "object" pointe
vers la DLL concernée, je crois que la version peut-être indiquée aussi ce
qui permet à IE de récupérer la bonne version si nécessaire). Attention
aussi à la sécurité (il faudra signer le contrôle notamment). A la première
utilisation, l'utilisateur devra approuver l'installation du contrôle. Il
peut aussi "toujours faire confiance à l'editeur" ce qui permet sans doute
de mettre à jour ou installer les autres contrôle signés avec le même
certificat sans autre question...
Voir par exemple :
http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vccore/html/_core_upgrading_an_existing_activex_control_to_be_used_on_the_internet.asp
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu
peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple
upload multiple avec drag and drop cela doit exister).
--
Patrice
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de
news:mn.f29b7d5985209bc3.18651@LesFees.Net...
Patrice a écrit :
> Quelle est le point qui diffère ? Pour moi la transmission se ferait à
la
> fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je
préfèrerais trouver un procédé qui reste dans le cycle des postbacks
pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté
client, quelle est la meilleure façon de le déployer de façon
transparente lors de la première connexion à la page, comment le mettre
à jour tout aussi automatiquement s'il est updaté, comment l'intialiser
dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net
en fait.
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et de placer le résultat dans un champ caché. Tu récupères donc les données dans le cycle normal de la page.
Pour la mise à jour c'est à priori automatique (la balise "object" pointe vers la DLL concernée, je crois que la version peut-être indiquée aussi ce qui permet à IE de récupérer la bonne version si nécessaire). Attention aussi à la sécurité (il faudra signer le contrôle notamment). A la première utilisation, l'utilisateur devra approuver l'installation du contrôle. Il peut aussi "toujours faire confiance à l'editeur" ce qui permet sans doute de mettre à jour ou installer les autres contrôle signés avec le même certificat sans autre question...
Voir par exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vccore/html/_core_upgrading_an_existing_activex_control_to_be_used_on_the_internet.asp
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple upload multiple avec drag and drop cela doit exister).
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit : > Quelle est le point qui diffère ? Pour moi la transmission se ferait à
la
> fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Il y a la toujours la solution d'utiliser une applet java communiquant avec l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y a plus simple.
oui c'est lourdingue, et je voudrais justement trouver quelque chose de plus simple...
Il y a la toujours la solution d'utiliser une applet java communiquant avec
l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A
l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y
a plus simple.
oui c'est lourdingue, et je voudrais justement trouver quelque chose de
plus simple...
Il y a la toujours la solution d'utiliser une applet java communiquant avec l'activeX via le JNI, mais c'est un peu lourdingue de mise en oeuvre. A l'époque "pre .NET" c'est la techique que j'utilisais, mais je pense qu'il y a plus simple.
oui c'est lourdingue, et je voudrais justement trouver quelque chose de plus simple...
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et de placer le résultat dans un champ caché. Tu récupères donc les données dans le cycle normal de la page.
Oui c'est une solution intéressante en effet.
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple upload multiple avec drag and drop cela doit exister).
Le problème est d'encapsuler l'appel d'une DLL côté client pour un système d'authentification par carte magnétique. La DLL ne pouvant être appelée depuis une page aspx côté client, mon idée est de faire un activeX qui lui peut être utilisé dans la page et qui utilisera par derrière la dll en question. C'est donc une encaspulation plus que le développement d'un contrôle. Pour le réalisé j'ai le choix mais il sera vraissemblablement fait sous delphi (le client n'utilise pas c++ mais delphi). Cette partie là ne me pose aucun souci. C'est juste l'intégration de l'activex dans une page aspx, l'initialisation de ses propriétés depuis des valeurs envoyées par le serveur, le lancement de méthode "execute" et le renvoi des infos aux serveurs. ça passe par du javascript que je maîtrise pas au niveau de delphi win32 ou n.net ou c#. Pour les dev Web j'ai toujours réussi à me passer de JS ou a n'utiliser que des fonctions simples dont on trouve en plus plein d'exemples tout fait sur le web..
Donc c'est surtout un exemple d'une telle intégration d'un activex dans une page aspx que je cherche.
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit :
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner
la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et
de placer le résultat dans un champ caché.
Tu récupères donc les données dans le cycle normal de la page.
Oui c'est une solution intéressante en effet.
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu
peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple
upload multiple avec drag and drop cela doit exister).
Le problème est d'encapsuler l'appel d'une DLL côté client pour un
système d'authentification par carte magnétique. La DLL ne pouvant être
appelée depuis une page aspx côté client, mon idée est de faire un
activeX qui lui peut être utilisé dans la page et qui utilisera par
derrière la dll en question.
C'est donc une encaspulation plus que le développement d'un contrôle.
Pour le réalisé j'ai le choix mais il sera vraissemblablement fait sous
delphi (le client n'utilise pas c++ mais delphi). Cette partie là ne me
pose aucun souci.
C'est juste l'intégration de l'activex dans une page aspx,
l'initialisation de ses propriétés depuis des valeurs envoyées par le
serveur, le lancement de méthode "execute" et le renvoi des infos aux
serveurs. ça passe par du javascript que je maîtrise pas au niveau de
delphi win32 ou n.net ou c#. Pour les dev Web j'ai toujours réussi à me
passer de JS ou a n'utiliser que des fonctions simples dont on trouve
en plus plein d'exemples tout fait sur le web..
Donc c'est surtout un exemple d'une telle intégration d'un activex dans
une page aspx que je cherche.
--
Patrice
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de
news:mn.f29b7d5985209bc3.18651@LesFees.Net...
Patrice a écrit :
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la
fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je
préfèrerais trouver un procédé qui reste dans le cycle des postbacks
pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté
client, quelle est la meilleure façon de le déployer de façon
transparente lors de la première connexion à la page, comment le mettre
à jour tout aussi automatiquement s'il est updaté, comment l'intialiser
dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net
en fait.
Dans ce cas tu pourrais exposer la fonction dans ton contrôle et retourner la liste. En JavaScript cela permet d'appeler la méthode qui t'interesse et de placer le résultat dans un champ caché. Tu récupères donc les données dans le cycle normal de la page.
Oui c'est une solution intéressante en effet.
Que veux tu utiliser pour créer ton contrôle ? Selon ce que tu veux faire tu peux aussi peut-être en trouver qui font déjà ce que tu veux ? (par exemple upload multiple avec drag and drop cela doit exister).
Le problème est d'encapsuler l'appel d'une DLL côté client pour un système d'authentification par carte magnétique. La DLL ne pouvant être appelée depuis une page aspx côté client, mon idée est de faire un activeX qui lui peut être utilisé dans la page et qui utilisera par derrière la dll en question. C'est donc une encaspulation plus que le développement d'un contrôle. Pour le réalisé j'ai le choix mais il sera vraissemblablement fait sous delphi (le client n'utilise pas c++ mais delphi). Cette partie là ne me pose aucun souci. C'est juste l'intégration de l'activex dans une page aspx, l'initialisation de ses propriétés depuis des valeurs envoyées par le serveur, le lancement de méthode "execute" et le renvoi des infos aux serveurs. ça passe par du javascript que je maîtrise pas au niveau de delphi win32 ou n.net ou c#. Pour les dev Web j'ai toujours réussi à me passer de JS ou a n'utiliser que des fonctions simples dont on trouve en plus plein d'exemples tout fait sur le web..
Donc c'est surtout un exemple d'une telle intégration d'un activex dans une page aspx que je cherche.
-- Patrice
"Merlin" a écrit dans le message de news:
Patrice a écrit :
Quelle est le point qui diffère ? Pour moi la transmission se ferait à la fin via HTTP avec un POST vers le serveur...
la partie de post, oui, c'est une solution possible. Mais je préfèrerais trouver un procédé qui reste dans le cycle des postbacks pour rester sur la page en cours.
Le second point concerne l'activex: sachant qu'il doit être côté client, quelle est la meilleure façon de le déployer de façon transparente lors de la première connexion à la page, comment le mettre à jour tout aussi automatiquement s'il est updaté, comment l'intialiser dans la page aspx avec des valeurs envoyées par le serveur, etc.
c'est la plomberie liée à l'activex qui me pose problème, pas asp.net en fait.
