Ganz einfache Gegenfrage: Warum zeichnest du dann nicht einfach beide Spalten selbst? Dann hättest du die selbe Logik dahinter und damit auch das selbe Ergebnis.

Gruß
Roland

Hi,

ich würde Environment.GetFolderPath(..) verwenden. Lass dir mal ausgeben, worauf dein Pfad zeigt.. ich vermute mal stark, dass der falsch ist. Wäre es ein Berechtigungsproblem, so würde er einen anderen Fehler bringen.

Gruß
Roland

Hi,

sollte normalerweise nicht sein. Schon mal versucht, die alle Zellen auch mit den gleichen Einstellungen beim Graphics-Objekt zu zeichen (Antialiasing, Qualitätsstufe, usw.)..
bzw.. du zeichnest alle Zellen selbst, oder?

Gruß
Roland

Hi,

von der Klasse SerialPort gibt es ein Ereignis DataReceived, womit du dann auf das Polling verzichten kannst. Schau dir das mal an.

Ansonsten zur Zeitmessung ist die Stopwatch wohl das Beste, die Auflösung ist mit Sicherheit mehr als ausreichend (Genauigkeit liegt irgendwo über dem Millisekundenbereich). Genaueres müsste hier in der Msdn zu finden sein. Einfach mal peer Google nach Stopwatch suchen und dann die Msdn-Doku kurz durchlesen.

Gruß
Roland

Hi,

ich persönlich bin einer von der Sorte, der seine eigene Protokoll-Bibliothek implementiert, die dann überall gleich verwendet wird. Zusätzlich gibt es auch ein gemeinsames Auswertetool. Grundsätzlich gebe ich aber herbivore recht, die meistens habens entweder selber gemacht oder nutzen von vorne herein eine Fremdbibliothek.

Ein allgemeines Interface und IOC und solche Sachen finde ich persönlich schon fast etwas übertrieben fürs Logging. In meinen Augen sollte Protokollierung in den eigenen Programmen möglichst überall gleich sein, damit die Auswertung der Protokolle auch überall auf den gleichen Weg geschehen kann. Aber gut, hier denkt vermutlich jeder etwas anders.

Gruß
Roland

Hi,

dein BackBuffer bzw. dein RenderTarget ist eine Textur.

Gruß
Roland

Das ist das falsche Fenster. Du musst per Ansicht -> Eigenschaftenfenster das Eigenschaftenfenster öffnen. Wenn du jetzt auf das Setup-Projekt klickst erscheinen dort alle Einstellungsmöglichkeiten des Setups.

.. übrigens ist das das Gleiche Fenster, wie z. B. bei Windows.Forms oder WPF (da, wo du die Eigenschaften von Controls einstellst).

Gruß
Roland

Hi,

Bisher dachte ich immer dass ein .NET Programm nicht so schwerwiegende Auswirkungen haben kann da es quasi in einer virtuellen Umgebung läuft.

Das unterschätzen wohl viele 😉

Natürlich kann man so nicht viel sagen, aber ein paar Denkanstöße im Vorfeld:*Inwieweit wird die Windows-API direkt über DllImports verwendet? *Gibt es andere Schnittstellen zu nicht verwaltetem Code? *Werden nicht verwaltete Objekte korrekt freigegeben (Stichwort: IDisposable) *Baut die Anwendung Speicher auf (Über TaskManager oder ProcessExplorer beobachten)? *Wie hoch ist die Frequenz der empfangenen Nachrichten? *Wie hoch ist die CPU-Auslastung? *Und und und..

Am Ende kann man natürlich auch mit verschiedenen Profiler-Tools nachschauen, was genau in der Anwendung los ist.

Gruß
Roland

Hallo,

wenns um Geschwindigkeit geht, würde ich TCP/IP Socket-Kommunikation empfehlen. Aber: Ist grundsätzlich recht flott, aber dafür hats nicht viel mit WCF oder anderen Standards zu tun.

Gruß
Roland

Hi,

meines Wissens gibts bei DevExpress ein Programm, dass die Verseise in einem Projekt automatisch auf die neueren Dlls stellt. Hast du das eventuell ausgeführt? Oder macht das bei denen das Setup mitlerweile automatisch?

Jedenfalls hatte ich so ein Problem auch schon mal mit einer Desktop-Anwendung beim Update von 7.x auf 8.x... aber da war ich selbst schuld.

Gruß
Roland

Hi,

Die Netzwerkverbindung wurde durch das lokale System getrennt

Sagt ja eigentlich schon, dass das Problem der eigene Rechner ist. Könnte man eigentlich drauf kommen, dass hier die Windows-Firewall dahintersteckt... aber, als ich den Beitrag heute früh gelesen habe, ists mir auch nicht eingefallen..

Gruß
Roland

Hi,

ein paar Vorschläge:*Socket.Receive müsste eine Überladung haben, in der man einen Timeout angeben kann...? So kannst du zum Beispiel immer nach einer bestimmten Zeit prüfen, ob der Thread abgebrochen werden soll *Bei dem Thread das Background-Flag auf true setzen, dann wird er automatisch Beendet, wenn du deine Anwendung schließt *Thread.Abort nicht verwenden, sofern dus wirklich nicht anders hin bekommst

Gruß
Roland

Welches DirectX verwendest du denn?
Ich meine, dass es da bei manchen Bibliotheken schon fertige Methoden wie Texture.SaveBitmap oder Texture.ToBitmap geben müsste.

Zur Not kannst den Bidschrirm auch mit den Funktionen aus dem System.Drawing Namespace in eine Bitmap schreiben. Siehe Graphics.CopyFromScreen.

Gruß
Roland

hm.. dann sollte es kein Problem sein. Ich hab so eine Konstellation auch schon mal gehabt (Dienst startet anderen Dienst) und das hat auch immer auf den verschiedensten Systemen funktioniert. Als Konto hat der Dienst immer das Systemkonto verwendet. Systeme waren meist Windows Server 2003 / Server 2008 und Windows 7.

Da gibts doch das Häckchen "für COM Interop registrieren". Das musst du für Debug und für Release aktivieren.

Gruß
Roland

Hi,

noch ein ganz anderer Vorschlag. Bei den Google-APIs handelt es sich doch um XML-RPC, oder?
Da gibts ne gute Bibliothek für C#: www.xml-rpc.net

Gruß
Roland

Die Schnittstellen von COM-Objekten kann man sich doch irgendwo anzeigen lassen, oder?

-> Wenn man die COM-KLasse als Referenz dem Projekt hinzufügt
-> Mit dem Programm oleview (bei Windows SDK dabei)
-> ...

Ich würde mir die Schnittstelle also erstmal ansehen. Da ich Photoshop nicht habe, kann ich das gerade nicht für dich übernehmen.

Gruß
Roland

Hi,

das Programm. welches Start() aufruft, muss Administratorrechte haben. Unter Windows 7 / Vista also am besten mal mit "Start als Administrator" probieren.

Gruß
Roland

Hi gfoidl,

packe den Datei-Stream in ein using, dann hast du da keine Problem. Beispiel:

using(FileStream outStream = File.OpenWrite(...))
{
    //...
}

Bei der Puffergröße stimme ich exaveal zu. 1 MB ist deutlich zu groß. So ganz nebenbei würde diese Array auch im LargeObjectHeap landen, was zumindest bei mir schonmal zu nem Problem geführt hat. Vorschlang: Ich persönlich nehme immer 1000 Bytes. Hab mich zwar noch nie genau damit auseinandergesetzt, was genau Ideal wäre, aber damit hatte ich noch nie Probleme.

Gruß
Roland

Hi,

eventuell wird ja eine eigene Session-Variable oder sowas zurückgeliefert. Schau dir mal per Fiddler an, was du dem Dienst beim Einloggen sendest und was du zurück bekommst.

Hier findest du den Download:
Fiddler

Gruß
Roland

Ok, dann solltest du mit dem HttpListener dein Ziel erreichen können.

Hi,

hab ich auch so noch nicht gesehen.
Wie hostest du denn den Dienst, selber oder über den IIS?

Nicht, dass da am Coding selbst was nicht ganz passt.

Gruß
Roland

Hola

da ich nach einem gewissen Zeitpunkt Daten wieder an den aufrufenden schicken muss.

Was ist denn ein "gewisser Zeitpunkt"? Die Antwort über Http sollte möglichst sofort zurückgeschickt werden, alles andere ist schlecht. Anerenfalls würdest du auch auf der anderen Seite einen Http-Listener benötigen.

Andere Frage: Warum eigentlich Http bzw. was willst du eigentlich erreichen? Um das Hosten von Webseiten oder Webservices gehts ja vermutlich nicht..

Gruß
Roland

Hi,

warum bentzt du dafür nicht die HttpListener-Klasse?
Msdn - HttpListener

So wie du das machst müsstest du den ankommenden Daten-Stream händisch zerstückeln.

Gruß
Roland

Darf man fragen, warum du da einen komplett eigenen Weg gehen willst?
Für die Sound-Ausgabe kannst du entsprechende Schnittstellen verwenden. Bei DirectX müsste was dabei sein, oder das offene OpenAL.. gibts mit Sicherheit noch mehrere.

Ansonsten müsstest du ja selbst auf die Hardware Ebene gehen oder direkt die Treiber ansprechen - nicht so der gute Weg.

Gruß
Roland

Ein kleiner Tipp:
Anders als bei DirectX ist der Shader-Compiler bei OpenGL nicht Standard, sondern von jedem Grafikkartenhersteller selbst implementiert. Somit kann es auch beim Verhalten des Compilers unterschiede zwischen den Herstellern geben.

Gruß
Roland

Das ist echt ne dumme Sache bei diesen Setups. Was ich da Momentan meistens mache:

Im Realease Build habe alle Projekte einen Ordner als gemeinsames Build-Ziel (sowas wie [SolutionDir]/bin/release/). Im Setup füge ich dann nicht direkt referenzen auf die Projekte, sondern auf die Dlls im oben genannten Release-Ordner hinzu. Damit hat man keine wirklichen Probleme mit dem Exclude. Falls wirklich Abhängikeiten reinkopiert werden, reicht ein einmaliges exclude.

2. Vorteil: Man bekommt bereits einen fertigen Installationsordner mit allen Dlls so wie sie ins Setup kommen ohne dass man das Setup selber installiert. Find ich so zum Testen sehr angenehm.

Gruß
Roland

Da gibts höchstwarscheinlich Probleme mit dem Codec. Avi ist ja schließlich nicht gleich Avi, da sich die Codierung bzw. der verwendete Codec von Datei zu Datei unterscheiden kann.

Hänge dich mal an das MediaFailed Ereignis und schau mal, ob du da mehr Informationen bekommst.

Gruß
Roland

Oder so.. das geht auch.
Beim VisualBrush musst du einen sinnvolle Größe setzen (Width und Height). So wie ich das sehe, ist der bei dir einfach zu klein.

Gruß
Roland

Hi Neidhard,

owei, 25 Paths * 300 Punkte = 7500 Linien.
Kommt ganz schön was für deine Grafikkarte zusammen.

Versuche das am Besten in einen Brush zu packen. Bei WPF gibts ja diese VisualBrush, ...Brush Objekte. Diese sorgen dafür, dass es im Hintergrund einmal auf eine Textur gerendert wird und dann erst wieder, wenn sich wirklich was an den Punkten ändert.

Ich schätze mal, dass bei deiner jetzigen lösung bei jedem Bild alle Punkte/Linien einzeln gerendert werden. Und das ist - je nachdem, welche Grafik-Hardware du hast - schlecht.

Gruß
Roland

Ist denk ich ein guter Weg so, nur bei NamedPipes musst etwas aufpassen. Ich meine, da hatte ich schonmal Probleme, wenn eine Desktop Anwendung mit einem Service über diesen Weg reden will (da gabs was mit Berechtigungen und Windows 7 / Vista / 2008).

Daher habe ich damals dann auf Tcp/IP Kommunikation auf LocalHost umgestellt, sobald die Kommunikation über NamedPipes Probleme macht..
Muss jetzt nicht so stimmen, aber am besten mal ausprobieren.

EMails oder gar SMSsen (gibts ja auch manchmal bei sowas) würde ich eher vermeiden. Da müsstest dann nämlich noch aufpassen, dass du nicht jemanden die Mailbox zumüllst (z. B. Fehler, der alle paar Sekunden ausgelöst wird).

Gruß
Roland

Ich persönlich kann mir nicht vorstellen, dass eine "klassische" Oberfläche komplett entfernt wird. So würde doch die Unterstützung älterer Software flöten gehen... mal ganz abgesehen von all den Windows-Programmen, die ja sinnvollerweise auf Fenster ausgelegt sind.

Unabhängig davon finde ich den Ansatz schon sehr interessant. Bin gespannt, wie sich das am PC anfühlt. Für viele Benutzer ist das in meinen Augen sehr sinnvoll, da die meisten eh nur ein paar Standardprogramme zum Surfen, Videos Schauen oder Chatten verwenden.

Gruß
Roland

Hallo Ichthys,

beides gleichzeitig einbinden geht nicht. Grund: Wenn dein Prozess als 32-Bit läuft, kannst du auch nur 32-Bit Dlls laden. Genauso bei 64-Bit..

Was du aber machen kannst: Beide Dlls zu deinem Projekt hinzufügen und diejenige dynamisch laden, die für deinen Prozess gerade die richtige ist.

Gruß
Roland

Hallo KrümelKuchen,

schau dir mal das da an:
http://jint.codeplex.com/

Es handelt sich dabei um einen JavaScript Interpreter für .Net. Läuft zwar nicht auf Basis der Dlr, dafür macht das Projekt einen ausgereiften Eindruck.

Gruß
Roland

Hallo zusammen,

ganz kurz: where (C#-Referenz)

schau dir mal das Thema "Generika" genauer an, damit hängt das zusammen.

Gruß
Roland

Komische Sache..

wenn ich jetzt einmal laut denke.. Wies aussieht, will dieses Excel-Interop zeugs irgendwas mit dem aktuellen Gui-Thread machen. Theoretisch könnte man mal per Application.AddMessageFilter(...) schauen, ob während der Zeit, in der auf Excel-Interop zugegriffen wird, irgendwelche Nachrichten ankommen. Falls dem so wäre, könnte man einfach in dem Worker-Thread eine neue Applications-Nachrichtenschleife starten, per Application.Run oder sowas.

Gruß
Roland

Hallo Sebastian,

ich bin mir nicht ganz sicher, aber eventuell hat es etwas mit dem thread-apartment zu tun. Der Gui-Thread läuft ja i. d. R. als STAThread. Der Hintergrund-Thread vom BackgroundWorker müsste ein MTAThread sein.

Versuche mal selbst einen Thread anzustarten, der mit STAThread markiert ist und messe da die Zeit.

Gruß
Roland

Hallo MrSparkle,

Hier ein kleiner Thread: .NET 3.5 runtime and .NET 4 runtime compatibility

Damit man dein Plugin nutzen kann, müsstest du wohl das Hauptprogramm unter .Net 4 starten.. zwar auch nicht die Ideallösung, aber .Net 4 würdest du ja sowieso benötigen.

Gruß
Roland

Hallo MarsStein,

gefällt mir, werden diese Registry-Keys grundsätzlich für alle COM-Objekte eingetragen und klappt das auf jeder Windows-Version?

.. in der zwischenzeit hab ichs so gelöst (die Prüfung dauert zwar so länger, aber man kann Sichergehen, dass das Control auch verwendet werden kann):

/// <summary>
/// Is Adobe Reader correctly installed?
/// </summary>
public static bool IsActiveXInstalled()
{
    try
    {
        //Try to create the ActiveX-Control
        AdobeReaderControl readerControl = new AdobeReaderControl();
        readerControl.Size = new Size(500, 500);
        readerControl.CreateControl();
        readerControl.Dispose();

        return true;
    }
    catch (Exception)
    {
        return false;
    }
}

Gruß
Roland

Hallo Kollegen,

ich habe in Windows.Forms ein Steuerelement, welches den Adobe-Reader anzeigt. Implementiert habe ich das über die AxHost-Klasse:

/// <summary>
/// .NET Wrapper für Adobe Reader ActiveX-Steuerelement
/// </summary>
public class AdobeReaderControl : AxHost
{
    ...

    /// <summary>
    /// Hostet das Adobe Reader ActiveX-Steuerelement in Windows.Forms.
    /// </summary>
    public AdobeReaderControl()
        : base("{CA8A9780-280D-11CF-A24D-444553540000}")

Funktioniert soweit auch super. Die Frage ist jetzt, wie kann ich vorher abprüfen, ob die Klasse auch wirklich existiert bzw. am Rechner installiert ist?

Gruß
Roland

Hi unikate24,

du meinst System.Windows.Controls.Image, oder?
Bei der Klasse musst du aufpassen, es handelt sich nämlich nicht direkt um ein Bild, sondern um ein Control, welches ein Bild anzeigt.

Stellt ein Steuerelement dar, das ein Bild anzeigt.

Stammt von der Image-Klasse

Das Bild selbst stammt zum Beispiel von einem BitmapSource Objekt, wofür es dann wieder zahlreiche Möglichkeiten gibt (schau mal auf Msdn, was alles von BitmapSource oder von ImageSource erbt..). Wenn du Metadaten rausholen willst, musst du hier nachschauen.

Und nochmal Achtung: System.Drawing.Image ist was anderes. Dabei handelt es sich um ein Bild, allerdings ist da im Hintergrund Gdi (alte Grafik-API von Windows). Die Klassen innerhalb von System.Drawing werden typischerweise in Windows.Forms Anwendungen verwendet. Die WPF-Klassen, von denen du schreibst, benutzen nicht Gdi.

Gruß
Roland

Hallo Grumbler85,

meinst du die MessageQueue Klasse von C# oder die Technologie im allgemeinen?
Falls du die Klasse meinst, finden sich da viele gute Artikel:

Msdn (Beschreibung der Klasse)
Msdn (Artikel zu dem Thema)

Gruß
Roland

Hallo Marcel064,

da sprichst du ein gute Thema an. In .Net muss du aktuell gut aufpassen, welchen Timer du für was verwendest. Spontan fallen mir zum Beispiel drei Stück ein, die mir immer wieder über den Weg laufen:

System.Threading.Timer
System.Windows.Forms.Timer
System.Windows.Threading.DispatcherTimer
System.Timers.Timer

Würd mich jetzt nicht überraschen, wenns noch mehr gibt.
Wichtig zu wissen ist, dass jeder zwar im Prinzip zyklisch eine Funktion aufruft, aber dennoch macht das jeder etwas anders.

Am Ende des Artikels Comparing the Timer Classes in the .NET Framework Class Library findet man eine kleine Übersicht über drei davon, was genau der Unterschied ist. Ich vermute auch stark, dass es hier im Forum mehrere Threads zu dem Thema gibt.

Unterm Strich: Wenn du dich unsicher bist, welchen man verwenden soll, dann besser nachfragen oder genau nachschauen.

Gruß
Roland

Hall PoWI,

nutze mal die Suche bzw. Google. Zu dem Thema gibt es jede Menge Resourcen.
Eins vorweg: Compilierst du als AnyCPU, so kann der JIT-Compiler selbst entscheiden, obs als 32- oder als 64-Bit Anwendung läuft. Diese "'Freiheit" kannst und musst du in manchen Fällen auch übersteuern.

Gruß
Roland

Hi Tarion,

den Überlauf kriegt man nicht direkt mit, das ist richtig. Natürlich könnte man da etwas tricksen, aber ich denke, dass es für den Fall dann doch bessere Alternativen gibt. Die Frage ist, ob eine Laufzeit von 29,4 Tagen für dein Programm realistisch ist? Bei mir war es so, weil es sich um eine Dienstanwendung handelt, die idealerweise ewig durchläuft.

Mal ganz dumm gedacht: Wenn es nur darum geht, dass irgendein Timer immer nach oben geht, kann man ja auch einfach eine Stopwatch oder sowas am Anfang des Programms starten und dann einfach laufen lasst. Einen Überlauf oder ähnliches wird es da so schnell nicht geben. Und schlechter als mit Environment.TickCount bist du auch nicht.

Gruß
Roland

Hallo Kollegen,

mein Desktop mit dem Bild, dass ich jetzt warscheinlich schon seit 5 oder 6 Jahren drin hab ^^

PS: Die Verknüpfungen habe ich unten rechts in der Symbolleiste versteckt.

Gruß
Roland

Hallo Sebastian,

genau von sowas gehe ich aus, denn deswegen habe ich oben gefragt, was genau da innerhalb von DoWork gemacht wird. Wenn jedemenge Invokes aufgerufen werden ist es klar, dass der Backgroundworker länger braucht. In diesem Fall kann man sich auf so wenige Invokes wie möglich beschränken, um die Performance zu steigern. Eventuell kann man auch BeginInvoke verwenden, da hier der Worker-Thread nicht wartet, bis die Gui aktualisiert ist, allerdings muss man aufpassen, dass man die Gui nicht zuballert.

Gruß
Roland

Hi mono,

ich könnte dir zur Umwandlung zwei Möglichkeiten vorschlagen:

1. du nutzt BitConverter..

BitConverter.ToInt16(...);

2. du rechnest einfach selber..

short myValues = byte1 * 256 + byte2;

In beiden Fällen gilt: Endianness beachten! Siehe Wikipedia (Bei erster Variante gilt auf X86-Prozessoren LittleEndian).

Die Zeichen, die von ReadLine verwendet werden, kannst du mit dieser Eigenschaft abfragen:

Environment.NewLine

Müsste CR und LF entsprechen, sicherheitshalber würde ich da aber nochmal nachschauen. Empfehlen würde ich dir bei solchen Geschichten aber nicht ReadLine zu verwenden, sondern die Bytes einzeln zu lesen und selber auf das Ende abprüfen.

Gruß
Roland