Udostępnij za pośrednictwem

Projektant zmienia się od platformy .NET Framework ( Formwindows s .NET)

  • Artykuł

Projektant wizualny dla systemu Windows Formdla platformy .NET miał pewne ulepszenia i zmiany od platformy .NET Framework. Te zmiany w dużej mierze wpływają na niestandardowych projektantów kontrolek. W tym artykule opisano kluczowe różnice między programem .NET Framework.

Visual Studio to aplikacja oparta na programie .NET Framework, a w związku z tym projektant wizualny widoczny dla systemu Windows Formjest również oparty na programie .NET Framework. W przypadku projektu .NET Framework zarówno środowisko Programu Visual Studio, jak i projektowana aplikacja systemu Windows Form, są uruchamiane w ramach tego samego procesu: devenv.exe. Stanowi to problem podczas pracy z aplikacją .NET systemu Windows Form(a nie .NET Framework). Kod .NET i .NET Framework nie może działać w ramach tego samego procesu. W związku z tym platforma .NET systemu Windows Formużywa innego projektanta , projektanta "poza procesem".

Projektant poza procesem

Projektant out-of-process jest procesem o nazwie DesignToolsServer.exe i jest uruchamiany wzdłuż procesu devenv.exe programu Visual Studio. Proces DesignToolsServer.exe jest uruchamiany na tej samej wersji i platformie .NET, na którą skonfigurowano aplikację docelową, na przykład .NET 7 i x64.

W projektancie programu Visual Studio obiekty serwera proxy programu .NET Framework są tworzone dla każdego składnika i kontrolki projektanta, które komunikują się z rzeczywistymi obiektami platformy .NET z projektu w projektancie DesignToolsServer.exe .

Projektanci kontrolek

W przypadku platformy .NET projektanci kontrolek muszą być kodowane za pomocą interfejsu API dostępnego Microsoft.WinForms.Designer.SDK w programie NuGet. Ta biblioteka jest refaktoryzowaniem projektantów programu .NET Framework dla platformy .NET. Wszystkie typy projektantów zostały przeniesione do różnych przestrzeni nazw, ale nazwy typów są w większości takie same. Aby zaktualizować projektantów programu .NET Framework dla platformy .NET, należy nieco dostosować przestrzenie nazw.

  • Klasy projektanta i inne powiązane typy, takie jak ControlDesigner i ComponentTray, zostały przeniesione z System.Windows.Forms.Design przestrzeni nazw do Microsoft.DotNet.DesignTools.Designers przestrzeni nazw.
  • Typy listy akcji w System.ComponentModel.Design przestrzeni nazw zostały przeniesione do Microsoft.DotNet.DesignTools.Designers.Actions przestrzeni nazw.
  • Typy związane z zachowaniem, takie jak adornery i linie przyciągania, w System.Windows.Forms.Design.Behavior przestrzeni nazw zostały przeniesione do Microsoft.DotNet.DesignTools.Designers.Behaviors przestrzeni nazw.

Edytory typów niestandardowych

Edytory typów niestandardowych są bardziej skomplikowane niż projektanci kontrolek. Ponieważ proces programu Visual Studio jest oparty na programie .NET Framework, każdy interfejs użytkownika wyświetlany w kontekście programu Visual Studio musi być również oparty na programie .NET Framework. Ten projekt stanowi na przykład problem podczas tworzenia kontrolki .NET, która wyświetla niestandardowy edytor typów wywoływany przez kliknięcie … przycisku w siatce właściwości. Nie można wyświetlić okna dialogowego w kontekście programu Visual Studio.

Projektant out-of-process obsługuje większość funkcji projektanta sterowania, takich jak adorners, wbudowane edytory typów i obraz niestandardowy. Za każdym razem, gdy musisz wyświetlić niestandardowe okno dialogowe modalne, takie jak wyświetlanie nowego edytora typów, należy replikować komunikację klient-serwer proxy, którą zapewnia projektant poza procesem. Spowoduje to o wiele większe obciążenie niż stary system .NET Framework.

Jeśli właściwości kontrolki niestandardowej używają edytorów typów udostępnianych przez system Windows Form, możesz użyć EditorAttribute polecenia , aby oznaczyć właściwości odpowiednim edytorem .NET Framework, który ma być używany przez program Visual Studio. Korzystając z wbudowanych edytorów, należy unikać konieczności replikowania komunikacji klient-serwer-proxy dostarczonej przez projektanta poza procesem.

[Editor("System.Windows.Forms.Design.FileNameEditor, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
        "System.Drawing.Design.UITypeEditor, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
public string? Filename { get; set; }

<Editor("System.Windows.Forms.Design.FileNameEditor, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", "System.Drawing.Design.UITypeEditor, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")>
Public Property Filename As String

Tworzenie edytora typów

Aby utworzyć projektantów niestandardowych, którzy udostępniają edytory typów, potrzebne będą różne projekty zgodnie z opisem na poniższej liście:

  • Control: Ten projekt to niestandardowa biblioteka kontrolek zawierająca kod kontrolek. Jest to biblioteka, do której użytkownik odwołuje się, gdy chce używać kontrolek.
  • Control.Client: System Windows Forms dla projektu .NET Framework, który zawiera okna dialogowe interfejsu użytkownika projektanta niestandardowego.
  • Control.Server: System Windows Forms dla projektu platformy .NET, który zawiera kod projektanta niestandardowego dla kontrolek.
  • Control.Protocol: projekt platformy .NET Standard, który zawiera klasy komunikacji używane zarówno przez projekty, jak Control.Client i Control.Server .
  • Control.Package: projekt pakietu NuGet zawierający wszystkie inne projekty. Ten pakiet jest sformatowany w sposób umożliwiający host narzędzi programu Visual Studio dla platformy .NET dla systemu Windows Formoraz korzystanie z biblioteki kontrolek i projektantów.

Nawet jeśli edytor typów pochodzi z istniejącego edytora, takiego jak ColorEditor lub FileNameEditor, nadal musisz utworzyć komunikację typu klient-serwer proxy, ponieważ podano nowy typ klasy interfejsu użytkownika, który ma być wyświetlany w kontekście programu Visual Studio. Jednak kod implementujący ten edytor typów w programie Visual Studio jest znacznie prostszy.

Ważne

Dokumentacja, która szczegółowo opisuje ten scenariusz, jest w toku. Do czasu opublikowania tej dokumentacji skorzystaj z następującego wpisu w blogu i przykładu, aby poprowadzić Cię do tworzenia, publikowania i używania tej struktury projektu: