Discussion :

[Maxence HUBICHE]

Imaginez-vous dans la peau de Bill Gates.
Vous avez tout pouvoir !
Vous êtes le maître architecte !

Quels seraient vos projets...
- immédiats
- à moyen terme
- à long terme
pour Access ?


A vos crayons !

[naphta]

Bonsoir,

en 1
un cache façon workspace sur les form+subform mais sur l'ensemble des enregistrements père-fils ouvert

en 2
Le moyen d'exploiter les nouveaux
- listview façon outlook
- FlexGrid hiérarchique
- treeview, progressbar etc

bon de toute façon c'est moi le Bill alors on fait tout vite et proprement
et puis sans SP1 ou SPn

Oh yes, it's good to be the king

[Tofalu]

Une chose qui manque vraiment et à faire dans l'immédiat :

- Une coloration syntaxique et un vrai éditeur de requête pour le code SQL ... C'est à dire autre chose qu'un notepad

[Maxence HUBICHE]

Moi, j'aimerai

• Dans l'immédiat
  
  • une version FullWeb pour faire du développement FullWeb (en liaison avec des serveurs SQLServer)
  • une intégration native de plus de contrôles "évolués", même si on peut le faire depuis de nombreuses versions, j'aimerai que ces contrôles (treeview, progressBar, listView, imageList, ...) soient intégrés à l'appli et décrits dans l'aide en ligne. l'ajout de contrôles sympas du genre : des listes qui premettent l'intégration d'images. Par exemple, je veux faire une liste de pays, je trouverai fun de pouvoir faire apparaitre le drapeau du dit pays en face du nom.
  • Pouvoir créer un exécutable vraiment stand-alone, et multi-plateforme, que je puisse installer ma solution sur un linux, si besoin.
• A moyen terme
  
  • Le développement de l'aspect "migration" pour que les solutions de migration puissent aller jusqu'au bout.
    
    • Migrer un MDB sur SQLServer, c'est rigolo. Mais je reste avec un mdb... c'est nul ! Pourquoi ne pas transformer ce mdb en ADP ? Pourquoi ne pas essayer de migrer un maximum de requêtes en vues/ procédures stockées/ etc. Et enfin, un outil de reporting qui me dit ce qu'il me reste à faire pour que la migration soit parfaite, du genre : impossible de migrer correctement telle requête car elle fait appel à telle et telle et telle fonction utilisateur développée en VBA que nous n'avons pu traduire.
    • Migrer un ACCDB sur SharePoint, c'est rigolo, mais on perd toutes les fonctionnalité d'interface développées si on ne met pas en branle le MONSTRE MOSS ! C'est dommage !
    • Pourquoi ne pas ajouter une fonction de migration de base de données mdb/accdb sur une plateforme Web, en dotnet, avec possibilité de configuration de la base de données SQLServer (et migration des données à la volée, comme indiqué ci-dessus)
    • Ce qui serait cool, ce serait la possibilité de compiler pour d'autres plateformes que Windows...
  • L'intégration de DotNet dans Access, directement, sans passer par un enième EDI. Qu'on puisse programmer Access directement en DotNet, et l'abandon progressif du support de VBA et des macros
• A long terme
  
  • La création d'un gamme de produits Access
    
    • un produit orienté développeur, full objet (héritage, polymorphisme, ...) basé sur le VB.Net (ou C# s'il n'y a pas le choix), bourré des contrôles qu'on aura mis en place lors des étapes précédentes, et d'autres encore. Ce serait un produit qui me permette de choisir le genre de développement (web, riche, ..) que je veux faire, mais aussi, d'en changer en cours de route si je le souhaite, voire même de générer les différentes solutions à la volée, de l'empaqueter, de la compiler, de générer des fichiers d'aide de manière simple, et une documentation technique (et utilisateur) de qualité.
    • un produit orienté utilisateur, qui ne soit pas ouvert sur le code, mais qui serve plus de requêteur et d'outil reporting, afin que l'utilisateur puisse analyser des données et faire des rapports facilement. Ce produit serait bourré d'assistants dans tous les sens afin de guider l'utilisateur, et qu'il ne fasse pas de bêtises amusantes du genre d'un produit cartésien inattendu dans une requête...

Voilà mon rêve

[Invité]

Bonjour Maxence

Voilà mon rêve

Tu es rêveur

Pour ma part j'avais pensé aux procédures évènementielles sur les tables (Trigger) qui à priori vont être mises sur la version 2010 (suite à tes quelques infos).

Je pense aussi à des choses très utiles dans l'interface IHM comme la MFC illimité nativement.

Quand à l'ajout de contrôles supplémentaires nativement, je dis Oui.

[Maxence HUBICHE]

Je suis le seul à rêver ?

[francishop]

Bonsoir,

Dis, Maxence, un soupçon me vient à l'esprit...
Tu ne serais pas en possession de quelques informations complémentaires à
Super Super SUPER!

Cordialement.

[alassanediakite]

Salut
Dans l'imédiat:
1_ Formulaire en mode continu avec sous formulaire
2_ Integration directe des paramètres de sécurités (groupes/utilisateurs et droits) dans le fichier (mdb ou ACCDB) principal contenant les tables.
Dans le moyen terme:
1_ Ne pas s'ecarter de l'objet PME/PMI de la chose
2_ Ne pas rendre la tache trop difficile aux débutants
Je m'excuse du peu

[SeaWolf601]

Que les controles dans un formulaire continu puisse être indépendants les uns des autres.

[User]

Bonjour,

Tout à été dit, notamment avec l'élargissement de la gamme de contrôles natifs.

Je pensais juste à une autre chose pour les requêtes:

Access prévoit des zones de listes comme paramètres des requêtes du style:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PARAMETERS Forms!Form1!ZoneDeListe Text ( 255 );
SELECT *
FROM table1
WHERE Champ=Forms!Form1!ZoneDeListe

Pourquoi Access ne prévoit pas des zones de liste à sélection multiple comme paramètres, avec l'opérateur In, du genre:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PARAMETERS Forms!Form1!ZoneDeListe TypeTableau;
SELECT *
FROM table1
WHERE Champ in Forms!Form1!ZoneDeListe

ça éviterai de le programmer à chaque fois en VBA

Une idée comme ça...

[naphta]

Bonjour,

Vous pouvez, en anglais seulement, proposer des modifications pour accélérer le développement et la saisie.

L'équipe de dev d'access 2010 dont le "Program Manager on the Access team" sont à l'écoute et ils en redemandent.

ici
http://blogs.msdn.com/access/archive....aspx#comments

a+

[Simplifi]

hello
suite à différents posts à propos des bibliothèques CDO ou Acrobat, mon souhait serait une vraie documentation de ces objets, un peu come dans l'aide, avec:
- le descriptif de l'objet et la signification de ses propriétés
- le descriptif de la fonction avec ses arguments et leurs valeurs possibles et le résultat retourné
- des exemples clairs

Bien sûr, les sous formulaires en mode continu seraient appréciés
Bien sûr, la possibilité d'avoir les tables à What mille Km serait génial

Alllez, courage et encore merci à tous

[jacou]

Bonjour,

Je suis pour une uniformisation des projets .accdb et .adp, permettant à Access

1. d'accéder d'une façon native à des tables Serveur SQL au lieu des liens ODBC.
2. de choisir de créer des tables en mode local mode fichier ou bien distant dans SQL Serveur.
3. .FormatConditions plus performant, qui ne fait pas vaciller les formulaires.