Delphi-PRAXiS - Avalon

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - Avalon (https://www.delphipraxis.net/52129-avalon.html)

Hallo,
ich habe heute morgen einen Artikel über Avalon gelesen. Dabei ist mir folgendes aufgefallen.

Unter dem .net Framework 1.1 sind unter C# die verwendeten Controls und deren übder den Objektinspektor zugewiesenen Werte in der Sourcedatei des Formulars gespeichert.

Jetz mit dem .net Framework 2.0 und Avalon werden die verwendeten Controls, deren Werte und sogar die Events in einer XAML Datei gespeichert. Der Code befindet sich in einer sog. Code Behind Datei.

Irgendwie erinnert mich das sehr stark an eine pas Datei mit der zugehörigen dfm Datei.
Liege ich da richtig?

Du hast da was verwechselt.

.Net 2.0 <> Avalon!

In .Net 2.0 kann C# endlich partial classes, also dass eine Klasse über beliebig viele Dateien verteilt werden kann.
Dadurch kann der Designer code (den es immer noch gibt ;) ) in einer anderen Datei untergebracht werden und müllt einem den eigenen Source code nicht zu. :)

Avalon ist ein *ganz* anderer Schuh. :)

Zitat:

Zitat von Robert_G

In .Net 2.0 kann C# endlich partial classes, also dass eine Klasse über beliebig viele Dateien verteilt werden kann.

Wobei ich da der Meinung bin, dass man das auch nur für den Designer nutzen sollte. Alles andere führt nur dazu, dass man seine Tassen/Klassen nicht mehr alle beisammen hat.

Normal schon...
Momentan arbeite ich an einem Automations modell. Da gibt es einige Klassen, die *einige* Methoden haben.
Da mir das zu unübersichtlich wird, habe ich einen Ordner mit dem Klassennamen in das Projekt gepackt und die Klasse etwas zerlegt. Ist bis jetzt schön übersichtlich. :)
Ist zwar Chrome und nicht C#, aber das Prinzip ist das gleiche. ;)

Zitat:

Zitat von Robert_G

Normal schon...

Bei Programmiersprachen, die keinen Interface-Teil haben, sind partial classes schon ein brauchbares Feature (ist mir vorhin gar nicht eingefallen). Da findet man sich im Code eben ohne sowas wie einen CodeExplorer nicht zurecht.

Zitat:

Zitat von jbg

Zitat:

Zitat von Robert_G

Normal schon...

Naja, du vergisst, dass es im VS einen ClasView gibt. Und dass man oben diese netten DropDowns für links klassen und rechts Member hat. ;)

Zitat:

Zitat von Robert_G

Naja, du vergisst, dass es im VS einen ClasView gibt.

Wieso vergessen? Ich habe nur eben den Delphi-Slang benutzt: CodeExplorer. :wink:

Zitat:

Zitat von Robert_G

Du hast da was verwechselt.

.Net 2.0 <> Avalon!

Ich habe das nicht verwechselt. Deshalb habe ichauch geschrieben net Framework 2.0 und Avalon.
In der aktuellen Ausgabe des dot.net Magazins steht ab Seite 26 das die GUI Elemente (also Desinger-Code oder Inhakt der dfm-Datei) in einer separaten Datei, die mit xaml endet gespeichert wird. Damit noch nicht genug der Verwandschaft. Die xaml Datei hat soger den gleichen Namen wie die Code-Behind Datei.

Beispiel: myapp.cs (Code Behind Datei)
myap.xaml.cs (XML Datei, die die GUI Elemente beschreibt)

Wenn das nicht stark nach pas und dfm riecht.

Zitat:

Zitat von Jens Schumann

Beispiel: myapp.cs (Code Behind Datei)
myap.xaml.cs (XML Datei, die die GUI Elemente beschreibt)

Wenn das nicht stark nach pas und dfm riecht.

Ist ja auch nicht verwunderlich, da M$ ja vor einigen Jahren den "Erfinder" von Delphi abgeworben hat. Und der ist jetzt für .Net & Co. zuständig.
BTW: Diese Trennung gab es IMHO auch schon in VB, wurde aber nicht auf die anderen MS-Sprachen übernommen, da der damalige "Feind" dies in seiner IDE perfekt adaptiert hatte. Inzwischen haben sich die Wogen jedoch geglättet...

Oh, da habe ich dich wohl falsch verstanden.
In 2.0 wird nämlich auch der Designer code von SWF in einer anderen Datei abgelegt.

Zu Avalon aka WPF:

XAML mit DFM zu vergleichen, ist ziemlich unpassend.
DFM als Resource war sozusagen der Weg des geringsten Widerstandes. Es ist einfacher Design infos in ein solches Format zu packen und zur Laufzeit daraus die GUI zu erzeugen.
XAML ist ein Markup, das während des Compilierens mit MsBuild in Code und Resource umgewandelt wird.
Dadurch muss man zur Laufzeit nicht das ganze Design als Resource entpacken sondern man hat hauptsächlich Code mit den Werten (TExte, Farben,...) im schnellen BAML Format als Resource.

kleines Beispiel:

XML-Code:

			<Window x:Class="AvalonApplication2.Window1"

        xmlns="http://schemas.microsoft.com/winfx/avalon/2005"

        xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"

        Text="AvalonApplication2">

   <Grid>

      <Grid.RowDefinitions>

         <RowDefinition/>

         <RowDefinition/>

      </Grid.RowDefinitions>

      <TextBlock Grid.Row="0"

                 Name="TestTextBlock"

                 FontSize="50"

                 TextAlignment="Center"

                 VerticalAlignment="Center">

         Hallo welt

      </TextBlock>

      <Button Grid.Row="1"

              Click="TestClick"

              Width ="100"

              Height="30">

         Klick mich

      </Button>

   </Grid>

</Window>

Dem TextBlock gab ich einen Namen. Im generierten Designer Code wird deshalb ein Feld in meiner Windows class angelegt, das derm TextBlock entspricht.
Der Button bekam nur einen Click handler und bekommt kein Feld.

Den click handler muss ich im Code anlegen und kann darin auf den TextBlock zugreifen:

Delphi-Quellcode:

			namespace AvalonApplication2;

interface

uses

  System.Windows;

type

  Window1 = public partial class(Window)

  private

    method TestClick(sender: Object; e: RoutedEventArgs);

  public

    constructor;

  end;

implementation

constructor Window1;

begin

  InitializeComponent();

end;

method Window1.TestClick(sender: Object; e: RoutedEventArgs); 

begin

   TestTextBlock.TextContent := 'was anderes';

end;

end.

Wie du im Screeen shot sehen kannst, habe ich hier ein Feld, obwohl ich das nur im Markup angegeben habe.
Mit MsBuild sind eine Haufen Dinge möglich um Code während des Kompilierens zu injezieren. :)