Groupbox/Radiobuttons initialisieren?

TobiBob

Grüße Leute!

Ich habe ein kleines Problem mit gruppierten Radiobuttons:

Normalerweise ist ja kein Radiobutton gecheckt beim start (habe ich jedenfalls wo gelesen), so ist es an anderen Stellen in diesem Programm, und so soll es an dieser auch sein. Beim Starten ist aber schon der erste ausgewählt. Wenn ich den nun in der _Load-routine auf .checked = false; setze, wird er dennnoch markiert angezeigt. Erst wenn ich den 2. Radio in der Reihe mit true initialisiere, ist der 1. nicht "an".

Woran liegt das? Hängt das mit der groupbox zusammen? Und was muss ich machen, damit beim starten wirklich keiner ausgewählt ist?

Habe schon ne Weile jetzt in den Hilfefunktionen und hier Suchfunktion betätigt, aber leider noch nichts gefunden. Ihr könnt mir bestimmt helfen

Danke im voraus,
tobi

EXDW

WPF oder Forms?

TobiBob

Forms.

hier ist noch der code aus der Initialisierungsroutine: vielleicht erklärt das ja was den Experten, ich selbst habe da leider noch nicht genug Erfahrung, um da etwas herauszulesen. Den fett-gedruckten code (ln 12) habe ich hinzugefügt - änder aber nichts...

[cpp]			// 
			// rbKostenart... Das heir ist der Radio, der beim Start 
			//         an ist, obwohl er nicht soll...
			this.rbKostenart.AutoSize = true;
			this.rbKostenart.Location = new System.Drawing.Point(10, 20);
			this.rbKostenart.Name = "rbKostenart";
			this.rbKostenart.Size = new System.Drawing.Size(70, 17);
			this.rbKostenart.TabIndex = 0;
			this.rbKostenart.TabStop = true;
			this.rbKostenart.Text = "Kostenart";
			this.rbKostenart.UseVisualStyleBackColor = true;
			[b]this.rbKostenart.Checked = false;[/b]
			this.rbKostenart.Click += new System.EventHandler(this.rbKostenart_Click);
			// 
			// rbKostenstelle
			// 
			this.rbKostenstelle.AutoSize = true;
			this.rbKostenstelle.Location = new System.Drawing.Point(10, 46);
			this.rbKostenstelle.Name = "rbKostenstelle";
			this.rbKostenstelle.Size = new System.Drawing.Size(82, 17);
			this.rbKostenstelle.TabIndex = 1;
			this.rbKostenstelle.TabStop = true;
			this.rbKostenstelle.Text = "Kostenstelle";
			this.rbKostenstelle.UseVisualStyleBackColor = true;
			// 
			// rbKostentraeger
			// 
			this.rbKostentraeger.AutoSize = true;
			this.rbKostentraeger.Location = new System.Drawing.Point(10, 73);
			this.rbKostentraeger.Name = "rbKostentraeger";
			this.rbKostentraeger.Size = new System.Drawing.Size(85, 17);
			this.rbKostentraeger.TabIndex = 2;
			this.rbKostentraeger.TabStop = true;
			this.rbKostentraeger.Text = "Kostenträger";
			this.rbKostentraeger.UseVisualStyleBackColor = true;
			// 
			// groupBox1
			// 
			this.groupBox1.CausesValidation = false;
			this.groupBox1.Controls.Add(this.rbKostentraeger);
			this.groupBox1.Controls.Add(this.rbKostenstelle);
			this.groupBox1.Controls.Add(this.rbKostenart);
			this.groupBox1.Location = new System.Drawing.Point(15, 12);
			this.groupBox1.Name = "groupBox1";
			this.groupBox1.Size = new System.Drawing.Size(214, 102);
			this.groupBox1.TabIndex = 4;
			this.groupBox1.TabStop = false;
			this.groupBox1.Text = "Erfassungsart:";[/cpp]

Edit:
Ich habe gerade die Lösung gefunden: man muss im event Activated den checked-Wert auf false setzten. Dann bleibt es auch in dem Zustand bei der ersten Anzeige.
also:

[cs]		private void Form1_Activated(object sender, EventArgs e)
		{
			this.radioButton.Checked = false;
		}
[/cs]

Das ist Gefrickel. Irgendwo hast Du ein Ckecked=true übersehen.

EXDW

µ schrieb:

Das ist Gefrickel. Irgendwo hast Du ein Ckecked=true übersehen.

So sieht Forms nunmal aus

TobiBob

µ schrieb:

Das ist Gefrickel. Irgendwo hast Du ein Ckecked=true übersehen.

Wie bist du dir da so sicht? Ich hab schon das Projekt mit dem Bezeichnernamen in der Suchfunktion durchsucht - nirgends wo was von Checked=true; ... und auch in den Eigenschaften ist Checked=false...
PS aber mir kommts auch so vor, dass das ne sehr behelfsmäßige Lösung ist.

@David: ist das sone typische Saceh mit Forms? Ich arbeite erst seid ca. 1 Woche damit

Dravere

David W schrieb:

µ schrieb:

Das ist Gefrickel. Irgendwo hast Du ein Ckecked=true übersehen.

So sieht Forms nunmal aus

Wenn man keine Ahnung hat ... kennst du doch, oder?
Der Code, den TobiBob hier kopiert hat, ist aus der InitializeComponent Methode. Das Zeug wird vom Designer automatisch generiert. Gibt es in WPF auch, ist genauso ein Gefrickel. Typisch automatisch generierter Code halt.

@TobiBob,
Nicht auf David W hören, wenn es um WinForms geht. Der ist ein fanatischer WPF Fanboy und lehnt alle anderen Denkweisen ab.

Dein Problem hat übrigens mit TabIndex = 0 zu tun. Als Lösung kannst du z.B. im Designer AutoCheck auf false und in deinem Konstruktor manuell AutoCheck wieder auf true setzen. Ist soweit mir bekannt ist die standard Methode.

Grüssli

EXDW

Dravere schrieb:

Der Code, den TobiBob hier kopiert hat, ist aus der InitializeComponent Methode. Das Zeug wird vom Designer automatisch generiert.

Weiß ich, und dieser sieht in Forms nun ein mal so aus. Meine Aussage ist nicht falsch.

Dravere schrieb:

Gibt es in WPF auch, ist genauso ein Gefrickel. Typisch automatisch generierter Code halt.

In WPF gibt es auch die InitializeComponent, natürlich, aber diese hat nicht solche Blöcke die alles in einer Methode definieren sondern ruft intern lediglich LoadComponent in der Application Klasse auf mit der Uri zur XAML Datei, diese XAML Datei wird dann durch den 'BamlParser' gejagt, und der baut rekursiv den Baum auf, es gibt keine lange Methode wo alles definiert ist, viel mehr definiert sich jedes Control selber.
InitializeComponent->Application.LoadComponent->XamlReader.LoadBaml->TreeBuilderBamlTranslator.Parse().
Es gibt wenn man es genau nimmt kein Generierten Code.

Dravere schrieb:

Nicht auf David W hören, wenn es um WinForms geht. Der ist ein fanatischer WPF Fanboy und lehnt alle anderen Denkweisen ab.

Ich lehne es nicht ab, es ist nur Unverständnis wie man neue Applikationen auf Forms aufsetzen kann, eine Verwaltete und nicht mehr weiter entwickelte Technik. Ich hatte mal eine Quelle wo belegt wurde das das letzte Update seitens Microsoft bei Forms 2003 war, und es fehlen schon Controls.
Viele Firmen die C# einsetzen wenden sich auch eher WPF zu als Forms, aus gutem Grund.

Zudem, was habe ich denn Böses gesagt? Ich habe nirgends Forms schlecht geredet in diesem Thread (Eventuell könnte man nun dieses Posting negativ bewerten). Ich habe lediglich bemerkt das der Designer Code in Forms tatsächlich so aus sieht, und das war nur eine Reaktion auf µs "Das ist Gefrickel".

Dravere

David W schrieb:

Zudem, was habe ich denn Böses gesagt? Ich habe nirgends Forms schlecht geredet in diesem Thread (Eventuell könnte man nun dieses Posting negativ bewerten). Ich habe lediglich bemerkt das der Designer Code in Forms tatsächlich so aus sieht, und das war nur eine Reaktion auf µs "Das ist Gefrickel".

Du hast nirgends gesagt, dass dies nur den Designer Code betrifft.
Die Aussage von μ war: "Das ist Gefrickel."
Deine Aussage dazu war: "So sieht Forms nunmal aus :D"
Was deine Aussage zu dem macht: "Forms ist nunmal Gefrickel."
Und seien wir mal ehrlich, genau so hast du es auch gedacht.

Und ich würde dir empfehlen diesen Blog-Eintrag zu lesen von Josh Smith, einer der WPF Disciples:
http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/

Josh Smith schrieb:

WPF is not intended to replace Windows Forms.

Für viele Dinge bin ich nachwievor froh, dass ich WinForms habe. Gerade auch die nähe zur WinAPI kann von grossem Vorteil sein. Und für kleine simple Tools/Applikationen ist WPF einfach nachwievor der reine Overkill.
Manchmal will man nunmal einfach nur eine Tabelle von Daten vor sich haben. Dazu braucht man kein WPF. Es gibt noch zahlreiche Anwendungsmöglichkeiten für WinForms. Es arbeiten auch nicht alle mit .Net auf einem Leistungsstarken PC. Oder es werden die Features von WPF einfach nicht benötigt und man arbeitet mit System.Drawing zusammen, siehe z.B. AForget.net. usw.

Ob ein Anfänger WinForms lernen soll oder nicht, darüber kann man von mir aus streiten. WinForms ist halt deutlich schneller und einfacher zu erlernen als WPF und kann von einem Anfänger einfacher verdaut werden. Und eine Auswahl von Werkzeugen schadet definitiv nicht. WPF sollte auf jedenfall auch noch gelernt werden.
Aber zu sagen, dass es keinen Sinn macht, mit WinForms eine neue Applikationen zu machen, halte ich für sehr kurzsichtig gedacht. Veraltet heisst nicht schlecht!

Grüssli

TobiBob

@Dravere, danke für deinen Hinweis, funktioniert optimal

Und das liebe ich so an guten Foren: bei ganz banalen Anfragen bekommt man immer viel an Hintergrundwissen mit, und zwar Dinge, die in keinem Tutorium oder Buch stehen! Ich werd mir später mal den ganzen Blog durchlesen, denn ich höre auch etwas konträre Dinge zu Forms vs WPF. Scheint ein sensibles Thema zu sein!

EXDW

Dravere schrieb:

Und seien wir mal ehrlich, genau so hast du es auch gedacht.

Woher willst du wissen was ich denke? Du glaubst mich besser zu kennen als du es tatsächlich machst

Dravere schrieb:

Und ich würde dir empfehlen diesen Blog-Eintrag zu lesen von Josh Smith, einer der WPF Disciples:
http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/

Josh Smith schrieb:

WPF is not intended to replace Windows Forms.

Dir ist schon klar das der Beitrag von 2007 ist und WPF da noch in den Kinderschuhen steckte? Die Zeiten haben sich geändert.
Neuere Diskusionen finde ich nicht, weil es schon längst geklärt ist das es kein Sinn macht in alten Sachen zu investieren.

Dravere schrieb:

Für viele Dinge bin ich nachwievor froh, dass ich WinForms habe.

Für bestehende Forms Applikation keine Frage.

Dravere schrieb:

Gerade auch die nähe zur WinAPI kann von grossem Vorteil sein.

Wo ist Forms näher an der WinApi? Auch in WPF kannst du dich Problemlos in die WndPrc Hooken Das sind Zweizeiler und du bist drinn, und das auch direkt in der entsprechenden Fensterklasse.

Dravere schrieb:

Und für kleine simple Tools/Applikationen ist WPF einfach nachwievor der reine Overkill.

App.xaml, App.xaml.cs, MainWindow.xaml, MainWindow.xaml.cs findest du als Minimalset Overkill? Das ist doch lächerlich.

Dravere schrieb:

Manchmal will man nunmal einfach nur eine Tabelle von Daten vor sich haben. Dazu braucht man kein WPF.

<Window>
    <DataGrid ItemsSource="{Binding MyTable}" />
</Window>

Fertig, im C# Code kannst du die Tabelle normal laden wie du es auch in Forms machen würdest. eine Datentabelle ist ein schlechtes Beispiel da Listen und Tabellen in WPF extrem einfach und schnell anzeigbar sind. Das macht dir jeder Anfänger innerhalb von ein paar Minuten.

Dravere schrieb:

Es gibt noch zahlreiche Anwendungsmöglichkeiten für WinForms. Es arbeiten auch nicht alle mit .Net auf einem Leistungsstarken PC. Oder es werden die Features von WPF einfach nicht benötigt und man arbeitet mit System.Drawing zusammen, siehe z.B. AForget.net. usw.

.Net hast du bei Forms auch, und WPF braucht nicht zwingend ein Leistungsstarken PC, wenn du eine Oberfläche aufbaust wie sie in Forms ist, ist es genauso Performant. Warum du ein Link zu einer Lib (oder?) aufführst ist mir schleierhaft, die gibts in jeder Technologie.
Ich zeige dir auch kein Lenkrad von Peugeot um zu zeigen das es besser ist als Skoda. Auch WPF hat Libraries

Dravere schrieb:

Ob ein Anfänger WinForms lernen soll oder nicht, darüber kann man von mir aus streiten. WinForms ist halt deutlich schneller und einfacher zu erlernen als WPF und kann von einem Anfänger einfacher verdaut werden.

Ein Anfänger lernt dann aber umsonst, denn die nachfrage sinkt kontinuierlich, und bei WPF müsste er dann so oder so von 0 anfangen da es einfach ganz anders geschrieben wird.
WPF halte ich einfacher für Anfänger, da es eine Sprache ist die Deutlicher aussagt was los is.

"Ich Möchte ein Button"

<Button></Button>

"Der Button soll ein Bild beinhalten

<Button>
    <Image></Image>
</Button>

"Über den Button soll es ein Text geben"

<TextBlock></TextBlock>

"Der Text soll lauten 'Klick den Button'"

<TextBlock>Klick den Button</TextBlock>

"Beide sollen, wie gesagt, übereinander sein, wie in einem Stack von oben nach unten"

<StackPanel>
    <TextBlock>Klick den Button</TextBlock>
    <Button>
        <Image></Image>
    </Button>
</StackPanel>

WPF kann extrem einfach sein und "Selbstsprechend" durch die Deklarative Syntax. Gerade für Anfänger ein Segen.
Ich war auch mal Anfänger, und hatte überlegt (Komme aus der c++ MFC Ecke) "Mach ich Forms oder WPF". Nachdem ich dann bei beiden Beispiele sah und rum probierte kam ich bei WPF deutlich schneller zu Ergebnissen die am Ende auch einfacher und besser waren.

Dravere schrieb:

Und eine Auswahl von Werkzeugen schadet definitiv nicht. WPF sollte auf jedenfall auch noch gelernt werden.

Warum dann den Umweg über Forms?

Dravere schrieb:

Aber zu sagen, dass es keinen Sinn macht, mit WinForms eine neue Applikationen zu machen, halte ich für sehr kurzsichtig gedacht. Veraltet heisst nicht schlecht!

Genauso wie du sagst das ich ein WPF Fanboy bin sag ich das du bisher vermutlich zu wenig in WPF gemacht hast um deren Vorteil zu erkennen. (PS. Ja ich bin ein WPF Fanboy, weil WPF ist einfach a. Einfacher; b. Flexibler ohne Komplizierter zu werden; c. Sehr sauber)

Nehmen wir einfach mal den Beispiel vom Eingangsposting.
Das wäre in WPF einfach

<Window>
    <GroupBox Header="Erfassungsart:">
        <StackPanel Orientation="Horizontal">
            <RadioButton Content="Kostenart" x:Name="rbKostenart" />
            <RadioButton Content="Kostenstelle" x:Name="rbKostenstelle" />
            <RadioButton Content="Kostentraeger" x:Name="rbKostentraeger" />
        </StackPanel>
    </GroupBox>
</Window>

Per default ist dann nichts ausgewählt, sobald eins ausgewählt sein soll dann einfach IsChecked="True" und fertig.
Jeder noch so blutige Anfänger wird das auf Anhieb erkennen. Und aus C# Code heraus kann er genauso auf die rb*** zugreifen. Und das ganze ohne Positions-, und Größengefummel.

//Edit, paar Blöde Typos entfernt.

Dravere

David W schrieb:

Woher willst du wissen was ich denke? Du glaubst mich besser zu kennen als du es tatsächlich machst

Ich lese auch in MyCSharp

David W schrieb:

Dir ist schon klar das der Beitrag von 2007 ist und WPF da noch in den Kinderschuhen steckte? Die Zeiten haben sich geändert.
Neuere Diskusionen finde ich nicht, weil es schon längst geklärt ist das es kein Sinn macht in alten Sachen zu investieren.

Nein, weil die Aussage von Josh nachwievor gültig ist. WPF hinkt in gewissen Dingen immer noch hinten nach. Schau dir nur mal gewisse fehlende Common Dialogs an, wo man heute noch auf die WinForms Dialoge zurückgreift!

Zudem ist die Frage immer noch dieselbe. Wieso sollte man bei so einer einfachen Applikation auf WPF zugreifen? Wozu diese neue Technologie einsetzen? In gewissen Bereichen hat sie einfach keinerlei Vorteil.

David W schrieb:

Dravere schrieb:

Für viele Dinge bin ich nachwievor froh, dass ich WinForms habe.

Für bestehende Forms Applikation keine Frage.

Nicht nur.

David W schrieb:

Dravere schrieb:

Gerade auch die nähe zur WinAPI kann von grossem Vorteil sein.

Wo ist Forms näher an der WinApi? Auch in WPF kannst du dich Problemlos in die WndPrc Hooken Das sind Zweizeiler und du bist drinn, und das auch direkt in der entsprechenden Fensterklasse.

Forms bildet direkt die WinAPI GUI ab. Eine WinForms ComboBox entspricht der WC_COMBOBOX aus der WinAPI. Es geht hier nicht um die WndPrc , sondern darum, dass WinForms die WinAPI GUI abbildet. WPF dagegen setzt auf DirectX und zeichnet seine Controls selber. Nur die Window Klasse entspricht der normalen Fensterklasse aus der WinAPI. Um gewisse Dinge dann in WPF reinzubekommen, muss man auf HwndHost oder dergleichen zurückgreifen. Im allgemeinen fand ich bisher diese Interoperabilität mit WPF eher sehr mühsam. WPF ist eine sehr abgeschottete Welt.

David W schrieb:

Dravere schrieb:

Und für kleine simple Tools/Applikationen ist WPF einfach nachwievor der reine Overkill.

App.xaml, App.xaml.cs, MainWindow.xaml, MainWindow.xaml.cs findest du als Minimalset Overkill? Das ist doch lächerlich.

Du misst die Grösse einer Applikation in der Menge von Files? Ich darf doch bitten ...

David W schrieb:

Dravere schrieb:

Manchmal will man nunmal einfach nur eine Tabelle von Daten vor sich haben. Dazu braucht man kein WPF.
<Window>
    <DataGrid ItemsSource="{Binding MyTable}" />
</Window>
Fertig, im C# Code kannst du die Tabelle normal laden wie du es auch in Forms machen würdest. eine Datentabelle ist ein schlechtes Beispiel da Listen und Tabellen in WPF extrem einfach und schnell anzeigbar sind. Das macht dir jeder Anfänger innerhalb von ein paar Minuten.

Klar ... als wenn es wirklich so einfach wäre. Von irgendwoher muss MyTable kommen. MyTable kann nur gewisse Formate unterstützen. Im allgemeinen muss man die Daten von MyTable aufbereiten. Man muss mindestens ein ViewModel einführen. DataContext setzen. usw. usf.
Du bist wie gewisse WPF Autoren. Die zeigen wie einfach doch alles ist und vergessen die Hälfte der Applikation oder passen alles so an, dass es jede grössere Schwierigkeit umschifft und damit ausblendet.

David W schrieb:

.Net hast du bei Forms auch, und WPF braucht nicht zwingend ein Leistungsstarken PC, wenn du eine Oberfläche aufbaust wie sie in Forms ist, ist es genauso Performant.

Dann zeig mir mal WPF im Compact Framework
Es gibt einfach Bereiche, da ist WPF (und auch Silverlight) nicht einsetzbar. Das meine ich mit dem Leistungsstarken PC. Ein Mikrokontroller mit Windows CE kann diese Stärke nicht erbringen. Daher auch meine Aussage, dass du kurzsichtig denkst. Du schaust dir nur deine Umgebung an und merkst nicht, dass .Net auch noch an ganz anderen Orten zum Einsatz kommt.

David W schrieb:

Warum du ein Link zu einer Lib (oder?) aufführst ist mir schleierhaft, die gibts in jeder Technologie.

Dann zeig mir eine Bildverarbeitungs- und Bilderkennungsbibliothek, welche für WPF geschrieben wurde. Denn genau dies ist AForge.Net. Damit wollte ich zeigen, dass es nachwievor Bereiche gibt, wo man eher auf WinForms setzt. Bildverarbeitung ist so ein Bereich.

David W schrieb:

Ein Anfänger lernt dann aber umsonst, denn die nachfrage sinkt kontinuierlich, und bei WPF müsste er dann so oder so von 0 anfangen da es einfach ganz anders geschrieben ist.

Man lernt nie etwas umsonst. Es bereichert einem an Ideen, welche man auch an anderen Orten einsetzen kann.

David W schrieb:

WPF halte ich einfacher für Anfänger, da es eine Sprache ist die Deutlicher aussagt was los is.
... XAML Zeug ...

Und in WinForms? Da nehme ich einen Button aus der Liste und setze ihn auf meine Form und ändere das Text Property. Wow ist das kompliziert. Können wir diese Kleinigkeiten lassen? Darin unterscheiden sich WPF und WinForms wirklich kaum.
Aber erklär mal einem Anfänger wie DependencyProperties funktionieren. Wann wo wieso welcher Wert genommen wird. Erklär einem Anfänger RoutedEvents (Tunneling, Bubbeling, Registrierung, usw.), Commands, Binding, usw.

Diese Konzepte sind zwar sehr toll an WPF, aber sie machen WPF auch deutlich komplizierter als WinForms.

David W schrieb:

WPF kann extrem einfach sein und "Selbstsprechend" durch die Deklarative Syntax. Gerade für Anfänger ein Segen.

Was du gezeigt hast, ist nur ein wenig XAML. WPF ist viel mehr!

David W schrieb:

Dravere schrieb:

Und eine Auswahl von Werkzeugen schadet definitiv nicht. WPF sollte auf jedenfall auch noch gelernt werden.

Warum dann den Umweg über Forms?

David W schrieb:

Dravere schrieb:

Aber zu sagen, dass es keinen Sinn macht, mit WinForms eine neue Applikationen zu machen, halte ich für sehr kurzsichtig gedacht. Veraltet heisst nicht schlecht!

Genauso wie du sagst das ich ein WPF Fanboy bin sag ich das du bisher vermutlich zu wenig in WPF gemacht hast um deren Vorteil zu erkennen.

Da täuschst du dich. Ich mache die Mehrheit meiner Anwendungen in WPF. Inzwischen ist bei mir auch mein Knoten bei WPF weg. Jetzt geht es sehr gut voran. Ganz ehrlich: Ich mag WPF! WPF ist toll! Ich ziehe WPF definitiv WinForms meistens vor! Aber es ist kein Allheilmittel.

Und ich habe einfach etwas gegen fanatische Prediger, welche nur die eine Technologie sehen und alle anderen aus ihrem Spektrum werfen und verbrennen. Das ist wie die Fanatiker, welche nur Windows, Linux oder Apple wollen und den Rest als Teufelswerk verbannen. Und sobald jemand irgendwo eine andere Technologie einsetzet, müssen sie dort schlecht darüber reden gehen, denn sie haben die Weisheit mit Löffeln gefressen und wissen, wo der Entwickler die Erlösung findet.
Es ist schön, wenn du mit WPF zufrieden bist! Ich mag WPF auch. Aber lass deine Sticheleien gegen WinForms. Das hat einfach keinen Zweck, schliesslich beherrscht du die WinForms nicht einmal.

Und hier ist für mich nun auch Schluss. Ich bin mir sicher, du wirst darauf nochmals antworten und alle Punkte "widerlegen" wollen, eröffne dazu aber bitte einen neuen Thread.

Und in Zukunft werde ich solche pauschale Aussagen entfernen, diese ganzen Diskussionen gehen nur ins Off-Topic und bringen nichts.

Grüssli

EXDW

Dravere schrieb:

David W schrieb:

Woher willst du wissen was ich denke? Du glaubst mich besser zu kennen als du es tatsächlich machst

Ich lese auch in MyCSharp

Was hat mycsharp mit mir zu tun? Da bin ich nicht mal aktiv.

Dravere schrieb:

Schau dir nur mal gewisse fehlende Common Dialogs an, wo man heute noch auf die WinForms Dialoge zurückgreift!

Nur der FontPicker, ColorPicker und BrowseFolder, aber da gibt’s auch 3rdParty.

Dravere schrieb:

Eine WinForms ComboBox entspricht der WC_COMBOBOX aus der WinAPI. Es geht hier nicht um die WndPrc , sondern darum, dass WinForms die WinAPI GUI abbildet. WPF dagegen setzt auf DirectX und zeichnet seine Controls selber. Nur die Window Klasse entspricht der normalen Fensterklasse aus der WinAPI. Um gewisse Dinge dann in WPF reinzubekommen, muss man auf HwndHost oder dergleichen zurückgreifen. Im allgemeinen fand ich bisher diese Interoperabilität mit WPF eher sehr mühsam. WPF ist eine sehr abgeschottete Welt.

Was willst du denn entsprechendes machen was die WinApi so erfordert das du keine Chance in WPF hast? Ich kenne keine Fälle, auch wenn ich rum frage oder recherchiere.

Dravere schrieb:

quote="David W"]

Dravere schrieb:

Und für kleine simple Tools/Applikationen ist WPF einfach nachwievor der reine Overkill.

App.xaml, App.xaml.cs, MainWindow.xaml, MainWindow.xaml.cs findest du als Minimalset Overkill? Das ist doch lächerlich.

Du misst die Grösse einer Applikation in der Menge von Files? Ich darf doch bitten ...[/quote]
Deine aussage Overkill bezieht sich auf? Die paar DLLs die benötigt werden? WPF läuft auch problemlos auf mein 2. PC mit einem Single Coce 1,1GHz und 1 GB RAM.
Woanders wo WPF unangemessen ist ist das ganze .NET fehl am platz, da müssen Native Sprachen wie C++ her.

Dravere schrieb:

Klar ... als wenn es wirklich so einfach wäre. Von irgendwoher muss MyTable kommen. MyTable kann nur gewisse Formate unterstützen.

Wo ist der unterschied zu Forms? Auch da musst du die Tabelle irgendwie laden, und genau wie du die Tabelle in Forms füllst kannst du es auch in WPF machen.

Dravere schrieb:

Im allgemeinen muss man die Daten von MyTable aufbereiten. Man muss mindestens ein ViewModel einführen. DataContext setzen. usw. usf.

Du bist wie gewisse WPF Autoren. Die zeigen wie einfach doch alles ist und vergessen die Hälfte der Applikation oder passen alles so an, dass es jede grössere Schwierigkeit umschifft und damit ausblendet.

Blödsinn. Wieso gleich die MVVM Keule schwingen? Gerade bei kleinen Applikationen löst man es ohne diesen da es mit diesem Pattern tatsächlich zuviel Arbeit wäre.
Was mir auch auf den Magen schlägt ist das viele WPF anhänger gleich mit MVVM ankommen. Aber das braucht man nur bei einer gewissen Größe, vorher kann man normale in der CodeBehind arbeiten, genau wie im Forms. Dadurch ist es auch für den anfänger sehr einfach.

Dravere schrieb:

Dann zeig mir eine Bildverarbeitungs- und Bilderkennungsbibliothek, welche für WPF geschrieben wurde. Denn genau dies ist AForge.Net. Damit wollte ich zeigen, dass es nachwievor Bereiche gibt, wo man eher auf WinForms setzt. Bildverarbeitung ist so ein Bereich.

Entwickeln wir im Haus, aber wir machen nur Kommerziell und setzen es selber ein, darf ich dir nicht geben. Kannst es aber später im Laden erwerben

Dravere schrieb:

Und in WinForms? Da nehme ich einen Button aus der Liste und setze ihn auf meine Form und ändere das Text Property. Wow ist das kompliziert. Können wir diese Kleinigkeiten lassen? Darin unterscheiden sich WPF und WinForms wirklich kaum.

Genau wie in WPF, mit dem vorteil das man bei WPF nach nach oben hin noch Luft hat.

Dravere schrieb:

Aber erklär mal einem Anfänger wie DependencyProperties funktionieren. Wann wo wieso welcher Wert genommen wird. Erklär einem Anfänger RoutedEvents (Tunneling, Bubbeling, Registrierung, usw.), Commands, Binding, usw.

Anfänger kommen damit nicht in Berührung. Schau mein Beispiel, dort habe ich die Namen gesetzt sodass er auf die Controls direkt in der CodeBehind zugreifen kann.

Dravere schrieb:

Diese Konzepte sind zwar sehr toll an WPF, aber sie machen WPF auch deutlich komplizierter als WinForms.

Nur wenn man es benutzt.

Dravere schrieb:

Was du gezeigt hast, ist nur ein wenig XAML. WPF ist viel mehr!

Irrelevant für den Anfänger.

Dravere schrieb:

Und hier ist für mich nun auch Schluss. Ich bin mir sicher, du wirst darauf nochmals antworten und alle Punkte "widerlegen" wollen, eröffne dazu aber bitte einen neuen Thread.

Und in Zukunft werde ich solche pauschale Aussagen entfernen, diese ganzen Diskussionen gehen nur ins Off-Topic und bringen nichts.

Dann bitte ich dich diese Beiträge ab zu Spalten, dann braucht man nicht alles nochmal eingeben.

Th69

David W: du meinst, bei myCharp bist du jetzt nicht mehr aktiv... (userid14268)
Das Internet vergißt nicht!

Dravere, ich stimme dir in allen Punkten vollkommen zu.

EXDW

Ich habe nie gesagt das ich dort nicht aktiv war, ich sagte das ich es nicht bin Lies genauer :p

//Dazu
Was glaubst du warum ich von mycsharp weg gegangen bin?

Firefighter

Ich kann mich noch gut erinnern wie du von mycsharp mal geschwärmt hast

Was glaubst du warum ich von mycsharp weg gegangen bin?

Warum bisse da weggegangen?

EXDW

Firefighter schrieb:

Ich kann mich noch gut erinnern wie du von mycsharp mal geschwärmt hast

Tja, Zeiten ändern sich, vor allem wenn die Erfahrung steigt.

sagbitte schrieb:

Warum bisse da weggegangen?

Warum das

weil ich dich dort vermisse

Firefighter

David W schrieb:

Firefighter schrieb:

Ich kann mich noch gut erinnern wie du von mycsharp mal geschwärmt hast

Tja, Zeiten ändern sich, vor allem wenn die Erfahrung steigt.

sagbitte schrieb:

Warum bisse da weggegangen?

Warum das

Du bist aber auch einer der Unverschämt viel Aufmerksamkeit braucht oder?

Nun sag uns doch bitte endlich warum du weggegangen bist, haben dir die Konsequenten Ausführungsorgane(herbivore und Konsorten) nicht mehr gefallen oder was war der Grund?