Hallo, ok, folgende Errors im Ausgabefeld beim scrollen des DataGrids:
System.Windows.Data Error: 40 : BindingExpression path error: 'PAUF_2017-8' property not found on 'object' ''DataRowView' (HashCode=41105570)'. BindingExpression:Path=PAUF_2017-8 ; DataItem='DataRowView' (HashCode=41105570); target element is 'TextBlock' (Name=''); target property is 'Text' (type 'String')
Ich habe ein laaanges SQL-Statement, welches ich über den SqlDataReader einlese.
Diesen tue ich dann in ein DataTable:
dbReader = dbCommand.ExecuteReader();
DataTable dt = new DataTable();
dt.Load(dbReader);
und die DataTable dann in das DataGrid:
dG_erg_table.ItemsSource = dt.DefaultView;
Edit:
Die Spalte PAUF_2017-8 wird im DataGrid nicht angezeigt. Aber wenn ich meine Abfrage, mit dem gleichen SQL-Statement, über SQL Server Management Studio Express tätige, wird diese Spalte mit Inhalt gefüllt. Aber nicht immer, manchmal auch mit NULL. Liegt da vielleicht das Problem mit dem DataGrid?
Dravere schrieb:
Firefighter schrieb:
Na klar, abwickeln.
Firefighter als Namen. Verwendet abfackeln statt abwickeln. Der nächste Feuerteufel-Feuerwehrmann?
Grüssli
PS: Ist mein Thread, ich darf Off-Topic sein :p
LOOOL du hast mich erwischt :D:D
Dravere schrieb:
Doug_HH schrieb:
Den Code abzuarbeiten, setzt das Starten der Form voraus!
Seit wann denn das? Der Start ist immer bei der Main-Funktion! Bei einer WinForms Anwendung hast du noch eine Main-Funktion explizit im Code. Bei WPF wird sie vom Kompiler generiert.
Grüssli
Ja stimmt, bin etwas durch den Wind
Hatte das so verstanden, dass er den Code in die Form implementieren sollte.
Ja, ich habe den Artikel nicht ganz verstanden, sonst wäre ich ja nicht hier
@Dravere: Danke! Ich wusste gar nicht dass hier ein Unterschied zwischen Task und void besteht...
Ja, ich denke das ist mein Problem.
Da ich die ausgewählte KatalogInfo für andere Zwecke in einer weiteren DepProp stehen hatte, nutze ich jetzt einfach das Property_Changed Event:
private static void loadedKatalog_PropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
if (e.NewValue != null) ((FragenEditor)d).DGFachbereichCombo.ItemsSource = (e.NewValue as FragenkatalogInfo).VorhandeneFachbereiche;
}
Danke für deinen Tip
Und sind es jetzt immer noch:
1. es reicht nur die ungeraden Zahlen zu testen (außer explizit einmal am Anfang mit der 2)
2. Sqrt(n) sollte die Abbruchbedingung sein (diese aber nur einmalig errechnen lassen!)
3. Und noch effizienter geht es mittels der Formel: p = 6k+1 oder p = 6k-1, s.a. http://de.wikipedia.org/wiki/Primzahl#Eigenschaften_von_Primzahlen
WinForms, hat sich aber erledigt. Scheinbar wurde der Wert irgendwo anders wieder überschrieben.
luker: Wenn man die Buttons manuell anwählt, ist das der Fall. Allerdings können scheinbar durch das Programm auch bewusst - so unsinnig das auch sein mag - mehrere Radios selektiert werden.
Hallo Newbie,
wenn Du das EntityFramework verwendest musst Du auf sowas gar nicht acht geben, denn dort wird automatisch auf Veränderungen geprüft (das kannste sogar abfragen).
Ich nehme aber mal an, dass Du quasi "zu-Fuß" unterwegs bist. Auch in dem Falle ist das gar kein großes Problem. Du holst Dir Deine Daten doch sicher aus einer Klasse mit entsprechenden Properties?
Was hält Dich davon ab, bei jeder Property-Änderung dies zu vermerken?
Oder holst Du alles einzeln per ADO.NET ab? In dem Falle (etwas ungünstig) kannste doch trotzdem prüfen ob sich ein Wert verändert hat - im Grunde ginge dies sogar ohne ADO.
Sag mal mehr was Du da einsetzt und vorhast, dann kann man sicherlich auch mehr dazu helfen.
Viele Grüße
Goa
Hi Vitali,
sowas mache ich über ein zentrales 'MainViewModel', und bündel darin die einzelnen ViewModels (ich trenne, wie in Deiner Überlegung eben auch, die ViewModels sehr gerne auf um den Code lesbarer und die Klassen möglichst klein zu halten).
Deine MainView (mit dem Ribbon) bindet somit an das MainViewModel, welches wiederum die 'Unter-'-ViewModels bereitstellt, hierbei ist halt nur wichtig ViewModel-Änderungen nach 'oben' zu melden (INotify...).
Ob das wirklich 100pro MVVM-konform ist weiß ich nun auch nicht, aber so hab ichs mir jedenfalls angewöhnt bislang und es funktioniert super und der Code ist schön sauber
Viele Grüße
Goa
sonic_1233 schrieb:
Hallo Leute,
bei mir tritt folgende Exception auf:
Die DLL "coredll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
Ich hatte ein ähnliches Problem bei einem von meinem Kollegen geschriebenen DLL, die ich lokal erstellte & dann einer Win32-Konsolanwendung zur Verfügung stellte. Der Grund für den Fehler war, dass Microsoft Visual Studio 2010 nicht den passenden Pfad fand. Als ich dann den vollen Pfad dem DLL-Namen vorstellte, ging es:
Statt
const string csDLL_LOCATION= "BasicFunctions.dll";
[DllImport(csDLL_LOCATION)]
public static extern int registerMe(int i);
… verwende ich
const string csDLL_LOCATION = "C:\\Documents and Settings\\…\\BasicFunctions.dll";
[DllImport(csDLL_LOCATION)]
public static extern int registerMe(int i);
