Coconut29200
Messages postés15Date d'inscriptionmercredi 4 avril 2007StatutMembreDernière intervention 4 juin 2007
-
3 mai 2007 à 07:56
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 2014
-
3 mai 2007 à 10:26
bonjour
je dévelloppe une appli sous VB6 et le PC que j'utilise est sous Windows2000.
Mon application est-elle immédiatement compatible avec Win98 ? et Win NTServer?
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 3 mai 2007 à 08:02
Tout dépend des composants que ton application utilise éventuellement et des fonctions de l'Api de Windows dont elle se sert éventuellement. Certains de ces composants et Dll peuvent ne pas "aller" sur toutes les versions de Windows ou ne pas (pour certaines fonctions) retourner les mêmes valeurs ou encore entraîner les mêmes effets.
Coconut29200
Messages postés15Date d'inscriptionmercredi 4 avril 2007StatutMembreDernière intervention 4 juin 2007 3 mai 2007 à 08:12
Ok et il n'ya pas une maniére pour être sur que ça passe?
Parceque je dois mettre mon logiciel sur un réseau ultra-sécurisé(les
machines qui y ont accés ont pas de port usb,pas de lecteur
disquette,pas de lecteur cd...)donc je dois passer par un service
spéciale de l'entreprise pour mettre mon logiciel sur ce réseau et je
me vois mal essayer de bidouiller en rajoutant des dll ou d autres
trucs sur ces réseaux(qui n'ont evidemment pas d'accés internet)
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 3 mai 2007 à 08:24
C'est au moment où tu développes ton application qu'il t'appartient de vérifier (en te documentant) la compatibilité des composants que tu ajouterais et des fonctions de l'Api de Windows que tu déclarerais.
En ce qui concerne les composants "ajoutés" : une chose est certaine : plus tu rechercheras ton "confort de développement", plus tu t'exposeras à des risques de compatibilité. Il vaut toujours mieux travailler un peu plus et améliorer l'indpendance de ton application en faisant, au besoi, plutôt appel à l'API de Windows (car les fonctions de cette API sont en règle générale beaucoup moins souvent susceptibles de se heuter à des problèmes de compatibilité. Beaucoup moins souvenbt ne voulant pas dire jamais, toutefois).
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 3 mai 2007 à 08:35
Je reviens, avec une autre préoccupation qui doit te "hanter" également en matière de perennité de ton application :
Dans le même ordre d'idée : il est (tout au moins à mon point de vue) extrêmement maladroit de "piloter" depuis VB des applications externes (telles Word, Excel, etc...) car ce "pilotage" induit l'écriture de lignes de codes susceptibles d'être comprises par ces applications (mais qui peuvent être différentes selon les versions installées sur la machine "cliente" .. Pire, le "clent" peut décider, demain, d'installer une nouvelle version de ces applications. Celà a déjà été le cas entre avant et après VBA et sera vraisemblablement à nouveau le cas un jour ou l'autre !...)
.
Vous n’avez pas trouvé la réponse que vous recherchez ?
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 3 mai 2007 à 09:04
Je reviens et ajoute ceci :
Quelles que soient les précautions prises : on ne distribue jamais une application sans passer par deux étapes importantes :
1) étape de qualification simple (dite de "grattage") au cours de laquelles plusieurs intervenants cherchent à faire "planter" l'application (saisies incohérentes, frappes de touches simultanément, recherches des cas particuliers etc...)
2) étape de qualification "avancée" : tests sur plusieurs machines de performances différentes et de systèmes d'exploitation différents.
Coconut29200
Messages postés15Date d'inscriptionmercredi 4 avril 2007StatutMembreDernière intervention 4 juin 2007 3 mai 2007 à 09:33
tu dis"Dans le même ordre d'idée : il est (tout au moins à mon point de vue)
extrêmement maladroit de "piloter" depuis VB des applications externes
(telles Word, Excel, etc...)"
or c'est le principe meme de mon programme(je suis en stage et je fais ce qu'on me demande c tout).
Et je n'ai pas plusieurs personnes qui pourraient consacré un peu de
temps à essaayer de débusquer des bugs de mon prog,le service ou je
suis est déja trés juste niveau planning. Et les accés aux machines
sont trés limités(toujours par sécurité) donc je ne peu pas effectuer
une série de test sur différentes machines.
Merci pour tes conseils mais dans mon cas je ne peut pas tous les appliquer
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 3 mai 2007 à 09:41
Je ne peux dans ce cas que compatir...
Prends donc toutefois la précaution (surtout si tu es en stage car celà montrera ton sérieux et ton esprit consciencieux) d'appeler l'attention de ton responsable de stage sur ces aspects. Il ne pourra que t'en féliciter, d'une part et, d'autre part, nul ne popurra te reprocher de ne pas avoir su prévenir (surtout en ce qui concerne les risques induits par un "pilotage" en ce qui concerne la pérennité de ce que l'on te fait ainsi développer, puisque celà t'est demandé et n'est donc pas ton choix). Je te conseille même d'inclure quelques lignes à ce propos dans ton rapport de fin de stage.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 3 mai 2007 à 10:26
Je viens mettre mon grain de sel.
la compatibilité multiplateforme est un point délicat du développement notamment concernat Win98. En effet si généralement on obtient un bon taux de compatibilité entre NT4.0, W2000, WinXP qui sont tous des noyaux NT, il en va tout autrement de Win98 et Millenium qui eux ne sont pas basés sur un noyau NT.
Pour avoir un peu plus de chance de compatibilité, il faut s'assurer ne pas utiliser explicitement des api windows propre à W2000 et rester le plus possible dans l'utilisation des composants classiques de VB6. De même il faut faire attention lorsqu'on rajoute des références au projet.
De plus si une application développée avec W2000, pour peu qu'elle n'utilise pas de fonctions vraiment spécifique du système, assure genralement une compatibilité ascendante (compatible XP), il en va autrement pour la compatibilité descendante (NT4.0). En effet, NT4.0 étant la génération precedente de l'os par rapport à W2000, il faut s'assurer que l'appli n'utilise pas de fonctions nouvellement introduite avec W2000.
Ainsi dans mon ancienne boite, pour résoudre très simplement ce problème en acord avec le client (un très grand groupe industriel mondial), la solution utlisée a été de recompiler l'application sur chaque plateforme et de distruber un installable par plateforme couverte. Certe ce n'est pas forcément très pro comme solution.
La seule solution qu'il te reste c'est de faire des tests appronfondis et poussés sur chaque plateforme visée.
Concernant le développement pour Office, le problème est identique. Si tu développe sur ton PC pour Office 2003, toutes les autres machines devraient normalement avoir Office 2003 ensuite pour fonctionner. Quelque fois ça passe si la version d'Office n'est pas la même, mais souvent ça pose problème.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #