das sind aber Grundlagen der OOP! ComponentResult ist der Rückgabetyp der Methode (und wird - bei deiner VS-Einstellung - in grün angezeigt, weil es eine eigene Klasse oder Struktur ist, im Gegensatz zu den Standardtypen void, bool, int, ...).
Warum dort aber dieser Rückgabetyp verwendet wird, welche innerhalb der Methode nicht weiter benutzt wird (außer daß dessen Standardkonstruktor aufgerufen wird), kann ich dir auch nicht sagen (evtl. haben einfach alle SPS-Methoden diesen einheitlichen Rückgabetyp?).
Diese Methoden (sowie die zugehörigen Klassenmember wie z.B. client) solltest du aber recht einfach in eine eigene Klasse auslagern können. Bedenke aber, daß du dann alle Zugriffe auf die GUI-Komponenten (wie z.B. die Textbox-Texte) dann als Parameter übergeben mußt.
Die Modifikatortasten (Strg-, Umschalt- und Alt-Taste) lassen sich über die statische Eigenschaft Control.ModifierKeys in den Ereignismethoden (z.B. Click) abfragen.
Ansonsten müßtest du noch zusätzlich KeyDown und KeyUp abonnieren und dort die aktuell gedrückten Tasten merken (und wieder entfernen).
Wenn die Eigenschaft Status heißt, so mußt du auch "Status" bei GetProperty angeben (und nicht "status")!
Eigenschaftsnamen in C# sollten laut C# Coding Conventions auch genau so benannt sein (d.h. mit einem großgeschriebenen Anfangsbuchstaben), dies solltest du also nicht ändern.
Da wirst du dich selber ein bißchen einlesen müssen.
Die Hauptmethode für dich ist Type.GetProperty sowie PropertyInfo.GetValue (dort gibt es auch jeweils Beispiele).
PS: Die Strings für die Eigenschaftsnamen müssen aber exakt übereinstimmen (d.h. auch Groß-/Kleinschreibung).
Du verwendest für die Eigenschaften der 4 Textboxen ja immer dieselbe Variable myTextBoxes[i] (deren Werte du jeweils überschreibst), so daß du letztendlich 4 mal die letzte TextBox erzeugst.
Bei 4 individuellen TextBoxen (mit jeweils unterschiedlicher Position und Größe) solltest du 4 getrennte Aufrufe machen:
myTextBoxes = new TextBox[4];
for (int i = 0; i < myTextBoxes.Length; i++)
{
// Neue TextBoxen erzeugen
myTextBoxes[i] = new TextBox();
}
//
// txtAppName
//
myTextBoxes[0].Font = new Font("Consolas", 12F, FontStyle.Regular, GraphicsUnit.Point, (byte)0);
myTextBoxes[0].Location = new Point(33, 107);
//myTextBoxes[0].Name = "txtAppName" + i; // Name benötigst du für dynamisch erzeugte nicht mehr
myTextBoxes[0].Size = new Size(250, 26);
myTextBoxes[0].TabIndex = 2;
// ... analog für die weiteren TextBoxen [1]-[3]
// ...
for (int i = 0; i < myTextBoxes.Length; i++)
{
// TextBox auf dem Formular plazieren
Controls.Add(myTextBoxes[i]);
}
Eleganter ginge es noch mit einer eigenen Methode CreateTextBox(...) sowie den verschiedenen Positionen, Größen etc. in jeweils einem eigenen Array:
Point[] locations = { new Point(33, 107), /* ... */ };
Size[] sizes = { new Size(250, 26), /* ... */ };
for (int i = 0; i < myTextBoxes.Length; i++)
{
myTextBoxes[i] = CreateTextBox(locations[i], size[i], /* ... */);
Controls.Add(myTextBoxes[i]);
}
So hältst du Methoden und Daten getrennt voneinander.
PS: Mit ExecLine(...) ist einfach eine Methode gemeint, welche die Daten dann verarbeitet.
Ich halte den Code von @BerndFfm trotzdem für Frickelcode.
Beim TableLayoutPanel brauchst du kein UserControl, da ja jedes Control in eine eigene Zelle platziert wird (bei einem UserControl würde man eine Zeile davon erzeugen und dann jeweils in eine einspaltige TableLayoutPanel oder aber in ein Panel packen).
Und deine eigene CreateRow-Methode rufst du dann in einer Schleife 10 mal auf (am besten im Form-Konstruktor nachInitializeComponent!).
Du übergibst am besten dann die Referenz auf das TableLayoutPanel an diese Methode (oder nicht ganz so flexibel benutzt direkt das auf der TabPage platzierte TableLayoutPanel).
Wenn du dir unsicher mit dem Code dafür bist, dann kannst du ja mal deinen Versuch hier reinstellen.
Vom Prinzip aber einfach
void CreateRow(TableLayoutPanel tableLayoutPanel, int row)
{
var checkBox = new CheckBox()
{
//Parent = TableLayoutPanel; // Edit: Merke gerade, daß dieses hier überflüssig ist, da es implizit durch SetCellPosition gesetzt wird
// weitere Eigenschaften
};
panel.SetCellPosition(checkBox, new TableLayoutPanelCellPosition(0, row); // 0 ist der Spaltenindex (d.h. diesen dann in dem unteren Code entsprechend ändern!)
// gleiches wie oben dann für die 4 TextBoxen
// ...
]
Ob du die 10 Zeilen schon initial anlegst oder dynamisch in der Methode mußt du selbst entscheiden.
Ich hoffe, daß du dann dieses Prinzip verinnerlicht hast und bei einem nächsten Projekt (oder auch noch für andere Teile dieses Projekts) dann sofort diesen Weg benutzt, anstatt mühselig im Designer X-mal die gleichen Controls anzulegen.
Und dann wäre der nächste Schritt halt "Data Binding", d.h. daß man einem Control nur noch die Daten (als Liste o.ä.) gibt und dieses selbständig diese Daten anzeigt. Dafür eignet sich bei WinForms am besten das DataGridView - aber dann solltest du dafür ein eigenständiges Textprojekt zum Herumexperimentieren anlegen.
Viel Erfolg noch!
PS: Bzgl. der Logik: Wenn z.B. die erste und letzte CheckBox "gecheckt" sind (d.h. die Indizes 0 und 9), was nützt dir dann die Info, daß die Anzahl davon 2 ist? Die Schleife würde dann ja nur von 0 - 1 zählen.
PPS: Es geht bei den MagicStrings um die Angabe für die Controls.Find-Methode (da vom Compiler nicht überprüft werden kann, ob du die ganzen Controls auch so im Designer angelegt hast). Es gibt halt im Framework manche Methoden, welche man besser nicht (oder nur selten) nutzen sollte. Bei dieser Methode müssen ja jeweils immer alle auf der Form platzierten Controls auf Namensgleichheit überprüft werden - und das kostet auch Performance).
Wie schon geschrieben, nützt dir die Anzahl der gecheckten CheckBoxen gar nichts, da du dann ja immer noch nicht die zugehörigen Indizes weißt (ich hoffe, du verstehst, wie unlogisch dies daher ist?).
Sind denn die 10 Reihen fix oder kann es auch mehr oder weniger geben?
Aber alleine schon das manuelle Erzeugen der einzelnen Controls im Designer ist doch viel zu aufwendig (insb. falls mal Änderungen erfolgen sollen).
Erzeuge eine Methode zum Hinzufügen einer Reihe (d.h. eine CheckBox und die vier TextBoxen - welche auch wieder mittels einer Methode implementiert sein sollte) und rufe dann in einer Schleife diese auf.
Wenn du nicht genau weißt, wie der Code dafür aussehen soll, dann schau dir in der bisherigen zugehörigen "designer.cs"-Datei den Code dafür an und kopiere ihn.
Und dann kannst du beim TableLayoutPanel die Methode GetControlFromPosition in einer Schleife aufrufen, um an die einzelnen Check- und TextBoxen zu gelangen (d.h. entsprechend casten).
Die im Designer erzeugten Sub-Controls löschst du dann wieder (außer evtl. das TableLayoutPanel).
So sollte der Gesamtcode dann wirklich minimal sein (und viel flexibler und wartbarer).
PPS: Magic Strings sind die hartcodierten Namen deiner Controls (d.h. wenn man im Designer mal den falschen Namen oder Index angibt, knallt dein Code).
Er hat X CheckBoxen mit jeweils zugehörigen TexteBoxen und möchte für jede 'checked' CheckBox eine Aktion ausführen (und da er sie anscheinend einzeln im Designer platziert und benannt hat, benutzt er dafür jetzt Controls.Find(...)).
Und alleine schon die Reihenfolge der CheckBoxen muß ja nicht zwingend zu den Indizes passen...
Der ganze Ansatz mittels X per Designer erstellten Check- und TextBoxen ist schon falsch (unprofessionell). Stattdessen würde man passende Container-Controls (z.B. DataGridView oder TableLayoutPanel) benutzen oder aber ein User-Control (für eine "Zeile") dafür entwickeln und diese dann dynamisch erzeugen und in einer Liste ablegen (beachte wirklich den von Abt verlinkten Artikel dazu).
PS: @BerndFfm, dein 2. Code paßt nicht zu der Anforderung.
da bringst du anscheinend einiges durcheinander:
1. Du verwendest WPF (System.Windows), nur daß du alles als Code-Behind hast, anstatt als XAML Code, geschweige denn mit MVVM: [Artikel] MVVM und DataBinding!
Daher sollte dieser Beitrag dorthin verschoben werden (macht evtl. ein Mod).
2. Komplett falsche Herangehensweise bzgl. langlaufenden Hintergrundaktionen, s. [FAQ] Warum blockiert mein GUI?
Auch die Namensgebung Script deutet auf ein falsches Verständnis hin.
Du mußt dir zuallererst einmal die Grundlagen der ereignisorientierten Programmierung (Stichwort: Windows Message Loop) aneignen.
Und dann deinen Code sinnvoll in UI und Logik aufteilen (schaue auch mal in [Artikel] Drei-Schichten-Architektur).
Für asynchrone Programmierung helfen dir die Schlüsselwörter async/await sowie die Task<T>-Klasse (das ist aber ein fortschrittliches Thema).
Verstehe ich das richtig, daß du daher aufgrund deiner Frage zur Parameteranzahl damit herausfinden möchtest, um welche Version es sich handelt?
Das ist, wie schon geschrieben, so nicht möglich.
Und beim Aufrufen der Funktionen per dynamischen Laden müßtest du ja sowieso Marshal.GetDelegateForFunctionPointer (LOL: "marshal" wird als "Mars Hallen" übersetzt) benutzen und dafür dann je nach Funktionsvariante passende Delegates erzeugen.
Du solltest einfach alle Funktionsvarianten (welche du in deinem Programm auch aufrufen möchtest) per DllImport erzeugen (ich nehme an, die DLL hat immer denselben Namen). Du mußt dann nur in deinem Programm eine passende Logik einbauen, welche die verschiedenen Versionen erkennt (evtl. die Datei-Info auslesen?) und dementsprechend dessen Funktionsvarianten aufruft.
Warum gibt es überhaupt verschiedene Versionen der DLLs, die dein Programm unterstützen soll?
MyDll ist eine Fremd Dll auf C bzw. C++ Basis soweit ich weiß.
Dann sollte es dafür doch eine zugehörige Headerdatei (.h oder .hpp) geben, in der die Funktionen deklariert sind. Die Aufrufe mußt du dann nur per "Marshalling" nach C# übertragen (also so wie du es bisher auch für die Funktionen LoadLibrary und GetProcAddress per DllImport gemacht hast) - du mußt die DLL also nicht dynamisch laden (außer du willst wirklich ein Plugin-System realisieren, d.h. beliebig benannte DLLs mit einheitlicher Schnittstelle aufrufen zu können).
Beide Steuerelemente (Controls) haben die Eigenschaft Text, der du den Buchstaben zuweisen (bzw. anhängen kannst):
char c = 'A';
label.Text = c.ToString(); // oder += zum Anhängen
Innerhalb der Button.Click-Ereignismethode kannst du dann den Button.Text auslesen und diesen dann dem Control.Text zuweisen.
Ich hoffe, du weißt schon wie man eine Ereignismethode für verschiedene Steuerelemente anlegt (damit du nicht 26x denselben Code hast)?!
PS: Wenn du gerade erst mit dem (C#) Programmieren anfängst, dann solltest du ersteinmal reine Konsolenanwendungen erstellen (und damit dann die Grundlagen erlernen), anstatt gleich eine GUI (wie WinForms) zu benutzen (welche die Grundlagen wie Benutzen von Eigenschaften und Ereignissen [[FAQ] Eigenen Event definieren / Information zu Events (Ereignis/Ereignisse)] voraussetzt).
Da fällt mir nur ein, daß du eine eigene Klasse mit den zwei Eigenschaften Font und Color erstellst und dafür dann den eigenen FontEditor zuweist.
Ich hatte vergessen, daß die Farbe ja nicht im Font-Objekt gespeichert wird, sondern man beim Zeichnen ja extra ein Pen (bzw. Brush) zusätzlich angeben muß.
Alternativ kannst du aber auch einfach eine eigene Eigenschaft Color in der Klasse AttributesForPropertyGrid erstellen und dort wird dann der ColorDialog aufgerufen.
Laut den Sourcen von System.Drawing.Design.FontEditor (mit ILSpy nachgeschaut) wird dort explizit die Eigenschaft ShowColor auf false gesetzt.
Evtl. klappt es, wenn du einen eigenen FontEditor (von UITypeEditor abgeleitet) implementierst und das EditorAttribute setzt:
[Editor("MyFontEditor", typeof(UITypeEditor))]
PS: Ich sende dir den Code per PM (da ich nicht weiß, ob ich diesen einfach hier veröffentlichen darf).
Das ist technisch nicht möglich. Die Parameter von nativen (z.B. in C oder C++ geschriebenen) Funktionen werden über den Stack (welches einfach nur ein Byte-Array darstellt) übergeben und ausgelesen. Genausowenig ist es daher möglich die genauen Datentypen der Parameter abzufragen, ohne den Code zu kennen. Daher ist es zur Verwendung zwingend nötig, die genaue Signatur der Funktion zu kennen.
Anders sieht es bei .NET aus, da diese mittels Reflection erfragt werden können.
Da wäre ich nie drauf gekommen. Die Kamera schickt mir eine Antwort. Diese muss ich nun wieder in einen String zurück wandeln.
Mir scheint, dir ist nicht so ganz klar, was Binärdaten sind. Die Herangehensweise mit Strings deutet auf eine falsche Vorstellung davon hin.
Du solltest dich daher mal intensiver mit den Basisdatentypen und deren Konvertierungen beschäftigen, gerade wenn du Client-Server-Programmierung (Protokolle) implementieren willst.
Schau dir besonders mal die beiden Klassen BinaryReader und BinaryWriter an, welche dir bei der Implementierung helfen können.
Nur, damit du, Sascha87, es nicht falsch verstehst. Der obige Code von Abt ist zwar syntaktisch jetzt richtig, aber benutzt direkt eine UI-Komponente (listFach.SelectedValuePath), und das ist eben nicht MVVM-konform.
Als Beispiel: Step by Step WPF Data Binding with Comboboxes ("Databinding ComboBox Example #1": Eigenschaft ColorString im VM-Code sowie das zugehörige Binding im vorherigen XAML-Code).
Und diese (entsprechend für deinen Code umbenannte) Eigenschaft verwendest du dann als Parameter für die Load(...)-Methode.
Dann mußt du auch die Auswahl der ComboBox (SelectedValue) als ViewModel-Eigenschaft erstellen (und per XAML binden) und diese dann in den weiteren ViewModel-Methoden verwenden.
PS: Warum sind die Load-Methoden als static definiert und benutzen jeweils statische Membervariablen?
Außerdem solltest du dir auch mal [Artikel] Drei-Schichten-Architektur durchlesen: Datenbankabfragen sollten nicht im ViewModel (Logik) durchgeführt werden, sondern in einer eigenen Datenzugriffsklasse (-schicht).
Und sowohl MySqlCommand als auch MySqlDataReader sollten per using-Anweisung umschlossen sein - dann benötigst du auch kein manuelles Close() mehr.
Überlege mal, was mit dem Wert n bei return n in der Methode berechneNullstellen beim Aufruf von
k.berechneNullstellen();
geschieht?!
Edit: Und zusätzlich zur schon erwähnten Ungenauigkeit bei Fließkommazahlen, findet deine Methode bisher nur Nullstellen von ganzzahligen X-Werten (x++)...
PS: Kommst du von Java, C oder C++?
Deine Klasse Nullstellen sollte Eigenschaften (statt der get- und set-Methoden) verwenden.
Intern werden die Komponenten Line, Polyline, ... auch mittels Pen (bzw. bei einem Muster mittels Brush) gezeichnet und standardmäßig wird Antialiasing benutzt.
Hast du denn mal SnapToDevicePixels=true ausprobiert?
Und was passiert, wenn du line_width = 1 setzt?
Und die OnRender-Methode dient nur als Beispiel zum direkten Zeichnen.
PS: Warum setzt du die points in der DrawSomeLines()-Methode doppelt?
Und das Setzen der line.Points kannst du verkürzen zu
line.Points = new PointCollection(points); // keine eigene Schleife nötig
Ich dachte es geht um die Boards, wo ein User keine ungelesenen Themen mehr hat.
Es ist klar, daß die bisherige Query nur Boards mit enthaltenen Themen liefert (da ja über alle Themen [Threads] selektiert wird).
Aber ist das wirklich ein Problem?
Du könntest natürlich ebenfalls hier einen LEFT JOIN machen:
SELECT * FROM [ForumBoards] AS [fb]
LEFT JOIN (<bisherige Query>) AS [fb2] ON [fb].[Id] = [fb2].[ForumBoardId]
So erhältst du dann allerdings NULL in den zurückgegebenen Spalten für die Boards ohne Themen (anstatt z.B. 0).
Edit: Ah, jetzt habe ich wohl deine Gesamt-Query verstanden (auch bzgl. der "Berechtigungen des Users").
Ich war bisher davon ausgegangen, daß ForumRelationsDbView alle Themen zurückliefert (aber diese sind nur in ForumThreads enthalten).
Dann wirst du die bisherige Query etwas anders aufbauen müssen (und zwar kombiniert mit meinem obigen LEFT JOIN).
Du solltest den SELECT mit der Gruppierung separieren (und als Sub-SELECT des LEFT JOIN einbinden).
Und der erste SELECT links davon sollte nur die Boards (mit Berechtigungen) betrachten.
Hier mal als Grob-Entwurf:
SELECT *
FROM [ForumRelationsDbView] AS [f]
INNER JOIN (
SELECT Berechtigungen des Users
) AS [t] ON [f].[ForumBoardId] = [t].[Id]
LEFT JOIN
(SELECT [f2].[ForumBoardId], COUNT(*) AS [BoardThreadCount],
COUNT(CASE WHEN [f3].[ForumThreadId] IS NULL OR [f3].[UserAccountId] IS NULL THEN 1 END) AS [BoardThreadsUnvisitedCount],
COUNT(CASE WHEN ([f3].[ForumThreadId] IS NOT NULL AND [f3].[UserAccountId] IS NOT NULL) AND ([f3].[LastVisitedOn] < [f2].[PostedOn]) THEN 1 END) AS [BoardThreadsWithNewPostCount]
FROM [ForumPosts] AS [f2] WHERE [f].[ForumThreadLatestPostId] = [f2].[Id]
LEFT JOIN ForumThreadUserVisits] AS [f3] ON [f2].[ForumThreadId] = [f3].[ForumThreadId]
WHERE ([f3].[ForumThreadId] IS NULL OR [f3].[UserAccountId] IS NULL) OR [f3].[UserAccountId] = :UserId
GROUP BY [f2].[ForumBoardId]
) AS [fb2]
ON [f].[ForumBoardId] = [fb2].[ForumBoardId]
(ich hoffe, ich bin bei den vielen Alias- und Spaltennamen nicht durcheinandergekommen)
Und hoffentlich kriegst du das dann so auch in EF als Linq-Ausdruck hin. ;-)