But in some computers this feature can be turned off for some specific drive types. There is a value with the name NoDriveTypeAutoRun at the following two registry subkeys that can be changed to enable or disable AutoRun for different drives: Current User:.
Disk that can be removed from the drive such as a floppy disk or USB flash drive. Disk that cannot be removed from drive usually a hard disk. Windows cannot read the content of such devices. It is also possible that such a device does not support the concept of content. Because of these factors, registration of apps for non-volume Autoplay devices is done on a per-device basis rather than a content-type basis.
When one of these devices is connected to the machine, Windows checks to see if an application has been registered for the device. If the user has not yet specified a preference, he is prompted to choose one of the registered Autoplay handlers see Figure 4. If the user has already picked a preferred application for the event, that application is automatically launched by Windows.
Figure 4Non-volume Autoplay Event Prompt Once a default application has been selected, that preference can be changed by clicking a small icon that appears in the taskbar notification area when the device is connected see Figure 5.
This approach is different from the way preferences are changed for volume-based devices. The difference is necessary as many non-volume-based devices do not appear in the My Computer folder. Thus, there is no place to host the Autoplay property page. Figure 5Icon Autoplay V2 Registration Mechanism Both volume and non-volume Autoplay now support a new registration mechanism for applications interested in responding to media Autoplay events.
With this new mechanism, multiple applications may be registered concurrently for events related to the same content type. This concurrent registration provides a more event-related experience for the user. Autoplay settings are stored in the registry. All settings are rooted on the following key:. Applications register handlers to handle Autoplay events associated with particular media types. Information required of volume and non-volume handlers is described in Figure 6 and Figure 7 , respectively.
Figure 8 shows how the information is reflected in the user interface. Figure 8Handler Values UI Handlers contain the information necessary to launch the associated application along with information used in representing that handler in the Autoplay user interface.
A handler does not necessarily have a one-to-one relationship with an application. In response to an Autoplay event, the handler wraps the application with information specific to the event. For example, assuming that an application registers for both music and video events, it would register two handlers.
The first would handle music and its action text would be something like "Play music. If the application registered for IDropTarget new to Windows XP , then all the files that were sniffed will be passed to the application through the IDataObject interface.
The buffer returned contains the Item ID lists for all files enumerated in the first four levels of folders on the volume. No files are filtered out. The purpose of the buffer is to avoid a second enumeration by the handler. A handler implementation is responsible for filtering out the files that it cannot handle. Figure 9 shows a code extract from Sample 1 that performs the enumeration of the sniffed files. When a non-volume device generates an event for which an Autoplay handler is registered, Autoplay creates an instance of the component registered through the Autoplay handler.
If the executable implementing this component is not already running, the COM infrastructure will launch the application. Among the first things that the launched application should do is register its local server factories with COM. Figure 10 shows edited code from the Sample 2 project that demonstrates how this can be done.
This is done so that subsequent Autoplay events will be handled by the already running executable. Although not mandatory, it is recommended in most cases to avoid launching multiple instances of the same application.
The second parameter is presently reserved and will be either NULL or the address of a zero-length string; it should be ignored. Future versions of Windows might introduce new Event Type values. Since the non-volume handlers are invoked from the Shell Hardware Detection service, additional COM registration must be performed with regard to security.
The component as well as the application to be invoked must each have an AppID value. Without these settings the COM component creation will fail since services do not run in an interactive session. The relevant settings shown here are extracted from Sample2. Autoplay V2 EventHandlers Autoplay V2 determines which handlers should be invoked in response to an Autoplay event using another entity, the EventHandler.
EventHandlers associate events to handlers, hence the name. They provide a level of indirection enabling the reuse of handlers for many events. For a handler to be shown in the Autoplay prompt or to be invoked in response to a specific Autoplay event, it needs to be registered under the proper EventHandler.
Volume-based events use predefined EventHandlers see Figure Non-volume-based events use EventHandlers defined by the implementers of the handler. Other applications that want to handle these events can register their handlers under this EventHandler.
When an application defines an EventHandler, the handler should be given a meaningful name describing the device or device type it applies to as well as the event it is meant to handle.
For non-volume devices, an additional registration step may be required. Non-volume devices need to associate their EventHandlers with the device and event they want to handle.
This is done through a DeviceHandler. Autoplay uses DeviceHandlers to associate a device's events with an EventHandler. Here you can see the resulting structure in the registry:. Both of these values are provided either by the device at installation or by an application that wants to handle the events of a particular device or device type. Autoplay determines which DeviceHandler matches which device using a new feature of Windows XP that enables the association of miscellaneous properties to a device's PnP ID.
This is also the mechanism used by Windows XP to display a custom icon and label for volume devices in the My Computer folder and in other parts of the Windows UI.
This topic is outside of the scope of this article, but you can refer to the Platform SDK documentation for more information on how to do this.
Canceling Autoplay To provide a better user experience, it may be necessary in some cases to prevent Windows from triggering Autoplay for a particular media type or device. For example, assume a user is listening to music files on his hard disk using some application.
He then inserts an audio CD. In such a case, interrupting the music that's currently playing is probably not what the user expects. For non-volume devices, let's assume that the user has indicated through the user interface that Application A is to handle video camera events.
But for some reason the user prefers Application B for video editing. He opens Application B and begins editing some previously acquired video, then decides to add some newly acquired content to the video being edited.
He invokes Application B's import function and is prompted to turn on the video camera to acquire the latest video content from the camera. Usually this would trigger the launch of Application A, the user's preferred application for video camera events.
Fortunately, Application B has cancelled Autoplay processing of video camera events while the user is editing video content. In this case, the cancellation of Autoplay processing by Application B has created a better user experience.
The purpose of Autoplay is not to provide a reaction to every single hardware event, but rather to help the user accomplish specific tasks related to hardware events of interest. When the software reaction would be disruptive to the current flow of work, or just plain annoying, Autoplay cancellation can be invoked.
Volume and non-volume Autoplay are cancelled in different ways. Furthermore, volume events can be cancelled using one of two methods depending on whether the application is in the foreground. Each one of these cases is explained next. Volume Autoplay Cancellation Since its first incarnation, Autoplay always provided a cancellation mechanism.
If the application wants to cancel Autoplay only when it's in the foreground, the application can listen to the QueryCancelAutoplay message. The component will be called whenever an event generates an Autoplay action.
To do this you can click the start button then run and type gpedit. This is the group policy editor interface. Still on the right pane, double click system again, 1. Scroll down and locate "Turn off Autoplay. Once found, double click it.
After doublNow that you have opened the Turn off Autoplay interface, you will find out that the default setting is Not configured. So lets configure it. Click on the "Enabled" radio button. Clicking this will enable turn off autoplay, or in simpler terms, autoplay is turned off. This is a great Instructable, but you need to add a main image of the final project to the intro step.
0コメント