nein, da muss man nix selber proggen.
Die anderen drei spalten müssen einfach auch ComboboxColumns sein - nur je mit anderm DisplayMember.

Hmm - naja.
Wie's aussieht verwendest du kein typisiertes Dataset.
Das ist dann alles ziemlich chaotisch, und du musst vielleicht doch so rumwursteln.
Also wenn du mal sehen willst, wie es auch gehen kann gugge
vier Views-Videos
Der Code dazu ist aber vb - das ist aber nicht wesentlich daran. Wichtig ist, die Konzepte zu verstehen, und wie die Designer zu nutzen sind.

uff - da bin ich draussen - Knapsack hoch 3!
Bin grade erst dabei Knapsack überhaupt zu kapieren - es ist nicht einfach nur Backtracking.
Tatsächlich ist der Standard-Algo zum Matrix-Füllen nichtmal rekursiv, und auch das anschliessende Auswerten derselben nicht.
Also ich weiss nicht, ob die bei Wikipedia einen richtigen Begriff von Backtracking haben, oder ich - bei mir ist Backtracking rekursiv.
Hier auf myCsharp finde ich auch nix wirkliches zum Knapsack, nur Beiträge, in denen behauptet wird, das sei erledigt, und im besten Falle noch: man solle da und da gucken...
Oft aber auch nur: Man solle selber gucken 8o (ohne da und da)

Hier fand ich schliesslich den Standard-Algo: https://www.programmingalgorithms.com/algorithm/knapsack-problem/
Allerdings ohne die Auswertung der Matrix - das fund ich hier: https://www.proggen.org/doku.php?id=algo:knapsack
Und auch eine mir verständliche Erklärung. Aber die haben eine rekursive Implementierung - vmtl. bisserl suboptimal.
/OT

Ich glaub garnet, dass man da was paralellisieren kann. Bei Knapsack hängt eine Teil-Lösung doch ab von zuvor gefundenen Teil-Lösungen - das kann man doch garnet nebeneinander her-wursteln lassen.

Tja, ich würds gerne probieren, deinen Code zu verbessern - etwa durch Backtracking.
Allein ich sehe ihn nicht...?

Zum Thema Rucksack: Von Wikipedias Erklärung verstehe ich nur iwas mit Backtracking.
Läuft "dynamische Programmierung" etwa auf folgendes hinaus?

Rekursiv alle Kombinationen durchgehen und dabei die (bisher) beste merken.
Bei der rekursiven Vertiefung immer abbrechen, wenn der aktuelle Wert bereits schlechter ist als der bislang gefundene beste Wert ?

das käme mir ziemlich trivial vor, dass man nicht weiter rumprobiert, wenn man eh schon aussm Limit ist.
Ist das, was der berühmte Bellmann meinte?

Ich versteh auch nicht den Wiki-Pseudo-Code mit den verschachtelten For-Schleifen. Sollte ich das richtig verstanden haben, sehe ich da eigentlich keine andere Lösung als eine Rekursive (oder evtl. noch eine, die Rekursion iterativ emuliert, etwa mit einem Stack)

Edit: Ups - Sorry - da kam nun ein Post dazwischen

Wie würde man mit BinarySearch eine Einfüge-Position ermitteln können? Ich dachte, so finde ich nur die Position eines vorhandenen Elementes. Tja, so kann man sich irren.
Ich hab dir doch gesagt, dass List<T> BinarSearch kann.
wie das geht, habich damals auch im Internet rausgefunden. Und dort gelernt, dass bei nicht-Match das Bit-Complement der EinfügePosition returnt wird.

aber wie gesagt: Wenn du wirklich mit nur 10 Elementen unterwegs bist (oder 100, oder 1000), dann lass den Quatsch, und insbesondere iwelche Parallelitäts-Experimente.

schnapp dir Collection<T> und bau erstmal eine funktionierende LimitedSortedList<T>.
Optimieren soll man immer!! als allerletztes machen.

Hi!
Ich arbeite ganz viel mit Datasets - typisierten allerdings. Ich finde, das hat deutliche Vorteile - zB ein an eine DataTable gebundenes DatagridView kann out-of-the-box nach beliebigen Spalten sortieren (bei vielen Datensätzen oft hilfreich).
(ORM - weiss ich garnet, ob die dann neue Abfragen auslösen müssen, oder wie man bei denen Sortierung umsetzt - jedenfalls nicht out-of-box)

Ich wundere mich, wenn du sagst:

Die DataTable benutze ich da ich es schneller geht, die Tabelle von der ich lese hat 4GB, die Daten die ich filter haben dann noch ca. 2GB. Du willst doch nicht etwa ein DatagridView anzeigen mit 2GB Daten?

Wie kann ich in Verbindung mit einer BindingSource darauf zugreifen? Beim typisierten Dataset brauchst du keine eigenen Datenklassen zu erstellen, das macht der Dataset-Designer.
auf eine typisierte Row greift man so zu:

        void changeSelectedCustomerBtn_Click(object sender, EventArgs e)
        {
            var rwCustomer = (CustomerRow)((DataRowView)customersBindingSource.Current).Row;// Get the current Customer from the BindingSource.  
            rwCustomer.CustomerName = "Tailspin Toys";
            rwCustomer.PhoneNumber = "(708)555-0150";
        }

        void changeFirstCustomerBtn_Click(object sender, EventArgs e)
        {
            var rwCustomer = (CustomerRow)((DataRowView)customersBindingSource[0]).Row;// Get the first Customer from the BindingSource.  
            rwCustomer.CustomerName = "Tailspin Toys";
            rwCustomer.PhoneNumber = "(708)555-0150";
        }

Mehr brauchts nicht - nichtmal Kommentare - wenn zB die Buttons korrekt benamt sind.
Sind sie aber bei dir nicht, und deine Kommentation ist scheints veraltet, und trifft unzutreffende Aussagen

Ich hab mich vor langem mal an so wiederverwertbaren Forms versucht - unds dann gelassen.

Wenn du das Form in ein anderes Projekt einbindest - kannst du dann dort im Designer Controls hinzufügen? Das war bei mir damals problematisch.

System.Collections.ObjectModel.Collection<T> ist dafür vorgesehen.
Eigene Auflistungen zu basteln, und ist dafür ausgezeichnet geeignet.
Bestimmte Member sind protected virtual, sodass man mit Leichtigkeit gezielt das Verhalten modifizieren kann.
nämlich nur protected SetItem() und InsertItem() wären zu überschreiben - feddich.
So erbt man das komplette IList<T>-Interface, ohne auch nur einen Finger dafür zu rühren.

Wenn man auf Performance abzielt könnte man beim Einfügen sogar BinarySearch zum Auffinden der Einfüge-Position anwenden. Dazu einfach die innere Liste nehmen - das ist eine List<T>, und List<T> kann BinarySearch.
Dann muss beim Add nicht mehr sortiert werden. Nicht viel Aufwand, aber bei 10 Elementen scheint mir auch das unsinnig.

Du könntest eine Methode SetzenText(Textbox tb) schreiben.

static class SL
{
public static void SetztenText(Textbox tb)
        {
            tb.text="Hallo";
        }
}

Aufzurufen:

SL.SetztenText(this.texbox1);

Das würde von jedem Form aus gehen (ob sowas sinnvoll ist sei dahingestellt)

Ich habe jetzt die einzelnen Importphasen in eigene Funktionen gegliedert... Dassis schoma sehr gut, und der erste Schritt.
... Welche meiner Funktionen muss async sein und wo wird das await angewendet? Wurde schon gesagt: die Zeitfresser müssen Async.
Ich hab mal auf CodeProject ein Tut gebastelt, was zeigt, wie man mit minimalem Eingriff eine Methode in einen NebenThread schubst.
Die gezeigten Code-Snippets sind zwar vb, es hat aber auch eine c#-SampleSolution.
Wie gesagt: Es trifft sich sehr gut, dass du die Kandidaten bereits in eigene Methoden isoliert hast.
Async/Await
Was anfangs als zum schreien einfach anmutet erweist sich dann doch als typischer Rattenschwanz:*Ist eine Methode Async auf den Weg gebracht, musst du so lange verhindern, dass der Button nochmal geklickst wird (Suspend Gui) *Während das Teil läuft willst du eine Progressbar oder sowas (Update Gui) *Natürlich will der User den Vorgang auch canceln können (Cancellation) *Fehler müssen (fast immer) im Gui-Thread behandelt werden (Error-Handling)

Jo - wird alles behandelt in meim Tut.
(Wenn du es brauchbar findest, rate es up - ich wunder mich immer, was für Artikel auf CP irrwitzig hochgeratet sind, während so ein Fundamental-Artikel zu einem ich finde bahnbrechend neuem Feature bei weniger als 20 ratings rumdümpelt.)