Configuration automatique pendant l’installation de l’appareil

La figure suivante montre le flux de données dans la configuration automatique lors de l’installation d’un appareil.

1. Lorsqu’une imprimante est installée, le spouleur initialise le pilote en appelant DrvPrinterEvent et en passant PRINTER_EVENT_INITIALIZE dans l’appel.

2. Le pilote utilise des interfaces de communication bidi pour obtenir les données qui lui intéressent, y compris les valeurs des options installables telles que \Printer.Configuration.DuplexUnit:Installed et \Printer.Configuration.HardDisk:Installed.

3. L’interface de communication bidi interroge le moniteur de port pour connaître les valeurs de ces attributs. Le moniteur de port peut contenir certaines des données demandées dans son cache. À titre d’illustration dans les étapes suivantes, supposons que la valeur de \Printer.Configuration.HardDisk:Installed se trouve dans le cache du moniteur de port, mais que la valeur de \Printer.Configuration.DuplexUnit:Installed n’est pas.

4. Si le moniteur de port dispose d’un cache et qu’il a enregistré une ou plusieurs des valeurs demandées, le moniteur de port retourne ces valeurs à l’interface de communication bidi. Pour toutes les valeurs qui ne se trouve pas dans son cache, le moniteur de port retourne ERROR_NO_DATA. Notez qu’une requête bidi peut échouer si le moniteur de port implémente un cache mais que le cache est vide. Pour éviter ce problème, le moniteur de port doit notifier l’interface de communication bidi lorsque son cache est rempli.

5. L’interface de communication bidi transmet les informations qu’elle reçoit du moniteur de port au pilote. Si l’appel de l’interface de communication bidi au moniteur de port entraîne un échec pour une raison quelconque, le pilote doit définir les valeurs par défaut pour ces attributs. Dès que le moniteur de port reçoit des informations sur les attributs demandés, il doit envoyer une notification contenant ces informations à l’interface de communication bidi.

   Le pilote met à jour le Registre avec la valeur de \Printer.Configuration.HardDisk:Installed (obtenue à partir du cache du moniteur de port) et la valeur par défaut pour \Printer.Configuration.DuplexUnit:Installed.

6. Le moniteur de port interroge l’appareil pour les deux valeurs, y compris la valeur mise en cache (\Printer.Configuration.HardDisk:Installed).

7. L’appareil envoie ses valeurs pour les attributs interrogés au moniteur de port. Pour tout attribut dont la valeur n’était pas déjà présente dans le cache ou dont la valeur diffère de celle du cache, le moniteur de port place la nouvelle valeur dans son cache.

8. Le moniteur de port envoie au spouleur une notification contenant toutes les valeurs qui ne se trouvaient pas dans le cache ou qui ont été modifiées. Dans cet exemple, le moniteur de port envoie une notification au spouleur concernant la nouvelle valeur de \Printer.Configuration.DuplexUnit:Installed. Notez que si la valeur mise en cache est identique à la nouvelle valeur reçue de l’appareil, le moniteur de port n’envoie pas de notification au spouleur.

9. Le spouleur répond à la notification du moniteur de port en appelant DrvPrinterEvent, en passant PRINTER_EVENT_CONFIGURATION_UPDATE en plus des informations sur toutes les valeurs modifiées dans l’appel. Cette action a deux objectifs : informer le pilote de la valeur de tout attribut dont la valeur a été placée dans le cache pour la première fois ou dont la valeur a été modifiée (\Printer.Configuration.DuplexUnit:Installed, dans cet exemple) ; pour mettre à jour le Registre. Pour chaque imprimante, le spouleur sérialise ses appels à DrvPrinterEvent, de sorte que le pilote n’ait pas besoin d’être thread-safe.

   Étant donné que les informations sur l’appareil sont stockées dans le Registre, le pilote peut satisfaire aux appels pour mettre à jour l’interface utilisateur ou les informations sur les fonctionnalités de l’appareil sans avoir à communiquer directement avec l’appareil physique. Le pilote peut être certain que les informations stockées dans le Registre sont correctes, car les notifications de modification déclenchent le pilote pour interroger l’appareil et mettre à jour l’état de configuration de l’appareil.

10. Le pilote met à jour l’interface utilisateur en fonction de la dernière configuration.

    Le pilote peut déterminer quand une modification s’est produite pendant l’installation de l’appareil, car le message de notification porte la valeur modifiée. Toutefois, si la notification est trop volumineuse pour être envoyée via le mécanisme de notification, la notification aura une ou plusieurs instances ReducedSchema, chacune d’elles indiquant qu’une caractéristique d’appareil a changé, mais sans aucun détail sur sa nouvelle valeur.