L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il pas un
véritable projet d'Access en dotnet ? (autre que la prothèse VSTO qui n'est
guère convaincante)
Pour la conception d'application de base de données, il est difficile de
faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet est
beaucoup plus stable qu'Access pour des applications professionnelles
(Access crash des dizaines de fois au cours du développement d'une
application, toutes versions confondues). Je cherche en vain de la doc sur
par exemple comment retrouver l'assistant création de formulaire d'Access
sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité
Access en dotnet, alors je pourrais concevoir des applications pures dotnet
utilisant des bases Access, sans avoir besoin d'Office pour utiliser
l'application, ce qui est nettement plus simple que l'encapsuler du code
dotnet dans un document Office 2003 (ce qui est le principe de VSTO, et qui
n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique version
dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci.
-------------------------------------------------------
Patrice Dargenton
patrice.dargenton@free.fr
http://patrice.dargenton.free.fr/index.html
-------------------------------------------------------
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Maxence HUBICHE
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== Maxence HUBICHE
MVP Access Revendeur CaseStudio (http://www.casestudio.fr) Responsable Access sur http://www.developpez.com La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il pas un véritable projet d'Access en dotnet ? (autre que la prothèse VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile de faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet est beaucoup plus stable qu'Access pour des applications professionnelles (Access crash des dizaines de fois au cours du développement d'une application, toutes versions confondues). Je cherche en vain de la doc sur par exemple comment retrouver l'assistant création de formulaire d'Access sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité Access en dotnet, alors je pourrais concevoir des applications pures dotnet utilisant des bases Access, sans avoir besoin d'Office pour utiliser l'application, ce qui est nettement plus simple que l'encapsuler du code dotnet dans un document Office 2003 (ce qui est le principe de VSTO, et qui n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique version dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci. ------------------------------------------------------- Patrice Dargenton
Hello Patrice,
encapsuler du code dans un document Office ... ?
T'es sûr de bien avoir compris comment fonctionne VSTO ?
ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== Maxence HUBICHE
MVP Access
Revendeur CaseStudio (http://www.casestudio.fr)
Responsable Access sur http://www.developpez.com
La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il
pas un véritable projet d'Access en dotnet ? (autre que la prothèse
VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile
de
faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet
est
beaucoup plus stable qu'Access pour des applications professionnelles
(Access crash des dizaines de fois au cours du développement d'une
application, toutes versions confondues). Je cherche en vain de la doc
sur
par exemple comment retrouver l'assistant création de formulaire
d'Access
sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité
Access en dotnet, alors je pourrais concevoir des applications pures
dotnet
utilisant des bases Access, sans avoir besoin d'Office pour utiliser
l'application, ce qui est nettement plus simple que l'encapsuler du
code
dotnet dans un document Office 2003 (ce qui est le principe de VSTO,
et qui
n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique
version
dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci.
-------------------------------------------------------
Patrice Dargenton
patrice.dargenton@free.fr
http://patrice.dargenton.free.fr/index.html
-------------------------------------------------------
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== Maxence HUBICHE
MVP Access Revendeur CaseStudio (http://www.casestudio.fr) Responsable Access sur http://www.developpez.com La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il pas un véritable projet d'Access en dotnet ? (autre que la prothèse VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile de faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet est beaucoup plus stable qu'Access pour des applications professionnelles (Access crash des dizaines de fois au cours du développement d'une application, toutes versions confondues). Je cherche en vain de la doc sur par exemple comment retrouver l'assistant création de formulaire d'Access sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité Access en dotnet, alors je pourrais concevoir des applications pures dotnet utilisant des bases Access, sans avoir besoin d'Office pour utiliser l'application, ce qui est nettement plus simple que l'encapsuler du code dotnet dans un document Office 2003 (ce qui est le principe de VSTO, et qui n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique version dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci. ------------------------------------------------------- Patrice Dargenton
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
et aussi l'inverse : le document peut appeler du code dotnet dans la dll : ces appels sont encapsulés dans le document office.
http://msdn.microsoft.com/office/understanding/vsto/default.aspx?pull=/library/en-us/odc_vsto2005_ta/html/officevstoservercapabilities.asp Overview of Server Capabilities in Visual Studio 2005 Tools for Office : In addition, the ability to use managed code behind the document at the client, combined with the ability to merge data in a high-performance way on the server, offers solution developers many new options
"managed code behind the document at the client" ca veut bien dire ce que ca veut dire : du code dotnet derrière le document sur le poste client, non ? L'autre point important étant le support applicatif du coté serveur pour les documents office.
Pour le moment, moi j'utilise très bien du code dotnet accédant à une base Access, même en écriture. Mais je n'ai encore jamais fait un formulaire de saisie en dotnet sur une base Access, car je trouve qu'il faut partir de trop bas niveau pour faire cela, par rapport à l'équivalent sous Access : il est possible de faire des applications fonctionnelles quasi complètes sans écrire une ligne de code sous Access (par exemple un formulaire maitre/esclave avec un sous-formulaire). On en est encore loin via DotNet.
de plus, VSTO n'interface pas Access pour le moment... Je crains qu'il n'y ait quelques mélanges là ! :s
Si yen a qui veulent vraiment faire cela, il est toujours possible de lancer un VB6.Shell sur du code DotNet via un .exe.Net
Sinon, tu as jeté un oeil sur InfoPath ?
Bof, ce qui m'intéresse, c'est plutot du Client riche dotnet sur une base Access : le meilleur des deux mondes. ------------------------------------------------------- Patrice Dargenton
"Maxence HUBICHE" a écrit dans le message de news:
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== > Maxence HUBICHE
MVP Access Revendeur CaseStudio (http://www.casestudio.fr) Responsable Access sur http://www.developpez.com La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il pas un véritable projet d'Access en dotnet ? (autre que la prothèse VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile de faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet est beaucoup plus stable qu'Access pour des applications professionnelles (Access crash des dizaines de fois au cours du développement d'une application, toutes versions confondues). Je cherche en vain de la doc sur par exemple comment retrouver l'assistant création de formulaire d'Access sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité Access en dotnet, alors je pourrais concevoir des applications pures dotnet utilisant des bases Access, sans avoir besoin d'Office pour utiliser l'application, ce qui est nettement plus simple que l'encapsuler du code dotnet dans un document Office 2003 (ce qui est le principe de VSTO, et qui n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique version dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci. ------------------------------------------------------- Patrice Dargenton
Hello Patrice,
encapsuler du code dans un document Office ... ?
T'es sûr de bien avoir compris comment fonctionne VSTO ?
ton document devient client d'une dll.
et aussi l'inverse : le document peut appeler du code dotnet dans la dll :
ces appels sont encapsulés dans le document office.
http://msdn.microsoft.com/office/understanding/vsto/default.aspx?pull=/library/en-us/odc_vsto2005_ta/html/officevstoservercapabilities.asp
Overview of Server Capabilities in Visual Studio 2005 Tools for Office :
In addition, the ability to use managed code behind the document at the
client, combined with the ability to merge data in a high-performance way on
the server, offers solution developers many new options
"managed code behind the document at the client" ca veut bien dire ce que ca
veut dire : du code dotnet derrière le document sur le poste client, non ?
L'autre point important étant le support applicatif du coté serveur pour les
documents office.
Pour le moment, moi j'utilise très bien du code dotnet accédant à une base
Access, même en écriture. Mais je n'ai encore jamais fait un formulaire de
saisie en dotnet sur une base Access, car je trouve qu'il faut partir de
trop bas niveau pour faire cela, par rapport à l'équivalent sous Access : il
est possible de faire des applications fonctionnelles quasi complètes sans
écrire une ligne de code sous Access (par exemple un formulaire
maitre/esclave avec un sous-formulaire). On en est encore loin via DotNet.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Si yen a qui veulent vraiment faire cela, il est toujours possible de lancer
un VB6.Shell sur du code DotNet via un .exe.Net
Sinon, tu as jeté un oeil sur InfoPath ?
Bof, ce qui m'intéresse, c'est plutot du Client riche dotnet sur une base
Access : le meilleur des deux mondes.
-------------------------------------------------------
Patrice Dargenton
patrice.dargenton@free.fr
http://patrice.dargenton.free.fr/index.html
-------------------------------------------------------
"Maxence HUBICHE" <mh.webmaster@club-internet.fr> a écrit dans le message de
news: a93294fd1a2928c71ffadcc181a0@msnews.microsoft.com...
Hello Patrice,
encapsuler du code dans un document Office ... ?
T'es sûr de bien avoir compris comment fonctionne VSTO ?
ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== > Maxence HUBICHE
MVP Access
Revendeur CaseStudio (http://www.casestudio.fr)
Responsable Access sur http://www.developpez.com
La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il
pas un véritable projet d'Access en dotnet ? (autre que la prothèse
VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile
de
faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet
est
beaucoup plus stable qu'Access pour des applications professionnelles
(Access crash des dizaines de fois au cours du développement d'une
application, toutes versions confondues). Je cherche en vain de la doc
sur
par exemple comment retrouver l'assistant création de formulaire
d'Access
sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité
Access en dotnet, alors je pourrais concevoir des applications pures
dotnet
utilisant des bases Access, sans avoir besoin d'Office pour utiliser
l'application, ce qui est nettement plus simple que l'encapsuler du
code
dotnet dans un document Office 2003 (ce qui est le principe de VSTO,
et qui
n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique
version
dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci.
-------------------------------------------------------
Patrice Dargenton
patrice.dargenton@free.fr
http://patrice.dargenton.free.fr/index.html
-------------------------------------------------------
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
et aussi l'inverse : le document peut appeler du code dotnet dans la dll : ces appels sont encapsulés dans le document office.
http://msdn.microsoft.com/office/understanding/vsto/default.aspx?pull=/library/en-us/odc_vsto2005_ta/html/officevstoservercapabilities.asp Overview of Server Capabilities in Visual Studio 2005 Tools for Office : In addition, the ability to use managed code behind the document at the client, combined with the ability to merge data in a high-performance way on the server, offers solution developers many new options
"managed code behind the document at the client" ca veut bien dire ce que ca veut dire : du code dotnet derrière le document sur le poste client, non ? L'autre point important étant le support applicatif du coté serveur pour les documents office.
Pour le moment, moi j'utilise très bien du code dotnet accédant à une base Access, même en écriture. Mais je n'ai encore jamais fait un formulaire de saisie en dotnet sur une base Access, car je trouve qu'il faut partir de trop bas niveau pour faire cela, par rapport à l'équivalent sous Access : il est possible de faire des applications fonctionnelles quasi complètes sans écrire une ligne de code sous Access (par exemple un formulaire maitre/esclave avec un sous-formulaire). On en est encore loin via DotNet.
de plus, VSTO n'interface pas Access pour le moment... Je crains qu'il n'y ait quelques mélanges là ! :s
Si yen a qui veulent vraiment faire cela, il est toujours possible de lancer un VB6.Shell sur du code DotNet via un .exe.Net
Sinon, tu as jeté un oeil sur InfoPath ?
Bof, ce qui m'intéresse, c'est plutot du Client riche dotnet sur une base Access : le meilleur des deux mondes. ------------------------------------------------------- Patrice Dargenton
"Maxence HUBICHE" a écrit dans le message de news:
Hello Patrice, encapsuler du code dans un document Office ... ? T'es sûr de bien avoir compris comment fonctionne VSTO ? ton document devient client d'une dll.
de plus, VSTO n'interface pas Access pour le moment...
Je crains qu'il n'y ait quelques mélanges là ! :s
Sinon, tu as jeté un oeil sur InfoPath ?
================== > Maxence HUBICHE
MVP Access Revendeur CaseStudio (http://www.casestudio.fr) Responsable Access sur http://www.developpez.com La plus grosse FAQ Access du Web : http://access.developpez.com/faq
L'avenir d'Access passe-t-il forcement par SQL serveur ? N'y a-t il pas un véritable projet d'Access en dotnet ? (autre que la prothèse VSTO qui n'est guère convaincante)
Pour la conception d'application de base de données, il est difficile de faire plus simple et puissant qu'avec Access, d'un autre coté, dotnet est beaucoup plus stable qu'Access pour des applications professionnelles (Access crash des dizaines de fois au cours du développement d'une application, toutes versions confondues). Je cherche en vain de la doc sur par exemple comment retrouver l'assistant création de formulaire d'Access sous dotnet : si je pouvais avoir l'équivalent de cette fonctionnalité Access en dotnet, alors je pourrais concevoir des applications pures dotnet utilisant des bases Access, sans avoir besoin d'Office pour utiliser l'application, ce qui est nettement plus simple que l'encapsuler du code dotnet dans un document Office 2003 (ce qui est le principe de VSTO, et qui n'a pas grand intérêt). Ou bien faut-il attendre une hypothétique version dotnet d'Office ? Quelqu'un a une piste à suivre ? Merci. ------------------------------------------------------- Patrice Dargenton
