Für Error-Handling ist es vermutlich eine schlechte Idee. Es mag Spezielfälle geben wo es Sinn macht, aber das so allgemein als Lösung vorzuschlagen halte ich für doof (vor allem: Lösung für welches Problem überhaupt?).
Beim Logging könnte es z.B. nützlich sein, um eine Komponente, die haufenweise Informationen rausloggen kann, von der Logging-Implementierung zu entkoppeln.
Hallo,
Ich bräuchte für meine Anwendung die Möglichkeit Buttons eine gewisse Transparenz zu geben.
Ich weiß, dass man unter .net 3.5 mit WPF bei Button und anderen Controls das Opacity Property verwenden kann. Es ist aber zu aufwändig die gesamte Anwendung auf das neue System umzustellen.
Jetz wollte ich also fragen ob vielleicht jemand eine Lösung für dieses Problem kennt oder mir einen Tipp geben könnte wie ich diese Funktion implementieren könnte.
Danke im Voraus
Mit dem Operator + hängst Du weitere Delegaten ein:
namespace ConsoleApplication2
{
class Program
{
public delegate void testD(int a);
static void Main(string[] args)
{
testD wahl = delegate(int a)
{
Console.WriteLine(a);
};
wahl += delegate(int a)
{
Console.WriteLine(String.Format("Und noch mal:{0}", a));
};
wahl(5);
}
}
}
fujitsufan schrieb:
Jetzt hab ich mal alle überflüssigen casts weggelassen.
Du hast noch einen vergessen. Ausserdem tummeln sich in Deinem Vergleich unnötige Klammern – und zu guter letzt ist das ganze sowieso unnötig aufwendig. Vor allem solche expliziten Zuweisungen an eine Boolean-Variable sind fast immer überflüssig.
Und zu guter Letzt: lass die Präfixe vor den Variablen weg, die bringen nichts und irritieren bloß.
Weniger ist mehr .
Sehr richtig. Daher:
private bool IsFlagSet(int value, int flags) {
int mask = 1 << value;
return (flags & mask) == mask;
}
EDIT: Den Funktionsnamen kann man auch anschaulicher machen.
Servus,
geht recht einfach. Google einfach mal nach "Broadcast C#"
> http://dotnet-snippets.de/dns/c-broadcast-senden-SID567.aspx
> http://www.demo2s.com/Code/CSharp/Network/BroadcstSample.htm
sind einige Beispiele, wie man sowas lösen konnte.
gruß
Hellsgore
Du kannst das auch Windows erledigen lassen, einfach WM_NCHITTEST abfangen (WndProc des UserControls überschreiben) und Windows mittels HTCAPTION glauben lassen es hätte die Titelzeile eines Fensters erwischt
google findet mit "WM_NCHITTEST HTCAPTION C#" bestimmt auch Quellcode oder zumindest brauchbare Ansätze.
Bei der Methode hat man auch keine Probleme mit Mouse-Captures etc. und das ist glaube ich auch nur sehr wenig Code...
HappyIntPtr schrieb:
mal eine kurze Frage hierzu: in dem Dispose"Pattern" von MSDN wird ein Interopaufruf (closehandle) verwendet. Ist das wirklich notwendig ? Ich setze beim Cleanup in unsafe-Blöcken einfach IntPtr auf zero (wie es ja danach noch gemacht wird). Trotz teilweise großer Speichermengen (mehrere 100MB) und langen Laufzeiten (Tage) hatte ich kein Speicherleck. Ich weiß dass das nicht unbedingt beweisend ist aber dennoch: warum ?
Naja das kommt darauf an was in den IntPtr drinnensteht.
Wenn es ein Zeiger auf einen Speicherbereich ist der über die GC Funktionen "gepinnt" wurde, dann reicht es AFAIK nicht aus einfach den IntPtr auf IntPtr.Zero zu setzen - der Block würde sonst nie vom GC collected (weil dieser denkt dass ein Programmteil über den er keine Informationen hat den Speicher noch verwendet - sonst könnte es ja passieren dass der GC Speicher "einsammelt" der noch von irgendwelchen unmanaged DLLs verwendet wird). In dem Fall müsstest du den Speicher auch über die entsprechende GC Funktion wieder ent-pinnen - das Nullsetzen des IntPtr ist dann aber eine Fleissaufgabe.
Wenn der Speicher über das "fixed" Keyword gepinnt wurde dann musst du garnix machen, da der Block ja beim Verlassen des "fixed" Blocks automatisch "ent-pinnt" wird. Ein Nullsetzen des IntPtr ist dann aber auch nicht erforderlich.
Und wenn du irgendwie die Adresse eines nicht-gepinnten Speicherbereichs in einen IntPtr bekommst, dann ist das sowieso ein Fehler, da dann nicht garantiert ist dass die Adresse sich nicht ändert (und ein IntPtr eben keine Referenz ist die der GC entsprechend anpassen würde wenn er etwas verschiebt, sondern eine einfache Zahl, die der GC nie ändern wird). Ich wüsste jetzt zwar garnicht wie man das ohne gröbere Hacks hinbekommt, aber falls es geht ist es auf jeden Fall Unsinn. Dass es mit grösseren Speicherbereichen oft trotzdem geht (weil diese in einem Eigenen Bereich allokiert und nicht vom GC verschoben werden) ist wieder so ne Sache -- verlassen sollte man sich halt nicht darauf.
fischlefisch schrieb:
Es fehlt noch der Rückgabetyp der überschriebenen OnPaint Methode, ich nehme mal void an ...
richtig
fischlefisch schrieb:
wo wir gerade davon sprechen, wann wird diese eigentlich aufgerufen?
Falls du darauf anspielen willst wie du selbst ein Neuzeichnen veranlassen kannst: Control.Invalidate()
Ansonsten wird OnPaint
ok nun gehts hatte tatsächlich noch nen fehler drinne...schon komisch manchmal prüft man es 20 mal und sieht es trotzdem nicht. Ähnlich wie das USB-Stick phänomen...passt immer erst nach dem zweiten mal drehen:P
thanks
Was zum teufel machst du da? C++ in C# programmieren? Das klappt nicht.
Du scheinst nichtmals zu wissen, das Klassen grundsätzlich referenzartig sind. Dein ref macht absolut keinen Sinn.
Zu deiem Fehler: Guck dir die Signatur von Write an. Du wirst sehen es gibt keine Überladung, die mit jedem Typen arbeitet (sprich object). Generics sind etwas ganz anders, als C++'s templates!
C++ Tempaltes sind mehr oder weniger Textersetzungen; es wird pro Typ eine Version erstellt und wenn das was dabei rauskommt irgendwie Sinn macht kompiliert es. Generics sind anders. Es gibt nur genau ein "BaseTypex" (aus Optimierungsgründen generiert die CLR spezialisierte Varianten für Value-types, aber das ist für die Betrachtung unerheblich). Über tTYPE (verwendest du einen Zufallsgenerator zum Generieren deiner Bezeichner?) ist absolut nichts bekannt. Du kannst damit also genau das machen, was du auch mit object machen kannst (ToString, Equals, GetHashCode). Willst du mehr, kannst du den Typ auf Subtypen bestimmter Interfaces einschränken und/oder bestimmte Konstruktor-Signaturen vorrausetzen (siehe Schlüsselwort where).
Das als minimaler Einstieg in die Grundlagen von C#.
1. write your code with namespaces an so on and let this build to a Type Library, then you will get a dll file from
2. In the solution you add the dll files as "references"
after including you can use it like you want
Windows hat std. mässig eine opc client interface dll (Automation Wrapper).
WEnn du eine c# anwendung schreibst, kannst du diese dll einbinden und dich mit dem realis verbinden... und tags verändern.
beispiel vb.net :
http://www.codeproject.com/KB/XML/OPC_XML-DA_Clients.aspx
Casta schrieb:
Unix-Tom schrieb:
Was intern passiert kann man auch mit VS IMHO ab Pro nachvollziehen da es dort den Source dazu gibt.
Wenn er den aber nicht hat dann ist es auch nicht erlaubt den weiterzugeben.
Wie kann man denn auf die Source zugreifen? Ich kann nur auf die Metadaten einer Assembly zugreifen, aber nicht auf den Quellcode?!
Grüße
Da gibst dann eine Zusatzeinstellungen in VS 2008 wo man die URL zum Source einträgt. Denn lädt er dann bei bedarf nach.
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
Templates (X<A>, X<B>, ...)?
(Ob das sinnvoll ist oder nicht ist wieder eine andere Frage, aber mit den gegebenen Informationen IMO unmöglich einzuschätzen)
