Exporter (0) Imprimer
Développer tout
0 sur 1 ont trouvé cela utile - Évaluez ce sujet

FAQ pour développeurs sur la migration des plates-formes Windows Mobile

Microsoft

Septembre 2004

S'applique à :
   Windows Mobile™ (logiciel)
   Pocket PC sur Windows Mobile
   Smartphone sur Windows Mobile
   Microsoft eMbedded Visual C++®
   Microsoft eMbedded Visual Basic®

Résumé : Cet article traite des problèmes les plus courants et des questions les plus fréquentes que se posent les développeurs au sujet de la migration d'une version de la plate-forme Microsoft Windows Mobile vers une autre. Cet article contient des liens vers des pages en anglais. (10 pages imprimées)

Sommaire

Introduction
Interface utilisateur
Fichiers et stockage
Sécurité
Matériel
Navigation et connectivité Internet
Affichage
Audio
Environnements de compilation et de développement
Nous contacter

Introduction

Le logiciel Windows Mobile™ est conçu pour s'adapter aisément à une large gamme de périphériques ainsi qu'au plus grand nombre de fabricants, d'opérateurs de mobiles et d'intégrateurs. Pour créer une plate-forme dotée d'un ensemble conséquent de fonctions de développement, la plate-forme Windows Mobile fournit deux plates-formes distinctes : la plate-forme Pocket PC sur Windows Mobile et la plate-forme Smartphone sur Windows Mobile. Au sein de ces deux catégories, la plate-forme Windows Mobile permet aux opérateurs et aux OEM de procéder à des personnalisations et de créer ainsi des périphériques uniques et séduisants. Notre objectif, chez Microsoft, est de garantir aux développeurs une expérience cohérente sur tous ces périphériques de sorte que les applications créées sur un périphérique et une plate-forme (Pocket PC et Smartphone) fonctionnent sans modification ou presque sur le périphérique voisin. Malgré nos précautions, il existe certaines variations entre les produits et les plates-formes, ces variations pouvant induire des différences de comportement d'un périphérique à l'autre.

Nous veillons à fournir à notre communauté de développeurs un maximum d'informations et cet article couvre une partie des problèmes les plus courants et des questions les plus fréquentes au sujet de la migration entre périphériques et plates-formes. Vous trouverez à la fin de cet article un alias de messagerie qui vous sera utile pour nous signaler des problèmes récurrents que nous pourrons ajouter à cette FAQ.

Cette FAQ s'adresse aux développeurs souhaitant migrer d'une ancienne version du logiciel Windows Mobile vers une nouvelle ou développer une base de code unique pour tous les périphériques sur Windows Mobile.

Interface utilisateur

Pourquoi les accélérateurs numériques de mes menus Smartphone sont-ils dupliqués ?

Lorsque vous créez un menu pour un Smartphone sur Windows Mobile 2003, le système d'exploitation ajoute automatiquement des accélérateurs numériques, ou raccourcis, au menu. Comme le système d'exploitation le fait automatiquement pour vous, le guide Designed for Windows Mobile Software Application Handbook for Smartphone Site en anglais précise que vous ne devez pas ajouter de numéros aux menus si vous souhaitez donner des touches de raccourcis. Cette modification a été adoptée lors du passage de Smartphone 2002 à Smartphone 2003, ce qui explique que les applications qui ajoutent manuellement des accélérateurs créent des doublons sur la plate-forme 2003.

Pourquoi les touches de raccourcis ne fonctionnent-elles pas avec les zones de liste sur Smartphone 2003 ?

Lorsque l'interface Smartphone présente une liste ou un menu, vous pouvez généralement utiliser le clavier pour accéder plus rapidement à l'élément souhaité en appuyant sur la touche de clavier correspondante. Ainsi, si vous affichez votre liste de sons ou de sonneries et que vous appuyez sur la touche 3, vous parvenez directement sur le premier élément de la liste commençant par la lettre « d ». Cette fonctionnalité ne pose pas de problème avec les applications du téléphone en ROM mais il peut arriver que les applications que vous développez avec Microsoft® eMbedded Visual C++® ou Microsoft Visual Studio® ne tiennent pas compte de ces combinaisons de touches dans les zones de liste. Ces combinaisons de touches seront corrigées dans les prochaines versions de Smartphone. Vous pouvez également contourner ce problème en sous-classant la fenêtre cible et en filtrant WM_IME_COMPOSITION pour sélectionner manuellement l'élément dans votre liste.

Pourquoi les barres de progression ne s'affichent-elles pas correctement ?

Certains périphériques sur Windows Mobile ont été commercialisés avec les couleurs systèmes définies sur les mêmes valeurs pour COLOR_BTNFACE et COLOR_HIGHLIGHT. Généralement, ces valeurs sont différentes et donc, lorsque COLOR_BTNFACE et COLOR_HIGHLIGHT ont la même couleur, il est possible que certains éléments de l'interface ne s'affichent pas aussi distinctement que prévu. Vous devez donc comparer les valeurs de BTNFACE et de HIGHLIGHT et redéfinir la valeur des couleurs de COLOR_BTNFACE et de COLOR_HIGHLIGHT si elles sont identiques.

Mon Pocket PC signalait certains événements par clignotement du voyant. Cela semble avoir changé entre 2002 et 2003. D'où vient cette différence ?

Pocket PC 2002 propose des options sous « Sons et rappels » pour définir la durée des options « Afficher un message à l'écran » et « Clignoter pendant ». Ces choix ne sont plus disponibles dans Windows Mobile 2003 pour Pocket PC. Pour plus d'informations, reportez-vous à Differences in LED flashing functionality between Pocket PC 2002 and Pocket PC 2003 Site en anglais.

Fichiers et stockage

Comment faire pour identifier de manière cohérente les emplacements de stockage sur les périphériques ?

Smartphone dispose de deux types de stockage : un magasin volatile et un magasin permanent. Le magasin volatile est réinitialisé chaque fois que vous éteignez le téléphone. Toutes les données devant être conservées lorsque le téléphone est éteint sont enregistrées dans le magasin permanent. Ce magasin est monté sous forme de répertoire à la racine pour les logiciels Windows Mobile 2003 pour Smartphone et Windows Mobile 2003 Deuxième Édition pour Smartphone.

La plupart des périphériques Smartphone 2002 utilisent un dossier IPSM qui représente leurs emplacements de stockage permanent. Avec Smartphone 2003, l'emplacement par défaut est généralement appelé « Storage ». Pour vous assurer que votre application parvient toujours à détecter le bon chemin de stockage, nous vous conseillons de tirer parti de l'API SHGetSpecialFolderPath pour déterminer un emplacement de stockage commun, tel que Mes Documents.

Il arrive également que le nom des emplacements des cartes de stockage des Smartphone et des Pocket PC varie d'un constructeur à l'autre. Comme un périphérique peut avoir plusieurs cartes de stockage portant des noms différents, votre application ne peut faire aucune hypothèse quant au nom ou au chemin d'une carte donnée. Utilisez les fonctions FindFirstFlashCard et FindNextFlashCard pour effectuer dans un programme une énumération des cartes de stockage.

Pourquoi mon application échoue-t-elle après une interruption, puis une reprise ?

Pourquoi mes handles de fichiers sont-ils incorrects sur la carte de stockage après la mise hors tension puis sous tension du Pocket PC ?

Avec la plate-forme 2003, le délai par défaut pouvant affecter le chargement et le déchargement de certains pilotes suite à un événement d'interruption/reprise a été réduit. Ce délai peut avoir un effet sur les applications qui attendent que les handles de fichiers associés aux cartes SD soient conservés pendant un événement interruption/reprise très court. Si vous rencontrez des problèmes de migration vers Windows Mobile 2003 avec des applications qui attendent que les fichiers restent ouverts sur les cartes SD entre les événements d'interruption/reprise, nous vous conseillons de faire passer à 4096 la valeur suivante du registre si elle est plus basse :

HKEY_LOCAL_MACHINE\System\StorageManager

PNPUnloadDelay : 4096

Pourquoi m'est-il impossible d'installer un logiciel sur certains périphériques Smartphone ?

Les Smartphone sur Windows Mobile ont un modèle de sécurité d'application que le fabricant du périphérique ou l'opérateur du mobile peut configurer. Ce modèle de sécurité est présenté en détail dans l'article A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers Site en anglais.

Outre les configurations de sécurité standard recommandées par Microsoft, le modèle de sécurité du Smartphone permet à un opérateur de mobiles ou à un fabricant de périphériques de personnaliser le périphérique pour protéger ses ressources. Dans la plupart des cas, il vous suffira simplement de consulter les configurations de sécurité diffusées par chaque opérateur pour comprendre le niveau de signature nécessaire pour installer un logiciel sur votre périphérique et l'exécuter. Gardez à l'esprit que toute tentative de modification des zones protégées du registre ou des données du périphérique au cours de l'installation ou de l'exécution du logiciel peut être refusée. De par la nature transactionnelle de l'installation sur le Smartphone, toute tentative de modification d'une clé de registre protégée peut provoquer l'échec complet de l'installation. Ainsi, certains téléphones du modèle Samsung i600 sécurisaient à l'origine la clé de registre HKCR, ce qui avait pour résultat de provoquer l'échec de certaines installations d'applications qui tentaient d'enregistrer une association de fichier sous HKCR. Samsung a diffusé un correctif pour exposer à nouveau cette clé. Pour plus d'informations, consultez les articles suivants :

Je constate que mon application a des comportements imprévisibles sur certains périphériques. Quelle peut en être la cause ?

Mon application se lance mais est interrompue par le système. Que se passe-t-il ?

La plate-forme Windows Mobile est conçue pour s'exécuter sur les périphériques avec peu de mémoire. En général, vous devez vous assurer que vos demandes de mémoire passent par malloc() ou utilisent l'opérateur new pour allouer correctement la mémoire avant de l'utiliser. Si vous ne procédez pas ainsi, vous vous trouverez dans une situation telle que vous essayerez d'utiliser de la mémoire qui ne vous est pas allouée ce qui provoquera une violation d'accès.

Les périphériques sont livrés avec différentes configurations de mémoire disponible et intégrée à la première utilisation. Lorsque le niveau d'espace de stockage devient particulièrement bas, il arrive que les applications qui écrivent des données et les nouvelles installations échouent. Si votre application est concernée par l'une de ces conditions, veillez à vérifier la mémoire disponible et l'espace de stockage restant sur votre périphérique de test. Si votre application a d'importants besoins en mémoire, pensez à vérifier le niveau de mémoire disponible à l'installation et à conseiller aux utilisateurs de désinstaller les logiciels qu'ils n'utilisent pas.

Pour vérifier le niveau de mémoire et de stockage de votre périphérique Pocket PC, appuyez sur Démarrer, Paramètres, puis sur Mémoire.

Pour vérifier le niveau de mémoire et de stockage de votre périphérique Smartphone, appuyez sur Démarrer, Paramètres, puis sur À propos de.

Autre facteur supplémentaire pouvant avoir un impact sur la mémoire disponible pour les applications, l'espace mémoire « adressable ». Il s'agit du mappage mémoire logique dans lequel les processus, les composants exécutables et la mémoire allouée doivent contenir pour s'exécuter. Cet espace adressable peut être à l'origine d'un certain nombre de problèmes de mémoire dans la mesure où vous pouvez disposer d'un volume de mémoire disponible important mais avoir épuisé par ailleurs l'espace de mémoire adressable.

Le système d'exploitation Windows CE qui sous-tend le logiciel Windows Mobile partage également les zones de mémoire adressable lorsque vous chargez des DLL, de manière à répartir la mémoire entre les différents processus. Il est important de comprendre avant tout comment le système d'exploitation gère la mémoire. Ce sujet est traité dans l'article MSDN Windows CE .NET Advanced Memory Management Site en anglais.

Pourquoi la DLL COREDLL est-elle située à l'emplacement 0 sur les périphériques sur Windows Mobile 2003 ?

À partir de Windows Mobile 2003, coredll.dll a été déplacée de l'emplacement 1 à l'emplacement 0 pour améliorer la gestion de la mémoire avec le Compact Framework. Bien que l'emplacement 0 soit généralement une zone de lecture/écriture de la mémoire, coredll.dll est une DLL de type XIP (Execute In Place) qui ne nécessite donc pas d'être copiée dans la RAM pour être exécutée.

Il arrive parfois que Autorun.exe ne s'exécute pas comme prévu sur les périphériques contenant plusieurs cartes de stockage. Pourquoi ?

Windows Mobile dispose d'un mécanisme qui lance automatiquement un exécutable appelé « autorun.exe » lorsque ce dernier est placé sur une carte de stockage et dans un répertoire spécifique, nommé en fonction du type de processeurs (par exemple, – \storage card\2577\autorun.exe). Certains périphériques prennent en charge plusieurs cartes de stockage ou utilisent des cartes de stockage internes inamovibles pour configurer automatiquement le périphérique. Il arrive que Autorun.exe ne s'exécute pas comme prévu sur les périphériques dotés de plusieurs cartes de stockage contenant un fichier autorun.exe. Ce problème va être corrigé dans les prochaines versions de Windows Mobile.

Pourquoi mes bases de données CEDB ne fonctionnent-elles plus après ma migration sur Windows Mobile 2003 ?

Le format interne des bases de données a changé sur les Pocket PC et sur les Smartphone sur Windows Mobile 2003. Cette modification peut entraîner le blocage de certaines applications tierces ou l'affichage d'un message d'erreur lorsqu'elles tentent d'accéder aux données. Sont affectées les applications qui installent les bases de données à partir des fichiers et en même temps que le programme lui-même. Si vous disposez d'une application qui utilise CEDB qui fonctionnait sur Pocket PC ou sur Smartphone 2002 et qui ne fonctionne plus correctement sur un Pocket PC ou un Smartphone sur Windows Mobile 2003, sachez qu'il existe un assistant pour vous aider à faire migrer les bases de données. Cet outil servira également aux utilisateurs qui ont entré les données dans les applications d'une version antérieure de Pocket PC ou Smartphone et souhaitent faire migrer leurs données lors du passage à la version 2003.

Database Conversion Wizard Power Toy Site en anglais

Sécurité

Pourquoi m'est-il impossible d'utiliser RAPI sur mon Smartphone ?

L'utilisation des API RAPI facilite l'accès aux ressources du périphérique à partir d'un ordinateur de bureau. Le modèle de sécurité du Smartphone peut être configuré de manière à interdire ou à restreindre l'API RAPI. Smartphone applique une politique de sécurité RAPI (4097) qui peut être configurée pour autoriser entièrement l'utilisation de RAPI, l'interdire complètement ou autoriser son utilisation avec un rôle restreint (SECROLE_USER_AUTH). Si l'API RAPI est configurée pour être exécutée par un rôle restreint, vous ne pourrez pas accéder à certains types d'appels interdits, comme CeMountDBVol et CeRapiInvoke. Les périphériques Smartphone peuvent être configurés de manière à accepter tout type d'appels RAPI mais cette politique est définie par l'opérateur de mobiles ou le fabricant du périphérique lors de sa construction.

Est-il nécessaire que je signe les fichiers MUI ?

Les fichiers MUI ne nécessitaient pas de signature sur Smartphone 2002. Avec Smartphone 2003 et les prochaines versions, les fichiers MUI doivent être signés tout comme d'autres fichiers binaires requis (EXE, DLL et CAB).

Dans le cadre de notre politique de sécurité, nous avons commencé à signer tous les exécutables mais une fois que nous avons signé une application Pocket PC, elle ne fonctionne plus. Pour quelle raison ?

Contrairement à Smartphone, les plates-formes Pocket PC jusqu'à la version 2003 Deuxième Édition ne prenaient pas en charge la signature des exécutables. Si vous signez une application Pocket PC sur l'une de ces plates-formes, vous recevrez un message signalant que l'application est corrompue. La signature sera prise en charge dans les prochaines implémentations de la plate-forme.

Matériel

Quelles capacités de pavé directionnel dois-je utiliser pour mon application ?

Microsoft exige actuellement que les fabricants implémentent des pavés directionnels à 5 directions sur les périphériques Windows Mobile. Certains fabricants ont même étendu ces exigences de base et fournissent des pavés de commande évolués. De fait, les pavés directionnels à 8 directions ne sont plus si rares. Vous devez garder à l'esprit que même si les périphériques évolués offrent de plus grandes capacités pour les applications, ces mêmes capacités peuvent ne pas être prises en charge sur tous les périphériques du marché. Les applications doivent être conçues pour fonctionner correctement conformément aux spécifications matérielles de base afin d'offrir aux utilisateurs les meilleures conditions d'utilisation et une prise en charge du service la plus large possible.

Navigation et connectivité Internet

Pourquoi les envois HTTP de plus de 16 Ko échouent-ils sur Windows Mobile 2003 ?

Lorsque vous passez de la plate-forme Windows Mobile 2002 à la plate-forme Windows Mobile 2003, il est possible que les envois de plus de 16 Ko échouent. Après l'envoi de 16 Ko de données, il arrive que le délai d'attente de ces transactions expire ou que ces transactions renvoient une erreur. Pour résoudre ce problème, divisez les données en segments de moins de 16 Ko.

Pourquoi les pages Web ont-elles une apparence et un comportement différents sur les périphériques 2003 ?

Sur les périphériques Windows Mobile 2003, Microsoft Pocket Internet Explorer redimensionne automatiquement le contenu de la page Web pour améliorer l'affichage de la zone de navigation. Cette capacité de redimensionnement introduit donc un changement par rapport à la plate-forme 2002. Si vous avez optimisé votre contenu pour les périphériques mobiles et que vous souhaitez annuler le redimensionnement automatique, vous pouvez le faire en utilisant la méta-balise suivante pour le désactiver :

<meta name="MobileOptimized" content="240">

Mon code qui utilise les contrôles HTML n'affiche plus les images correctement. Pour quelle raison ?

Si vous utilisez le contrôle HTML et traitez les images manuellement, notez que ce comportement a changé dans la plate-forme 2003.

  • Avec Pocket PC 2002, le fichier sur lequel pointait la balise IMG SRC est transféré en l'état au gestionnaire de notification NM_INLINE_IMAGE. (Par exemple, « file://\\Mes Documents\\logo.bmp » est transmis dans son état courant et sans modification au gestionnaire WM_NOTIFY). Dans Pocket PC 2003, le contrôle modifie l'URL en « file:///Mes Documents/logo.bmp ». Si vous êtes habitué à gérer l'image dans votre application, la chaîne NM_HTMLVIEW::szTarget devrait être convertie de manière appropriée pour charger l'image.
  • Si vous utilisez MFC et que vous souhaitez personnaliser la gestion de l'image, vous deviez, avec Pocket PC 2002, renvoyer une valeur différente de zéro au gestionnaire NM_INLINE_IMAGE. La plate-forme 2002 ignore également la valeur du troisième paramètre de OnNotify. Avec la plate-forme 2003, vous devez définir le paramètre LRESULT de OnNotify sur une valeur différente de zéro pour indiquer au contrôle que vous avez vous-même géré l'événement. Notez que dans les deux plates-formes, vous devez envoyer DTM_SETIMAGE et recevoir une valeur différente de zéro de la part du gestionnaire de notification.

Que dois-je faire pour que mon Pocket PC gère correctement le « localhost » ?

Si vous avez des problèmes pour utiliser votre serveur HTTP Pocket PC ou pour vous connecter à l'hôte local à l'aide d'un périphérique sur Windows Mobile 2003, il est possible que vous deviez apporter la modification suivante sur votre périphérique :

  1. Créez un fichier appelé _setup.xml contenant les éléments suivants :
    <wap-provisioningdoc>
    <characteristic type="CM_Mappings">
     <characteristic type="536870911">
     <parm name="Pattern" value="*://localhost/*" />
     <parm name="Network" value="{e8e89f5a-d3bb-4c58-9b4e-
    08279d31044e}" /> </characteristic> </characteristic> <characteristic type="Registry"> <characteristic type="HKLM\Software\Microsoft\ConnMgr\Providers\{EF097F4C-
    DC4B-4c98-8FF6-AEF 805DC0E8E}\localhost-null"> <parm name="DestId" value="{e8e89f5a-d3bb-4c58-9b4e-08279d31044e}" datatype="string" /> <parm name="Type" value="0" datatype="integer" /> <parm name="Enable" value="1" datatype="integer" /> </characteristic> </characteristic> <characteristic type="CM_Mappings"> <characteristic type="536870911"> <parm name="Pattern" value="*://127.0.0.1/*" /> <parm name="Network" value="{e8e89f5a-d3bb-4c58-9b4e-
    08279d31044e}" /> </characteristic> </characteristic> <characteristic type="Registry"> <characteristic type="HKLM\Software\Microsoft\ConnMgr\Providers\{EF097F4C-DC4B-
    4c98-8FF6-AEF805DC0E8E}\localhost-null"> <parm name="DestId" value="{e8e89f5a-d3bb-4c58-9b4e-
    08279d31044e}" datatype="string" /> <parm name="Type" value="0" datatype="integer" /> <parm name="Enable" value="1" datatype="integer" /> </characteristic> </characteristic> </wap-provisioningdoc>
  2. Créez un fichier de mise à disponibilité au format CAB  Site en anglais comme indiqué dans MSDN.
  3. Placez le fichier CPF sur votre périphérique et activez-le dans l'Explorateur de fichiers. Le programme d'installation CAB va le traiter et supprimer le fichier. Il n'y a aucun retour visuel d'informations à ce stade. Vous devez être capable d'utiliser http://localhost pour accéder au serveur Web local sans connexion réseau.

Pourquoi reçois-je des erreurs de type 12029, 12031 et 12007 lorsque j'établis ma connexion en utilisant InternetOpen avec INTERNET_OPEN_TYPE_PRECONFIG ?

Lorsque vous utilisez INTERNET_OPEN_TYPE_PRECONFIG, InternetOpen tente de se conformer aux informations de proxy configurées sur le périphérique, quelles qu'elles soient. La plupart des Smartphone sont configurés pour acheminer les proxys spécifiques d'un opérateur qui peuvent avoir un impact sur certains types de communication réseau. INTERNET_OPEN_TYPE_PRECONFIG extrait du registre les informations de ce proxy qui peuvent être modifiées par la configuration de Pocket Internet Explorer. Un moyen rapide de vérifier si vous avez affaire à un problème de proxy est d'effectuer un essai avec INTERNET_OPEN_TYPE_DIRECT, d'utiliser INTERNET_OPEN_TYPE_PROXY et de transmettre les informations de proxy directement à InternetOpen.

Mon code Javascript ne fonctionne plus. Qu'est-ce qui a changé ?

Lors du référencement d'objets dans Javascript avec Windows Mobile 2003, vous serez amené à utiliser une référence d'objet qualifiée complète. Si, par exemple, vous aviez un bouton dans une balise HTML <FORM> sous Pocket PC 2002, vous pouviez accéder au bouton <OBJECT> via l'attribut ID, n'importe où dans le script. Avec Pocket PC 2003, l'attribut doit être entièrement qualifié avec window.form_name.object_id.ButtonGo.Disabled = 1, par exemple :

Window.form1.ButtonGo.Disabled = 1

Je ne parviens pas à charger un document XML dans Javascript sur Windows Mobile 2003.

Si vous utilisez Microsoft.XMLDOM pour charger un fichier local XML dans Javascript, vous obtiendrez une erreur de type « Accès refusé » sur Windows Mobile 2003 alors que cette méthode fonctionne sur la plate-forme 2002. Cette nouvelle erreur est due aux modifications de sécurité apportées à la plate-forme 2003. Pour contourner ce problème, vous pouvez charger les données par le biais d'un objet ActiveX® que vous pouvez créer dans Javascript.

Pourquoi mes URL ne fonctionnent-elles pas correctement sur les périphériques 2003 ?

Il est possible que Pocket Internet Explorer ne code pas correctement les données POST/GET qui contiennent certaines entités de caractère HTML. Toute URL contenant &or &lang ou &, par exemple, ne sera pas convertie correctement. Vous trouverez une liste des entités concernées à l'adresse http://www.w3.org/TR/html401/sgml/entities.html Site en anglais. Ce problème concerne uniquement les périphériques sur plate-forme 2003 et sera corrigé dans les prochaines mises à jour de la plate-forme.

Affichage

Comment gérer les périphériques qui prennent en charge les résolutions élevées, la rotation et le format paysage ?

Le logiciel Windows Mobile 2003 Deuxième Édition introduit de nouvelles capacités d'affichage dans la plate-forme Windows Mobile. Si vous avez émis des hypothèses sur la résolution de l'écran et l'orientation, il peut s'avérer nécessaire de vérifier que vos applications fonctionnent sur tous les périphériques sur Windows Mobile 2003 Deuxième Édition. La première étape consiste à tester vos applications afin de vous assurer qu'elles fonctionnent comme prévu sur des périphériques haute résolution en modes paysage ou carré.

Vous rencontrerez également un nouvel avertissement lorsque vous installerez une ancienne application sur des périphériques Windows Mobile 2003 Deuxième Édition. Vous trouverez les informations sur ces nouvelles capacités ainsi que des instructions sur la façon de créer le package de votre application pour cette plate-forme dans le kit developer resources package for Windows Mobile 2003 Second Edition software Site en anglais.

Pourquoi les images de la barre d'outils semblent-elles disparaître de mon application sur Windows Mobile 2003 Deuxième Édition ?

Le problème des images de la barre d'outils qui semblent disparaître est dû à un changement de comportement dans Windows Mobile 2003 Deuxième Édition. Ce changement peut provoquer la suppression des images lorsque la barre d'outils est retirée du formulaire. Cette disparition d'images de la barre d'outils peut également se produire suite à un changement des propriétés MinimizeBox, WindowState ou FormBorderStyle du formulaire, ces modifications pouvant occasionner la recréation du formulaire au niveau natif, ce qui entraîne alors la suppression de la barre d'outils du formulaire.

Pour contourner ce problème, définissez la propriété ImageList de la barre d'outils après avoir effectué les opérations mentionnées ci-dessus.

En mode paysage sous Windows Mobile 2003 Deuxième Édition, toutes mes boîtes de dialogue ont des barres de défilement même si elles ne comportent aucune commande sous le bas de l'écran. Pour quelle raison ?

Les barres de défilement apparaissent même si les boîtes de dialogue ne comportent pas de contrôle placé au bas de l'écran, en raison d'un changement de comportement sous Windows Mobile 2003 Deuxième Édition qui a pour effet de faire apparaître des barres de défilement inutiles. Comme la fonction de barre de défilement automatique ne fonctionne pas si la boîte de dialogue comporte un contrôle onglet, le problème d'affichage des barres de défilement peut être résolu en créant un contrôle onglet (classe SysTabControl32), en le plaçant dans une zone hors de l'écran (en lui attribuant des coordonnées négatives) et en désactivant sa propriété WS_VISIBLE. Cette solution garantit qu'aucune barre de défilement verticale ne sera introduite automatiquement lorsque le périphérique basculera en mode paysage.

Est-ce que je dois utiliser GETRAWFRAMEBUFFER, GAPI ou GDI ? Qu’en est-il de DirectX ?

Les développeurs demandent souvent quelle approche envisager pour développer des graphiques et des jeux sur des plates-formes Windows Mobile pour prendre en charge le plus grand nombre de capacités d'affichage et tirer parti des interfaces les plus efficaces à leur disposition. Les capacités peuvent varier d'un périphérique à l'autre. Microsoft DirectX® sera disponible dans les prochaines versions de la plate-forme Windows Mobile afin de fournir une interface familière aux développeurs de jeux pour cibler les périphériques sur Windows Mobile. Une solution efficace pour les applications nécessitant un accès vidéo rapide consiste à demander ExtEscape pour GETRAWFRAMEBUFFER, puis à revenir sur GAPI et enfin sur GDI respectivement.

GETRAWFRAMEBUFFER est généralement implémentée sur les périphériques à écran haute résolution et à tampon de trame adressable de manière linéaire. Si vous obtenez une erreur lorsque vous demandez cet ExtEscape, cela signifie que votre périphérique n'a pas d'écran haute résolution adressable de manière linéaire. GAPI fournit en général une prise en charge plus vaste pour les développeurs de jeux d'un périphérique à l'autre ainsi que la compatibilité ascendante pour les applications existantes. GDI fait partie du cœur du système d'exploitation et masque les détails du matériel à l'utilisateur. Il fournit souvent une très bonne prise en charge pour les applications graphiques.

Audio

Pourquoi mon flux audio est-il légèrement « houleux » ?

Il peut arriver que la sortie de votre routine audio se révèle « légèrement houleuse » sur certains périphériques Pocket PC et Smartphone 2003. Ceci se produit généralement lorsque l'utilisation de l'UC avoisine les 100 %, avec un taux binaire élevé. Ce problème se produit généralement en raison des courts délais des demandes de rappel de la part du système d'exploitation ou du pilote audio intégré dans certains périphériques sur Windows Mobile 2003.

Dans le domaine du développement des jeux, il n'est pas rare de créer un thread distinct pour gérer les requêtes du pilote audio relatives à des données audio supplémentaires. Cette approche peut toutefois contribuer à créer ce délai à l'origine du problème. Pour résoudre ce problème, vous pouvez intégrer vos routines audio dans votre thread principal (celui qui avoisine les 100 % d'utilisation de l'UC). Vous pouvez, en outre, inclure un Sleep(0) dans la boucle principale afin d'améliorer le temps de latence des rappels.

Si les problèmes persistent lorsque votre jeu charge des graphiques ou exécute une action qui prend plus de temps qu'il n'en faut pour lire les tampons audio en attente, nous vous conseillons de déplacer le chargement graphique en aval dans l'exécution du programme afin d'éviter le chargement pendant l'exécution du son.

Pourquoi mon enregistrement est-il vierge ?

L'enregistrement de sons sur certains périphériques Smartphone 2002 peut être retardé ou interrompu pendant les périodes d'activité du réseau UDP. Vous pouvez constater ce problème si vous commencez à enregistrer à l'aide d'une application qui se base sur le flux du trafic UDP puis interrompt l'enregistrement. La période d'activité du réseau UDP peut entraîner un flux d'enregistrement vierge. Ce flux vierge est dû à un problème de pilote sur certains périphériques.

Environnements de compilation et de développement

Pourquoi mon code se comporte-t-il différemment après la compilation avec eMbedded Visual C++ 4.0 ?

La façon dont certaines optimisations de code étaient réalisées a changé dans Microsoft eMbedded Visual C++® 4.0. Si vous constatez des différences de comportement dans des zones hautement optimisées de votre code, essayez de désactiver temporairement ces optimisations pour déterminer si les modifications du compilateur peuvent jouer un rôle. Pour désactiver les optimisations, il vous suffit d'ouvrir Projet, de choisir Paramètres, puis de désactiver les optimisations dans l'onglet C++. Si vous faites migrer des projets de eMbedded Visual C++ 3.0 à eMbedded Visual C++ 4.0, veillez à lire au préalable l'article MSDN, Migrating to the eVC 4.0 Environment Site en anglais.

Qu'est-ce qui a changé dans les contrôles ActiveX ?

À partir de la version Window Mobile 2003, dans les nouveaux contrôles ActiveX, le modèle de thread du composant doit être déclaré comme Free ou both au moment de l'enregistrement. Dans les versions antérieures de Windows Mobile, le système ignorait ce paramètre d'enregistrement qui est désormais nécessaire.

Pourquoi les applications qui utilisent eMbedded Visual Basic ou ADOCE échouent-elles sur les périphériques équipés de Windows Mobile 2003 ?

Sur les périphériques sur Windows Mobile 2003, ADOCE et le runtime Microsoft eMbedded Visual Basic® ne sont plus inclus dans la ROM. Ils peuvent être installés, ou téléchargés et installés manuellement. Veuillez noter que le développement de code en eMbedded Visual Basic n'est plus pris en charge sur la plate-forme 2003 et est proposé uniquement pour permettre aux clients d'exécuter des applications des Pocket PC 2002 non modifiées.

Téléchargez eMbedded Visual Basic Runtime for Pocket PC 2003 Site en anglais.

Qu'est-il arrivé à imgdecmp.dll ? Comment faire pour programmer le chargement direct de formats communs d'images ?

Les périphériques sur Windows Mobile comportaient généralement une bibliothèque ROM appelée imgdecmp.dll qui servait aux applications Microsoft. La bibliothèque exportait une API qui n'était pas documentée dans le SDK mais qui était néanmoins utilisée par les développeurs pour charger des fichiers d'image. À partir de Windows Mobile 2003 Deuxième Édition, cette bibliothèque a été supprimée et les nouvelles API shell, SHLoadImageFile et SHLoadImageResource, ont été intégrées dans les en-têtes de aygshell.h. Ces API peuvent être utilisées à la place de la prise en charge d'image qu'assurait imgdecmp.dll.

Remarque    Imgdecmp.dll va être supprimée de la future version de la plate-forme Windows Mobile.

Pourquoi m'est-il impossible de rechercher (de répertorier) les périphériques Bluetooth à l'aide de WSALookupService/WSALookupServiceNext ?

Les fabricants de périphériques ont la possibilité de charger un choix de piles Bluetooth sur leurs périphériques Windows Mobile. À partir de Windows Mobile 2003, Microsoft fournit une pile Bluetooth compatible avec vos API Bluetooth et socket. Si un fabricant choisit d'utiliser une autre pile Bluetooth, il vous faudra certainement utiliser le SDK ou le jeu d'API que propose ce fournisseur tiers. Ainsi, la plupart des produits iPaq utilisent, par exemple, une pile Widcomm Bluetooth. Widcomm fournit aux développeurs son propre SDK pour développer les applications Bluetooth sur ces périphériques.

Nous contacter

Aidez-nous à faciliter la migration entre les différentes plates-formes Windows Mobile.

Si vous rencontrez des incohérences de développement sur les plates-formes Windows Mobile ou si vous développez du code personnalisé pour contourner un problème spécifique d'un périphérique, n'hésitez pas à nous le faire savoir en écrivant à wmdevmig@microsoft.com.



Dernière mise à jour le vendredi 29 octobre 2004



Afficher:
© 2014 Microsoft. Tous droits réservés.