Hab's hin bekommen. Hätte ich auch selbst drauf kommen können
private void rdcmdServerD_CheckedChanged(object sender, EventArgs e)
{
txtApplicationD.Visible = rdcmdServerD.Checked;
lblApplicationD.Visible = rdcmdServerD.Checked;
txtDescriptionD.Hide();
lblDescriptionD.Hide();
txtSwitchportD.Hide();
lblSwitchportD.Hide();
}
Geht super.
das ist zumindest nicht die feine art..
http://c-plusplus.net/forum/viewtopic-var-p-is-1962801.html
http://c-plusplus.net/forum/viewtopic-var-p-is-1962763.html
poste es doch bitte nur in eine "rubrik" - zum beispiel in rund um die programmierung oder ausbildung.
so gibt es ein posting gewirr und viel verschwendete zeit und doppelte argumente.
und was schätzt du werden die leute in den entsprechenden subforen empfehlen?
Also den zweiten Fall hast du ja anscheinend gelöst. Du kannst eine Datei, zeitgleich mehrmals kopieren. Das wolltest du doch!?
Und beim ersten willst du wohl prüfen, ob der Benutzer nur Leserecht hat? Nicht ob die Datei in Zugriff ist?
Um Rechte abzufragen, solltest du mal GetAttributes probieren.
Ich hab gerade selber eine Lösung gefunden glaube ich, obwohl ich bezweifel das es nicht die optimale ist:
con.Open();
reader = cmd.ExecuteReader();
while (reader.Read())
{
dgvServer.Rows.Add(
reader["ip"],
reader["application"],
reader["name"]);
}
reader.Close();
con.Close();
EDIT:
Habe den Code ein paarmal getestet und es geht ganz gut mit dieser Lösung. Würde mich trotzdem interessieren ob ihr noch bessere oder optimiertere Lösungen kennt?
Hallo Experten,
stimmt, die Fehlermeldung ist logisch.
Also folgende Situation:
Ich habe in einer C# - WPF- Applikation eine "normale", eigene Win32 Standard- DLL eingebunden, die ihrerseits die MFC verwendet (historisch) und dort also Ausnahmen behandelt. Bisher habe ich diese Ausnahmen innerhalb der DLL behandelt. Ich habe in einem try{}- Block einen Fehler festgestellt und darauf hin eine eigene Ausnahme mit throw(MVHW_IMGSZ_ERR) geworfen, die ich innerhalb der Funktion mit catch(DWORD nErr) {} aufgefangen und behandelt habe.
Jetzt komme ich also bis zum throw(), lande aber nicht im catch(), sondern bekomme von "ganz oben" die Fehlermeldung...
Eine nicht behandelte Ausnahme des Typs "System.Runtime.InteropServices.SEHException" ist in WindowsBase.dll aufgetreten. Zusätzliche Information: Eine externe Komponente hat eine Ausnahme ausgelöst.
Frage:
Wie kann ich verhindern, dass mir wahrscheinlich die Applikation die Fehlerbehandlung wegnimmt?
Ich danke Euch im Voraus für Eure Antworten.
Den Code übernehmen nach da?
WCF ist ja ein Sammelsorium an Diensten. WebDienste(z.b.SOAP), Windows-Dienste etc,
Ich denke Du hast einen Windowsdienst genommen und der müsste
installiert/registriert werden am System. Da solltest zu mal mehr zum
Stichwort "Verteilte Anwendungen" lesen.
Für Silverlight nimmt man aber eher Webdienste. Silverlight ist für das
Web ausgelegt und ist rein Clientseitig.
Was hast du denn vor?
Installer schrieb:
[...]keine Kontrolle. [...]nichtmal über den Installationspfad.
Hi Installer,
deine Kritik ist berechtigt. Genau aus diesem Grund würde ich auch gerne auf die "Veröffentlichen" Funktion verzichten. Leider ist Verwendung dieser Funktionalität fester Bestandteil unseres Unternehmens und ich kann leider nicht darüber entscheiden (darauf zu verzichten).
Somit komme ich um einen Workaround wohl nicht drumherum.
Gruß
Hallo ich habe folgendes Problem
Ich möchte per XSD eine Klasse definieren welche ich per XML Serialisieren und Deserialisieren kann. Innerhalb dieser Klasse habe ich eine Collection von Points. Gibt es irgendwelche möglichkeit diese Points innerhalb der xsd datei schon als System.Drawing.Point zu definieren? Ich mag nicht jedes mal meinen eigenen Point Array durchlaufen um dann einen neuen Drawing.Point Array anzulegen. Gibt es ggf andere möglichkeiten wie ich das gewünschte erzielen kann?
Funktionen die z.B. Standardmäßig nach dem deserialisieren aufgerufen werden und diese Konvertierung machen könnten? Wichtig ist einfach das die Klasse welche per XSD.exe generiert wird, so erhalten bleibt wie sie generiert wurde. Es nützt mir nichts innerhalb der erzeugten CS Datei etwas zu ändern, da diese eh immer neu generiert werden soll. Mir fällt da spontan nichts sinnvolles ein wie ich das lösen könnte.
Dir wurde schon vor 5 Monaten weitergeholfen.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-266107.html
Hier noch einen anderen Thread zum Thema:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-272550.html
Aber dieser Thread wird geschlossen, kannst gerne den alten wieder hervorholen, falls du es wirklich ernst meinst.
Grüssli
Es wird alles durch gerouted, das ist korrekt. Aber nur der owner des Controls kennt es tatsächlich.
Sobald du selber ein EventHandler setzt, also das Event fangen möchtest, wird intern dieses AddHandler aufgerufen, somit lauscht das Window dann aktiv auf dieses Event.
Manche AddHandler werden auch durch Templates gesetzt.
O.o schrieb:
Ich kann das Verhalten bei mir leider nicht reproduzieren. Das einzige was mir aufgefallen ist ist, dass beim Start von "mblctr.exe" eine Meldung erscheint, dass das Windows Mobilitätscenter nur auf Laptops verfügbar sei.
Benutzt du einen Desktop-PC und du siehst nur die Fehlermeldung nicht?
Danke ,das war die Lösung.Ich habe es auf einem Laptop ausprobiert und da funktioniert es.
Vielen Dank
Thomas P
Da wird einfach ein Vollbild (FullScreen Fenster über den Desktop mit entsprechendem Filter gelegt und darüber dann das eigentliche Anzeigefenster (in Farbe).
Also erst ein CopyFromScreen und dann ein Schwarz/Weiß-Filter (Helligkeit jedes Pixels als RGB gespeichert, denn (0x0,0x0,0x0) ist schwarz (0x80, 0x80, 0x80) ist mittelgrau und (0xFF, 0xFF, 0xFF) ist weiß). Die Helligkeit könnte z.B. mittels der HSV-Berechnung ermittelt werden oder aber als (R+G+B)/3.
Für Grafik-Filter-Programmierung kann ich dir die LowLevelGraphicsLibrary empfehlen.
Habe ich vor kurzem erst empfohlen: http://www.c-sharp-forum.de/viewtopic.php?p=619022#619022
Für dich dürfte dann der GrayScale-Filter interessant sein:
new GrayScale().Execute(bitmap);
IMMER Property.
Damit Du im Zweifelsfall verfolgen kannst, wer den Fehler verurscht hat. Einfach ein if/throw in set rein und fertig. Fenster Aufrufstack und man hat ihn.
Ok, fast immer. Wenn Du sicher bist, daß niemals obige Suche nötig ist und Du nicht zwischen read- und write-Rechten unterscheiden willst und niemals unterscheiden willst, und die lächerlich wenigen 5 Takte (heute eine Nanosekunde) (sogar abnehmend, weil die Prozessorbauer sich natürlich des Problems annehmen) für den Zugriff sparen willst, dann halt anders.
Die Schreibarbeit ist ja nicht das große Ding. Die Lesearbeit ist das blöde. Also ich habe stets mindestens 10-mal so viel Lese-Arbeit wie Schreib-Arbeit. Fehlersuche halt. Wenn ich die Quote langsam verbessert habe, gehe ich halt komplizierter Probleme an, so daß ungefähr 1:10 bleibt.
So ein Standard-Property-Ding lese ich weg wie als nicht anders als wenn es als rohes Attribut dastände. Damit ist Get/Set-Property eigentlich nicht teurer. Beim Lesen. Also bei allem, auf was es ankommt. Wenn es mehr als nur nichts tut, muß ich natürlich nachdenken. Aber dann ist es in C# genau dort gut aufgehoben und minimaldenkisch. Also gut.
Weiche nur ab von "Attribute immer private", wenn Du weißt, daß es Performance bringt und du weißt, daß die Zusatzperformance im Gesamtprogramm auch noch ausreichend Einfluß hat. edit: Wobei das sogar eine Optimierung ist, die ein Hauptschüler nach entsprechender Einarbeitung ausmessen könnte und nach vorgegebenem Scheme auswählen könnte und zu 99% optimal wäre. Mach Attribute immer private und erwarte, daß Dein Compilerbauer den Compiler (und deswegen auch die VM) verbessert. In zwei oder drei Jahren haben die es gelöst.
