str n00b schrieb:
CSL schrieb:
1. Strings sind immer imutable
macht ja nichts, ich kann doch einer statischen string variable trotzdem verschiedene 'imutables' zuweisen.
Du willst eine referenz eines Strings in einer liste und dem string woanders was zu weisen und das in der Liste soll sich mit ändern, right? Das geht eben nicht da du bei der zuweisung einen neuen string erstellst, da imutable, dh dein string in der liste wird immer der alte bleiben, so lange bis du ihn explizit zuweist oder ihn in eine klasse schachtelst wie ich oben zeigte.
str n00b schrieb:
CSL schrieb:
2. Ein Key darf nur einmal existieren
weiß ich, der key soll sich ja nicht ändern, sondern nur der wert.
Du schriebst doch:
str n00b schrieb:
strings[a_string] = "another string";
zugewiesen. nun soll auch a_string 'automatisch' diesen wert bekommen.
Und das verstand ich so das der key auch ausgetauscht werden soll. Kann mich aber auch täuschen
str n00b schrieb:
CSL schrieb:
3. Doofe idee
nö, ganz im gegenteil. es geht darum weniger code bei der erneuten zuweisung schreiben zu müssen, weil ich von den a_string's ein paar dutzend vorliegen habe. mit c und c++ würd ich das mit zeigern hinbekommen, aber in c# weiß ich zurzeit noch nicht wie. vllt. iwie mit unsafe code, mal schauen
Verpacke doch deine "Dictionary" in ein eigenes Objekt umd erlaube lesen und schreiben nur über zwei Methoden (meinetwegen ein Property) und der sorgt dafür das alles korrekt abläuft, dann hast auch auch immer nur ein single point of entry.
Ich find die idee aber auch doof weil du so mal eben schnell böse Seiteneffekte bekommen kannst.
Die Sache ist ja ganz einfach die:
strings[a_string] = "another string";
du sagst da nicht "der string ist nun "another string", sondern du sagst "die gespeicherte referenz zeigt nun auf den "another string" im Speicher.
Der String worauf die Referenz vorher zeigte existiert noch weiterhin im Speicher, da deine interne liste darauf Zeigt.
-> C# ist eine eigene Sprache, man löst Sachen nicht so wie man es aus anderen Sprachen gewohnt ist also lass disen Unsafe Quatsch, wenn du es wie in C++ lösen willst kannst du auch in C++ bleiben.
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.
