Du kannst per Format-String bestimmen, wie die Ausgabe aussehen soll.
Mit

Console.WriteLine("{0:000.0E+000}", 3.14159265);

bekommst du

314,2E-002

als Ausgabe.

Grüße,
Georg

Wie bereits gesagt ist es kein TextFrame sondern ein PictureFrame. Entsprechend casten und du kannst das Bild über das Picture Property setzen.

Bilder werden in einem "APIC"-Frame gespeichert. Ist ein solcher in deiner MP3-Datei vorhanden?

Für den Windows Installer gibt es auch eine öffentliche API, siehe Windows Installer Reference.

Versuche es einmal mit den Enumerate* Methoden der Directory Klasse(ab .net 4.0). Das sollte vor allem bei vielen Dateien mehr Performance bringen.

Sowohl System.IO.Compression.* als auch dein Link basieren auf dem Deflate-Algorithmus.
Da würde mir spontan zlib als "Referenzimplemtierung" einfallen.

Du hast vermutlich auch den Device-Treiber in Verwendung. Ob das Auslesen aller VIDs&PIDs mit dem Device-Treiber funktioniert kann ich nicht sagen, bezweifle es aber.
Nur setzt der Device-Treiber eben ein eigenes USB-Device voraus, um installiert werden zu können. Da buzz_lightzyear nichts von einem eigenen Device schreibt, gehe ich davon aus, dass buzz_lightzyear den Filter-Treiber verwenden muss.

ist zwar nicht über WMI, jedoch ein einfacher Weg, der leicht implementierbar ist:
>

Meines Wissens nach brauchst die SharpUSBLib zum AUslesen aller VIDs&PIDs einen installierten libusb Filter-Treiber. Von dessen produktiven Einsatz rät die libusb Seite ab.

Für welche Geräteklasse willst du die VID & PID auslesen?

USBView z.B., sendet eigene Control-Transfers, über den Host-Controller-Treiber an die angeschlossenen USB-Devices, um an die Deskriptoren zu kommen. Die Sourcen findest du im aktuellen WDK.

Du könntest auch versuchen statt raw Ethernet Paketen UDP Pakete zu verschicken und somit auf WinPcap verzichten. Dafür ist der TCP/IP Stack ausgelegt und ich könnte mir gut vorstellen, dass sich der Datendurchsatz erhöht.
IP & UDP kannst du ja relativ statisch in deinem Ethernet Frame unterbringen, dies sollte auch mit einem FPGA noch relativ einfach realisierbar sein.

Ohne einen Puffer auf der FPGA Seite - und BRAM wird hier nicht reichen - wirst du immer wieder Pakete verlieren, sei es durch Übertragungsfehler oder weil WinPCap die Daten nicht schnell genug speichern kann.

Hast du auf der FPGA-Seite einen Puffer für die Daten?
Ich habe bisher zwar noch nie Ethernet für soetwas verwendet, jedoch habe ich bei anderen Bussystemen, wie USB und PCIe immer einen Puffer von ~100ms gebraucht um keine Daten zu verlieren.
Falls dass nicht hilft, kannst du ja mit einer anderen Anwendung Daten erzeugen und rausfinden, ob die Netzwerkkarte, WinPCap oder deine Anwendung der Flaschenhals ist.
Warum tut ihr euch den Aufwand mit Ethernet überhaupt an? bei ~240MBit/s reicht doch auch USB.

Grüße

Der FTDI unterstützt leider keine hardwareseitigen Delays. Allerdings kannst du je nach Protokoll, durch senden von Dummy-Bytes ein Delay erzeugen.

Welchen Mode(MPSSE, BitBang, UART) vom FTDI verwendest du?

Die Namen sowie weitere Eigenschaften kannst du mit Hilfe der SetupAPI rausfinden. Ich würde dir aber trotzdem raten, die ganzen USB<->Seriel Wandler nicht mehr zu verwenden, sondern einen eigen µC mit USB. Dies bedeutet zwar am Anfang Mehraufwand, zahlt sich aber bald aus.

Stichwort Closure.
Siehe [Artikel] Delegaten, anonyme Methoden, Lambda-Ausdrücke & Co.

Doch es sind Binärdateien. Huffman, Deflate arbeiten mit Binärdateien und nicht mit Strings.
Ich würde hier weder SortedList, noch Dictionary verwenden, sondern ein simples Array mit 256 Elementen. Für jedes Byte ein Element.
Die Datei komplett einzulesen funktioniert nur bei kleinen Dateien, bei größeren Dateien bekommst du ein Problem.
Verwende einen FileStream und ließ die Daten Blockweise, mit einer Blockgröße von z.B.: 64KB, ein. Dann läufst du mit einer for-Schleife über den Block und berechnest die Häufigkeiten.

Evtl. ist ein bool-Array der Größe 10.000.001, bei der der Wert als Index verwendet wird und der bool Wert angibt, ob der Wert in der Liste enthalten ist, noch ein bisschen schneller.

Für so etwas würde ich her die BitArray-Klasse verwenden.

Bei mir hat Eclipse in einer Endlosschleife immer weiter verschachtelte Ordner angelegt. Wenn ich versucht habe das über den Explorer zu löschen kam eine ähnliche Fehlermeldung.

Seit Vista oder W7 unterstützt auch der Windows Explorer lange Dateipfade. Spät aber doch...

Das geht schon, nur unterstützt es das .Net Framework nicht. Du musst "\?&quot; an den Pfad voranstellen, dann kann der Pfad bis zu 32K Unicode Zeichen enthalten.
Es gibt aber sicherlich bereits .Net Komponenten die mit langen Dateipfaden arbeiten können. =>google

Gibt es keine bereits verfügbaren Simulatoren für eure CPU? Je nach Komplexität der Plattform und euren Anforderungen(z.B. Cycle genau) kann so ein Simulator sehr aufwendig werden.
Auch ich würde hier eher nicht C# verwenden, sondern SystemC verwenden.

Schon mal mit [PROPERTY_NAME] im ExeCommand-Attribut versucht.
Also z.B.:

ExeCommand="-File [INSTALLDIR]"

sicher könnte man den Installationspfad "von Hand" in die Registry schreiben, aber ich denke gerade für den Installationspfad sollte es bei den normalen Setup-Generatoren eine automatische/standardmäßige Unterstützung geben...

Es gibt das ARPINSTALLLOCATION Property um den Pfad zu speichern und automatisch zu setzen. Allerdings wird dieses zumindest von VS2005 nicht verwendet. Abgesehen davon, hat dieses Property bei einigen älteren Windwos Installer Versionen bei mir nicht zuverlässig funktioniert.

Hab jetzt so ziemlich alle möglichkeiten aus der Command-Line MSDN ausprobiert ...

=>TARGETDIR=C:\Foo

1. Während der Installation den Installationspfad in die Registry zu schreiben und bei einem Update von dort wieder auszulesen ist die einfachste Möglichkeit.

2. Du kannst Properites, und somit auch den Installationspfad, über die Kommandozeile ändern. Siehe Windows-Installer: Command-Line Options

Hi,

Grundsätzlich kannst du eine Scriptsprache deiner Wahl (Ruby bzw. Phyton sind gerade in) nehmen und diese durch eigene Module (Scriptcode sowie externe DLLs) erweitern. Dies hat den Vorteil, dass du bereits bestehende Entwicklungsumgebungen für die Scriptsprache nutzen kannst. Der Nachteil dieser Lösung ist, wenn du mehr als nur Skripte ausführen willst. Z.B. Spezielles User-Interface, etc.

Die andere Möglichkeit wäre die Scriptsprache in dein Programm zu integrieren. Hier würde sich z.B. die DLR mit IronRuby/IronPhyton anbieten. Dadurch bist du flexibler was die GUI und die weitere Funktionalität deines Programmes betrifft, musst allerdings Dinge wie IntelliSense, Debugger u. ä. selber entwickeln.

Ich setzte IronPhyton und IronRuby bereits in einigen meiner Projekte ein. Die Integration und Erweiterung durch eigenen Methoden bzw. Klassen geht sehr leicht. Dafür fehlt es der DLR noch an einigen Features wie Debugging, Abbrechen von Skripten und Fehlerbehandlung.

Grüße

Du kannst statt dem IntPtr auch ein byte-Array mit OutAttribute verwenden. Macht die Sache doch wesentlich einfacher...

[DllImport("deineDLL")]
private static extern short FC_GetImage([Out] byte[] pImage, short xImage, short yImage, IntPtr pImageInfo);

Rückgabewert schon mal ausgewertet?

Z.B. das VersionNT-Property.

Für so etwas gibt es LaunchConditions.

Hast du bereits ein MC-Board auf dem das .Net Micro Framework läuft, oder verwendest du nur den Simulator?

Hallo,
ich kompiliere alle meine Anwendungen gegen das .Net 2.0 FW. Das hat den Vorteil, dass es auf den meisten Systemen bereits installiert ist(Ab Vista mit dem Betriebssystem ausgeliefert), und auch noch auf älteren Systemen (Win2K) installiert werden kann. Zusätzlich gebe in der App.config mittels SupportedRuntime-Element an, dass meine Anwendung auch mit dem .Net 4.0 FW funktionieren.
Somit sollte nur in den wenigsten Fällen die Installation vom .Net FW nötig sein.
Im Installer kannst du mit MsiNetAssemblySupport prüfen, ob das entsprechende .Net FW installiert ist und gegebenenfalls nachinstallieren.

=> Dynamic Language Runtime, IronPython, IronRuby, ...

@wcseller
Vielen Dank, das werde ich mal ausprobieren.

@chilic
So etwas ähnliches habe ich bisher in Verwendung. Sieht nur alles andere als professionell aus...

@herbivore
Ich denke auch, dass es da was geben müsste. Nur die meisten Beispiele die ich bisher gefunden habe, machen es so, wie von chilic vorgeschlagen.

Hallo,

ich bin auf der Suche nach einem TextBox-Control, welches zusätzlich Buttons mit Bildern anzeigen kann. Ähnlich der Suchleiste in Firefox (siehe Anhang).
Kennt jemand von euch ein solches frei verfügbares Control?

Grüße,
Georg

Die zwei Backslashs zeigt nur der Debugger an. Diese sind nicht wirklich im String vorhanden.

Einfacher ist es natürlich mit LINQ (wie marsgk) dir beschrieben hat.
Aber einfacher zu verstehen ist wohl die Variante mit der for-schleife 😃

List<T>.RemoveAll hat nichts mit LINQ zu tun. RemoveAll ist eine normale Methode der List<T> Klasse.

Ich persönlich finde den Einzeiler RemoveAll wesentlich sprechender, als eine for-Schleife.

Schon mal in die Doku geschaut?
=>List<T>.RemoveAll

So ein ähnliches Problem hatte ich auch mal. Windows hat einen Icon Cache, und verwendet vermutlich ein falsches/kein Icon für deine App.
Such mal im Internet wie man den Cache löscht.

@MarsStein
Die DLL exportiert ja die Funktion. Nur leider als C++ und nicht als C Funktion, daher auch das Name Mangling.
@SkySurfer
Verwende als CallingConvention cdecl statt stdcall

Hallo,

ich würde an deiner Stelle eine Windows-Message an alle relevanten Prozesse schicken.
Siehe SendMessage, RegisterWindowMessage oder auch WM_COPYDATA.

Warum setzt du für dein Vorhaben nicht einfach die DLR mit IronRuby oder IronPython ein?

Das heisst, du machst den erhöten aufwand um dann doch nur wieder einen Threadpoolthread zu bekommen?

Erhöhter Aufwand? Ich finde z.B. das von mir gepostete Beispiel einfacher, als einen eigenen Thread zu erzeugen oder Backgroundworker zu nehmen.

Naja, irgendwo muss ja der callback ja auch ausgeführt werden. Der Vorteil ist eben dass der Threadpool-Thread sofort wieder frei wird und andere Anfragen abarbeiten kann, während bei synchroner Ausführung der Thread blockiert.

Aber wie ich bereits Herbivore geschrieben habe, sollte man nicht dogmatisch immer ein Muster anwenden, sondern sich je nach Anwendungsfall für das beste Muster entscheiden.

Zum einen kann es sein, dass nicht die einzelne Methode langlaufend ist, sondern erst das Zusammenspiel vieler Methoden oder der Aufruf einer Methode in einer Schleife. Dann nützt einem das Muster nichts.

Doch natürlich, ich kann im Callback ja weitere Aktionen anstoßen.

Zum zweiten könnte es sein, dass man mehrere (asynchrone) Methoden hintereinander ausführen möchte. Dann bekommt man eine Art (End-)Rekursion (also aus dem Callback die nächste Methode aufrufen, die wieder einen Callback aufruf, ...) und bekommt damit möglicherweise einen StackOverflow.

Der callback wird normalerweise in einem anderen Thread ausgeführt, so dass es nicht zu einem StackOverflow kommt.

Zum dritten müsste man bei jeder weiteren Klasse mit langlaufenden Operationen das Muster immer wieder neu implementieren. Sobald der Verwender auch nur auf eine Klasse stößt, die das Muster nicht implementiert, muss er sich eh selber um das Threading kümmern.

Leider gibt es in der Informatik kein Muster mit dem man alles abdecken kann. Allerdings bieten alle wichtigen .Net Klassen dieses Muster an, so dass viele wichtige Operationen abgedeckt sind.

Aus all diesen Gründen, finde ich das Muster zu kompliziert, zu spezifisch, zu unflexibel und zu unpraktikabel. Ich rate vom Einsatz des Musters dringend ab.

Kompliziert vielleicht, allerdings ist das Thema Multithreading - egal wie man es löst - nicht einfach.
Unflexibel und Unpraktisch sicher nicht. Ganz im Gegenteil! Dieses Muster ist viel flexibler als alles in einem eigenen Thread laufen lassen.

Es gibt Anwendungen, in denen das asynchrone Muster einfacher zu implementieren ist und bessere Leistung ermöglicht. Ebenso gibt es wiederum Anwendungsfälle, bei denen ein eigener Thread die bessere Lösung ist.
Als guter Programmierer muss man halt abwegen, welches Muster ich einsetze. Hier einfach eine Möglichkeit auszuschließen, halte ich für falsch.

Hallo Herbivore,

Sofern bei der asynchronen Variante I/O Completion Ports verwendet werden, hat kleines_eichhoernchen sehr wohl Recht.
Beid er synchronen Variante ist der (ThreadPool-)Thread blockiert bis die I/O-Operation abgeschlossen ist.
Bei der asynchronen Variante hingegen kehrt der Thread sofort wieder zurück und kann wieder andere I/O-Operationen abarbeiten. Sobald die I/O-Operation fertig ist, wird der Callback in einem ThreadPool Thread ausgeführt. Dadurch ist eine bessere Auslastung der Threads möglich.

Irgendwie drehen wir uns hier im Kreis.
Wenn du mit Callbacks arbeitest, benötigst du keine Asynchrone herangehensweise ( wie sie oben beschrieben ist) , sondern du kannst ganz normal mit Threads oder dem BGW arbeiten.

Ich rede hier von callbacks im Sinne von AsyncCallback. Und für diese braucht man nun mal asynchrone Methoden. Aber vielleicht kannst du ja erklären was du unter callbacks versteht.

@ErfinderDesRades
Dein Beispiel ist aber sehr an den Haaren herbeigezogen. Hier eine einfache Implementierung mit async IO. Was soll daran verkorkst oder kompliziert sein. Abgesehen davon funktioniert diese Lösung auch in multithreaded Anwendungen ohne GUI.

private TcpListener listener;

public Form1() {
    ...
    listener.BeginAcceptTcpClient(OnClientConnected, null);
}

private void OnClientConnected(IAsyncResult ar) {
    TcpClient client = listener.EndAcceptTcpClient(ar);

    Invoke(...);
}

Doch habe ich. Ich habe mich auf

und wann ruft man die End-Methode auf? Das ist doch das Problem. Ruft man sie sofort auf, kann man sich den Aufwand sparen, weil man dann wieder synchron arbeitet. Und wenn man sie nicht sofort aufruft, wann dann? Woher weiß man, dass die asynchrone Verarbeitung beendet ist?

bezogen.

Wenn du sowieso mit einem Callback arbeitest, brauchst du keine Asynchronen Methoden.

Ich würde eher sagen: damit ich mit einem Callback arbeiten kann brauche ich asynchrone Methoden

Hallo herbivore,

typischerweise ruft man die EndXXX Methode im Callback, dem man der BeginXXX übergibt, auf.
Denn das ist ja genau das, was man will: Wenn die Operation zu Ende ist, führe Code - wie nächste Operation starten, oder Label in der GUI aktualisieren aus.
Und dieses Pattern lässt sich leicht und effizient mit Callbacks lösen.

Wenn der C++ Sourcecode vorhanden ist, dann würde ich nicht den Umweg über pinvoke gehen, sondern mit C++/CLI eine .Net Assembly erstellen und diese kannst du direkt von C# aus referenzieren.

public String _clname
        {
            get
            {
                return _clname;
            }
        }

Kommst du selbst drauf?