Algorytm routingu poleceń

W programie Visual Studio polecenia obsługiwane są przez wiele różnych składników. Polecenia są kierowane z najbardziej wewnętrznego kontekstu, który jest oparty na bieżącym zaznaczeniu, do najbardziej zewnętrznego (znanego również jako globalny) kontekstu. Aby uzyskać więcej informacji, zobacz Dostępność poleceń.

Kolejność rozpoznawania poleceń

Polecenia są przekazywane przez następujące poziomy kontekstu polecenia:

1. Dodatki: środowisko najpierw oferuje polecenie dowolnym dodatkom, które są obecne.

2. Polecenia priorytetu: te polecenia są rejestrowane przy użyciu polecenia IVsRegisterPriorityCommandTarget. Są one wywoływane dla każdego polecenia w programie Visual Studio i są wywoływane w kolejności, w której zostały zarejestrowane.

3. Polecenia menu kontekstowego: polecenie znajdujące się w menu kontekstowym jest najpierw oferowane do docelowego polecenia, które jest udostępniane w menu kontekstowym, a następnie do typowego routingu.

4. Cele poleceń zestawu narzędzi: te obiekty docelowe poleceń są rejestrowane podczas wywoływania polecenia SetupToolbar2. Parametr pCmdTarget może mieć wartość null. Jeśli nie jest to null, ten cel polecenia jest używany do aktualizowania poleceń znajdujących się na pasku narzędzi, który konfigurujesz. Jeśli powłoka konfiguruje pasek narzędzi, przekazuje ramkę okna jako pCmdTarget tak, aby wszystkie aktualizacje poleceń na pasku narzędzi przepływły przez ramkę okna, nawet jeśli nie znajduje się ona w fokusie.

5. Okno narzędzi: okna narzędzi, które zwykle implementują IVsWindowPane interfejs, powinny również implementować IOleCommandTarget interfejs, aby program Visual Studio mógł uzyskać element docelowy polecenia, gdy okno narzędzia jest aktywnym oknem. Jeśli jednak okno narzędzia, które ma fokus, jest oknem projektu , polecenie jest kierowane do interfejsu IVsUIHierarchy , który jest wspólnym elementem nadrzędnym wybranych elementów. Jeśli ten wybór obejmuje wiele projektów, polecenie jest kierowane do IVsSolution hierarchii. Interfejs IVsUIHierarchy zawiera metody QueryStatusCommand i ExecCommand, które są analogiczne do odpowiednich poleceń w interfejsie IOleCommandTarget.

6. Okno dokumentu: jeśli polecenie ma flagę RouteToDocs ustawioną w pliku .vsct, program Visual Studio szuka obiektu docelowego polecenia w obiekcie widoku dokumentu, który jest wystąpieniem interfejsu IVsWindowPane lub obiektu dokumentu (zazwyczaj interfejsu IVsTextLines lub interfejsu IVsTextBuffer). Jeśli obiekt widoku dokumentu nie obsługuje polecenia, program Visual Studio kieruje polecenie do zwróconego interfejsu IOleCommandTarget . (Jest to opcjonalny interfejs dla obiektów danych dokumentu).

7. Bieżąca hierarchia: Bieżąca hierarchia może być projektem, który jest właścicielem aktywnego okna dokumentu lub hierarchii wybranej w Eksploratorze rozwiązań. Program Visual Studio szuka interfejsu IOleCommandTarget zaimplementowanego w bieżącej lub aktywnej hierarchii. Hierarchia powinna obsługiwać polecenia, które są prawidłowe zawsze, gdy hierarchia jest aktywna, nawet jeśli okno dokumentu elementu projektu ma fokus. Jednak polecenia, które mają zastosowanie tylko wtedy, gdy Eksplorator rozwiązań ma fokus, muszą być obsługiwane za pomocą interfejsu IVsUIHierarchy i jego QueryStatusCommand metod i ExecCommand .

   Polecenia Cut, Copy, Paste, Delete, Rename, Enter i DoubleClick wymagają specjalnej obsługi. Aby uzyskać informacje o sposobie obsługi poleceń usuwania i usuwania w hierarchiach, zobacz IVsHierarchyDeleteHandler interfejs.

8. Globalny: jeśli polecenie nie zostało obsłużone przez wymienione wcześniej konteksty, program Visual Studio próbuje skierować go do pakietu VSPackage, które jest właścicielem polecenia implementujące IOleCommandTarget interfejs. Jeśli pakiet VSPackage nie został jeszcze załadowany, nie jest ładowany, gdy program Visual Studio wywołuje metodę QueryStatus . Pakiet VSPackage jest ładowany tylko wtedy, gdy metoda Exec jest wywoływana.

Treści powiązane

• Projektowanie polecenia