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)
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.
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:
Zitat von ChookaC
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?
Zitat
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
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.
Ich habe jetzt die einzelnen Importphasen in eigene Funktionen gegliedert...
Dassis schoma sehr gut, und der erste Schritt.
Zitat
... 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.)
ich hab grad was lustiges ausprobiert:
In den Settings eine bool-Property "ControlsEnabled" angelegt.
Einen Button aufs Form, und bei Databindings - ApplicationSettings ein Databinding eingerichtet zwischen dessen Property "Enabled" und my.settings.ControlsEnabled.
Weiters eine Checkbox aufs form, und deren Checked-Property auch an das Setting gebunden.
Jo, nun kannich mit der Checkbox den Button dis/en-ablen - und es ist ganz egal, auf welchem Form/UserControl der liegt.
Ist bei vielen Buttons vmtl. viel Geklickse, das einzurichten, aber ist ganz ohne Code zu schreiben.
HiTest weiss ich jetzt auch nicht, wie für das Problem anwenden.
Mit RectAngle.Intersect() kann man ermitteln, ob 2 Rechtecke sich überschneiden.
Also musst du deine TreeItems durchlaufen um festzustellen, wessen DarstellungsRechteck sich mit deinem Auswahlrechteck überschneidet.
Ich vermute, mit dem Binding stimmt was nicht.
Dann solltest du eine diesbezügliche Fehlermeldung ins Ausgabefenster bekommen, sobald das DataTemplate angewendet wird (also iwas damit anzeigt oder anzeigen soll).
Ich hab mal ein Tutorial verzapft, wo ich derlei Feinheiten der Xaml-Syntax bisserl auf Grund gehe.
Dazu hab ich einfach ein Stück Xaml (fast) ohne jede Syntax-Vereinfachuing formuliert, und anschließend die verschiedenen Vereinfachungen angewendet (Property-Attribute-Syntax, DefaultProperties, Markup-Extensions, TypConverter) - bis schließlich leidlich "normales" Xaml bei rauskommt.
Ähm - eigentlich - zumindest nach Ansicht einer recht grossen Community - sollte man Wpf so nicht programmieren.
Genuiner Bestandteil von Wpf ist der MVVM-Pattern, also statt des CodeBehinds sollte Databinding verwendet werden.
Wennde MVVM noch nie gehört hast, google mal danach.
Zusätzlich dazu gugge vlt. Wpf-AnwendungsStruktur
Ist zwar vb, aber strukturell gibts da kein Unterschied.
meine 5ct: Ich mag CodeFirst auch nicht besonders, weils da nicht mehr den Edmx-Designer gibt.
Der - als Entity-Relation-Diagramm - ist mir nämlich eine große Hilfe beim Konzipieren von Datenmodellen.
Bei CodeFirst habich Mühe, den Überblick zu behalten.
Ich gebe auch die Hoffnung nicht auf, dasses MS demnächst doch noch einfällt, auch EF.Core wieder mit ER-Diagramm-Designer-Unterstützung auszustatten.
Ach Abt - immer ein aufmunterndes Wort für die Anfänger! ;)
Und so unwidersprüchlich:
Zitat
Wie sicherlich dem Wiki zu entnehmen ist, ist XSD einzig und allein zur Definition einer Struktur gedacht
(ähm - welchem Wiki?)
Zitat
Das XSD kann aber auch für andere Dinge verwendet werden, zB durch die strukturelle Vorgabe als IntelliSense Quelle in XML Editoren.
Und ich hätte noch ein, wofür man Xsd gebrauchen kann: Man kann sich damit eine Klassen-Struktur generieren lassen. Ich hab zwar grad vergessen wie das im Einzelnen geht, aber google "c#-Classes from xsd" müsste Anleitung erbringen.
Hat man diese Klassen-Struktur, so kann man eine Xml deserialisieren (Stichwort "Xml-Serialisierung"), und enhält c#-Objekte, die man mit c# manipulieren kann, und das Ergebnis kann man auch wieder serialisieren.
Auf diese Weise muss man mit Xml überhaupt nicht herumfuchteln, sondern es ist ein Instrument, um sehr komplexe Objektstrukturen zu persistieren oder zu transportieren.
Oh - das ist ein ziemlich gutes Control - da brauchste nur der DataSource eine BindingSource zuweisen, und wenn alles richtig konfiguriert ist, ist damit die ListView befüllt.
Gibt doch auch ein umfangreiches DemoProjekt zu dem Control - gibt das denn garnix her für deine Problematik?
ich wüsste nicht, dasses ein json-dictionary überhaupt gibt.
Ansonsten löscht man einen Eintrag aus einem Dictionary mit der Dictionary.Remove() - Methode.
Sehr hilfreich finde ich immer den ObjectBrowser, wo man etwa die dictionary-Klasse suchen kann, und alle verfügbaren Methoden und Properties sehen - inklusive ihrer Aufrufe-Konventionen.
Kennst du den ObjectBrowser? ist ein Built-In-Tool der IDE.
jo - habich gesehen, und wie das als Aufruf rauskommt auch verstanden.
Gefällt mir aber nicht, 3 TypParameter angeben zu müssen - da bleib ich lieber bei der Reflection/dynamic - Lösung.
Wie gesagt: Meine Kernfrage war eher prinzipieller Natur, ob in derlei gelagerten Fällen eine TypParameter-Einschränkung möglich ist, die nicht den TypParameter der Basisklasse mitliefern muss.
Dassis geklärt - ist nicht möglich.
Hätte das einen Vorteil gegenüber dem Ansatz, den ich bereits habe?
Das Feine an meim Ansatz ist ja, dass ich einen Datenabruf an den Service absetzen kann, meist mit einem Einzeiler.
Wie sähe der Datenabruf bei deim Ansatz aus?
Dassis etwas mühsam, weil es um Codes in VB geht, die auf Arbeit sind (und ich krankgeschrieben).
Aber ich habs jetzt mal vom Prinzip aussm Kopf glaub ziemlich korrekt hingebastelt.
Also auf ARbeit haben wir eine Anwendung, die ca. 50 InterfaceMember in 10 WcfServices konsumiert, und das ist eine wahre "DoRepeatYourself"-Orgie, schlimmer noch, die Selbstwiderholungen sind teilweise auch noch inkorrekt implementiert. (hysterisch gewachsener Code).
Also wenn man nur einen besch... String abrufen will muss man folgende Übung absolvieren:
static string GetFoo() {
// dazu Logging, Localisation, Errorhandling, response-Header-Auswertung - in immer derselben Implementierung
using (var myClient = new ServiceClient())
using (var scope = new OperationContextScope(myClient.InnerChannel)) {
OperationContext.Current.OutgoingMessageProperties["Autentication"] = _AutenticationToken;
return myClient.foo().Data;
}
}
Wie gesagt (im Comment angedeutet), das eigentliche Code-Gebrabbel ist hier weggelassen, realiter ists das 3-fache, und ist immer dasselbe.
Das Gebrabbel habich nun isoliert - der Pattern heisst glaub "Function höherer Ordnung einführen":
static string GetFoo2() {
return Execute((ServiceClient clnt) => clnt.foo().Data);
}
static TResult Execute<TService, TResult>(Func<TService, TResult> fnc) where TService : IDisposable, new() {
// dazu Logging, Localisation, Errorhandling, response-Header-Auswertung - einmal implementiert, und richtig
using (var myClient = new TService()) {
IClientChannel chnl = GetChannelFromClient(myClient);
using (var scope = new OperationContextScope(chnl)) {
OperationContext.Current.OutgoingMessageProperties["Autentication"] = _AutenticationToken;
return fnc(myClient);
}
}
}
Wie du siehst - GetFoo2 macht jetzt nur noch, was man denkt was GetFoo2 im Kern zu machen hat - alles annere ist an einem Punkt konzentriert und sauber.
Bisserl unsauber halt noch das GetChannelFromClient(), weil das hampelt - wie du dir auch gedacht hast - mit Reflection rum, bzw. mit dynamic.
Jo, und da bin ich bisserl frustriert, dass ich die TypEinschränkung nicht so formulieren kann, dass ich normal auf myClient.InnerChannel zugreifen kann.
Weil eigentlich sind ja alle notwendigen TypInformationen gegeben.
Es ist also einerseits ein konkretes Problem, andererseits ein abstraktes: Es scheint mir ein Mangel der Sprache zu sein, weil prinzipiell wäre hier doch die Möglichkeit gegeben, auch Polymorphie bereitzustellen.
Nämlich die nicht-generischen Member eines generischen Typs könnte man doch eiglich zugreifbar machen, auch ohne dass der konkrete TypParameter bekannt ist.
Man kanns auch als DesignFehler der ServiceBase<T> - Klasse sehen: Täte die von einer nichtgenerischen ServiceBase erben, welche den .InnerChannel veröffentlichte, wäre ich ebenfalls nu der Notwendigkeit enthoben herumzureflecten.
Ich bin derzeit mit Wcf-Webservices befasst, und immer wenn ich einen instanziere muss ich auch einen ObjectContext instanzieren, und myWebService.InnerChannel übergeben. .InnerChannel ist nichtgenerische Property der Service-Basisklasse, also von ServiceBase(Of TInterface).
Ich würde nun gerne eine generalisierte Methode coden, die gleich beides erstellt: den WcfService und den ObjectContext, und die für alle möglichen WcfService verwendbar wäre - prinzipiell sowas:
public void InitService<TService>()
where TService : ServiceBase<?>, new {
_Service = new TService();
_Context = new ObjectContext(_Service.InnerChannel);
//...
}
Aber leider weiss ich nicht, wie ich die ServiceBase<TInterface> als TypParameter-Einschränkung formuliere, weil ich TInterface nicht habe.
Tatsächlich brauche ich TInterface auch nicht, denn ich will ja auf den nichtgenerische Property .InnerChannel zugreifen - hat ja mit dem Interface nix zu tun.
Geht das überhaupt?
(Übrigens "ObjectContext" ist nicht der richtige Datentyp-Name des 2.Objektes, das ich erstellen muss - ist mir entfallen. Aber ich hoffe das prinzipielle Problem ist klargeworden?)
Ich hab eine komplizierte Abfrage, die läuft recht lange und löscht recht viel.
Der Db-Admin wünscht, dass die Löscherei in Chunks von 500 Datensätzen erfolgt.
Da habich eine komplizierte Lösung, wo ich erst nachzähle, wieviele denn gelöscht werden, dann die Anzahl der dafür benötigten Chunks, und dann in einer While-Schleife abfahren.
Etwas einfacher, aber iwie auch skurril ist eine Lösung, wo ich das Output-Feature dazu nutze, herauszubekommen, wieviele Datensätze gelöscht wurden, und wenn weniger als ChunkSize, die Schleife verlassen - beispielCode (b.Bed auskopieren + testen):
--Chunken mit dem Output-Feature
create table #todelete(numb int )
create table #todelete2(numb int )
declare @count int=0
while @count<100
Begin
insert into #todelete values(@count)
insert into #todelete2 values(@count*2)
select @count=@count+1
end
declare @ChunkSize1 int = 15
create table #deleteds(numb int )
declare @delCount int = @ChunkSize1
while @delCount = @ChunkSize1
Begin
Begin TRANSACTION;
Delete Top (@ChunkSize1) td
output 1 as numb into #deleteds
FROM #todelete td
join #todelete2 td2 on td.numb=td2.numb
COMMIT TRANSACTION;
select @delCount= count(*) from #deleteds;
select @delCount
truncate table #deleteds;
End
select count(*) Rest from #todelete;
drop table #deleteds
drop table #todelete
drop table #todelete2
(das mit toDelete, toDelete2 soll andeuten, dass die Abfrage komplex ist)
Meine Frage: Gibts da nicht was einfacheres?
ich bevorzuge und benutze immer Docking - evtl. kombiniert mit einem TableLayoutpanel.
Damit krieg ich bislang jedes Layout ohne eigenen Sizing-Code hin, und funzt auch immer.
Ansonsten denke ich, ein grundlegender Fehler hier ist, dass versucht wird, die Arbeits-Methode iwie async zu modifizieren.
Das ist nicht erforderlich (kann sein, dasses möglich ist, aber erforderlich ists nicht, und obs und wanns sinnvoll ist weiss ich auch nicht, weil ich mach das nie so.)
Imo soll die Arbeits-Methode arbeiten, und sich nicht um die Nebenläufigkeit kümmern.
Nebenläufigkeit erreicht man durch einen bischen komischen Aufruf, mit Await, Task.Run() und den eiglichen Aufruf in eine anonyme Methode gewrappert.
jo - probierma.
ich gebe noch zu bedenken, dasses oft scheitert, eine "EierlegendeWollmilchsau" zu konstruieren.
Jdfs. bei mir gerät die Verwaltung von auch nur mässig komplexen Optionen meist zu einer eigenen Baustelle, oft auch nicht klein, und sehr anwendungs-spezifisch.
Da muss dann ein eigenes Datenmodell her und ein eigenes Gui - da beißt die Maus kein Faden ab.
Aber probierma: Ich sag ja nicht, dass die "EierlegendeWollmilchsau" prinzipiell immer unmöglich ist - manchmal gelingts auch.
Aber meist eben nicht, daher meine Warnung, da allzuviel Zeit reinzustecken.
Du kannst im FormDesigner das DialogResult von Buttons festlegen, damit bewirkst du gleichzeitig, dass diese Buttons das Form schließen - ohne weiteren Code schreiben zu müssen.
gugge Filmle: Dialoge implementieren
Indem du so den Designer seinen Job machen lässt, entfällt der Button-Klick-Code, und wird insgesamt merklich einfacher:
//nur nötige usings
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
namespace WindowsFormsApp1 {
public partial class Form2 : Form {
public uint Kal {
get { // ifs ohne {} einzeilig notieren
if (Xy_l.Checked) return 1;
if (Xl_ylog.Checked) return 2;
if (Xlog_yl.Checked) return 3;
return 4;
}
}
// readonly props, die ihren Wert selbst ermitteln (kein BackingField)
public decimal X_min { get {return Convert.ToDecimal(Xmin_box.Text); } }
public decimal X_max { get { return Convert.ToDecimal(Xmax_box.Text); } }
public Form2() {
InitializeComponent();
}
}
}
Wobei das problematisch ist, decimal-Werte aus Textboxen zu lesen - das stürzt ab, wenn da jemand "Hallo Welt" reinschreibt.
Für Zahlen-Eingaben NumericUpdown nehmen.