Du schreibst ganz normal die Funktion, welche das enthält was gemacht werden soll.
Verkürztes Beispiel von der Basta 2014:
static void Main()
{
Predicate<int> predicate = (number) => number % 2 == 0;
if(predicate(10))
// do something...
}
Wichtig bei der Funktionalen Programmierung ist nur, dass keine Änderungen an irgendwelchem Zeugs gemacht werden die nicht im Funktionsscope liegen. Auf C# übertragen bedeuted das, dass folgendes ungültig ist:
static bool isEven = false;
static void Main()
{
Action<int> func = (number) => isEven = number % 2 == 0;
func(10);
System.Console.WriteLine(isEven);
}
Da C# jedoch keine rein funktionale Sprache ist, lässt der C# compiler das durchgehen.
Wie man die DLL verwendet ist übrigens sehr schön auf der Seite von Johannes Bildstein beschrieben:
http://www.codeproject.com/Articles/688276/Canon-EDSDK-Tutorial-in-Csharp#Init
doch Office war früher immer bei Windows dabei. Ob es umsonst war weiss ich nicht. Vielleicht war Windows dann schon mal ein Stück teurer. Aber dieses Lizenzmodell mit 1 Jahr und so das gab es bis vor 5 Jahren definitiv noch nicht !
Ich hab mir den von dir verlinkten Artikel schon durchgelesen. Und da ist nix zu finden was Regex.Escape nicht escapen würde. Du bist einfach nur ein arroganter dummer Wixer.
Hallo zusammen,
ich arbeite gerade an einer App, die mit Darten zu tun hat.
Dafuer haette ich gerne eine Moeglichkeit, die Dartscheibe als UI Element anzuzeigen, und die verschiedenen Bereiche in dem Image Klickbar zu machen.
Also z.B. einfach 20, Doppel 19 usw.
Gibt es eine Moeglichkeit, das ganze zu machen, ohne das Bild in x Segmente zu splitten?
Vielen Dank schon mal
Dieser Thread wurde von Moderator/in Shade Of Mine aus dem Forum Webzeugs in das Forum C# und .NET verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
Hallo,
du hast bereits Glück, dass du nicht schon bei Zugriff auf die ListView-Items eine Exception um die Ohren geworfen bekommst. Wie du korrekt festgestellt hast dürfen Control-Zugriffe nur im UI Thread passieren. Auch dass die Schleife durchlaufen wird, ist reines Glück.
Gib eine eigene Liste in den Thread und nicht das ListView.
Uli103 schrieb:
wieso ist denn die Color Klasse nur per get verfügbar?
(...)
Muss ich das verstehen ?
Nein, musst du nicht verstehen.
Es ist so, weil es so ist.
Ich vermute der Grund sind die Coding-Guidelines von MS die sagen dass public fields pfui sind und value types sowieso am besten immutable sein sollten. Beide Regeln machen zwar bei so Sachen wie Color mMn. keinen rechten Sinn, aber naja.
Ich kenne mich mit der PInvoke Syntax von VB.NET nicht aus. Ich kann nur sagen: Grundsätzlich sollte PInvoke diese Funktion packen. Ist ja trivial, ein " Long " Parameter (was auch immer Long in VB ist) und ein Integer Returnwert.
Wie man das für VB.NET schreibt weiss ich allerdings nicht. Sollte sich aber relativ einfach ergoogeln lassen.
Dim szN As String * 17
Das deklariert einen String mit fixer Länge 17. Das geht in VB.NET nicht. Es gibt zwar das Attribut VBFixedString , aber deckt lange nicht alles ab was die VB Deklaration abdeckt.
Siehe http://stackoverflow.com/questions/2305377/how-to-declare-a-fixed-length-string-in-vb-net
Diesbezüglich müsste man also gucken was mit szN alles gemacht wird. Auch das ist generell sicher lösbar, die Frage ist nur wie aufwendig es wird - wie viel man dazu umschreiben muss.
Bei TreeView, gibt es die Möglichkeit mit ShowNodeToolTips = true; Dort
erscheint immer ein Fensterchen rechts unten, mit dem vollständigen Text.
Schön wäre es aber, wenn sich der Text einfach nach rechts fortsetzen würde.
Weiss das jemand ?
Du hast noch nicht abgefangen was passiert wenn der User anstatt einer Zahl etwas anderes eingibt. Am besten mit MyBool = int.TryParse(Input, out MyInt) versuchen. Dann wird keine Exception geworfen.
BTW, weils mir gerade wieder einfällt...
Ein reales Beispiel für was passiert wenn man Dinge nicht deterministisch freigibt.
Die Klasse System.Windows.Interop.D3DImage verwendet intern Objekte vom Typ System.Windows.Interop.InteropBitmap (bzw. davon abgeleitete).
Jedes mal wenn man D3DImage.SetBackBuffer mit einem anderen BackBuffer aufruft erzeugt D3DImage ein neues Objekt das von InteropBitmap abgeleitet ist.
Diese Objekte halten unmanaged Resourcen - ich glaube mich zu erinnern dass es um file mappings geht (Shared Memory halt).
D3DImage gibt diese InteropBitmap Objekte aber nie frei. (EDIT: Also "unreachable" werden die natürlich, aber D3DImage räumt sie eben nicht deterministisch ala IDisposable auf. /EDIT) Und es gibt auch sonst keine Klasse im ganzen WPF Framework die sich darum kümmern würde die InteropBitmap Objekte so bald wie möglich freizugeben.
Der Effekt: wenn man oft D3DImage.SetBackBuffer aufruft, weil man halt blöderweise muss (z.B. weil sich das Format oft ändert, oder weil der User dauernd Fenster wo ein D3DImage drinnen ist auf und zu macht), dann kackt das Programm irgendwann einfach ab. Fliegt ne Exception irgendwo in den Eingeweiden von WPF - gefangen bekommt man die nicht (weil WPF-interner Thread) und man könnte sie sowieso nicht sinnvoll behandeln. Bzw. davor wird es erstmal noch gröbstens langsam - so schlimm dass die ganze GUI einfriert und quasi unverwendbar wird.
Einziger Workaround der mir eingefallen ist: Nach allen 2-3 D3DImage die man erzeugt bzw. allen 2-3 SetBackBuffer Aufrufen ein GC.Collect ausführen.
Ich will damit nur verdeutlichen: Dispose-Disziplin ist keine unnötige Fleissaufgabe - es können in der Praxis wirklich böse Dinge passieren wenn man da schludert.
EDIT: Oops, zu früh Absenden gedrückt. Jetzt sollte es passen.
PCMan schrieb:
Frage ich mal andersherum: Wenn ein erfahrener Enwtickler die Sache angehen würde, schreibt der dann ganz spezifische Lösungen nur für diesen einen Fall? Oder entwickelt er etwas generisches, z.B. eine Steuerung, die sowohl den Aquariumfutterautomaten als auch den Rasensprenger bedienen kann?
Das hängt massiv vom Unternehmen ab, wo man arbeitet. Optimalerweise arbeitest Du in einem an eine Hochschule angeschlossenen Forschungsinstitut und hast da einen Namen. Und dann machste weder das eine noch das andere.
Im "real life" haste derzeit Chefs über Dir, die zur Zeit entweder SCRUM ums Verrecken oder 80er-Jahre-Stil durchboxen.
Du bist der einzige Programmieraffe, der gelegentlich ein Buch liest; und wirst bald den Ruf haben, zaubern zu können.
KP
So leicht lasse ich mich nicht verunsichern wenn ich mir wo sicher bin. Und wäre ich mir nicht sicher gewesen, hätte es mir auch nicht geschadet nochmal nachzulesen.
