Hallo,

mich wuerde mal interessieren, ob Ihr die Verwendung der Woerter "native" und "unmanaged" synonym verwendet oder ihr hier differenziert. Ich habe folgende Anmerkung im I-Net gefunden:

The phrase native code is used in two contexts. Many people use it as a synonym for unmanaged code: code built with an older tool, or deliberately chosen in Visual C++, that does not run in the runtime, but instead runs natively on the machine. This might be a complete application, or it might be a COM component or DLL that is being called from managed code using COM Interop or PInvoke, two powerful tools that make sure you can use your old code when you move to the new world. I prefer to say .unmanaged code. for this meaning, because it emphasizes that the code does not get the services of the runtime. For example, Code Access Security in managed code prevents code loaded from another server from performing certain destructive actions. If your application calls out to unmanaged code loaded from another server, you won't get that protection.

The other use of the phrase native code is to describe the output of the JIT compiler, the machine code that actually runs in the runtime. It's managed, but it's not IL, it's machine code. As a result, don't just assume that native = unmanaged.

Gruss,
DaMoe

Moin zusammen!

Ich kann auch nur davon abraten. Meine Erfahrungen sind, dass VS2010 recht speicherhungrig ist. Selbst mit 2GB RAM (siehe Empfehlung meines Vorposters) ist das manchmal schon eng. Ich setze VS2010 mit ReSharper ein und selbst bei einer kleinen Solution mit ca. 2 - 4 Projekten, hat sich meine devenv.exe ca. 740MB meines Arbeitspeichers gegoennt. Das ist schon eine Menge.

Gruss,
DaMoe

Alternativ: AES: Keeping your data secure

Hallo Herbivore,

danke fuer die Antwort. Ich habe tatsaechlich mit der Synchronization-Klasse eine Loesung erarbeiten konnen. Allerdings konnte ich mein Problem erst mit der von SynchronizationContext abgeleiteten Klasse WindowsFormsSynchronizationContext-Klasse loesen.
Ich habe nun noch eine weitere Frage. Da ich die umgesetzte Funktionalitaet in einem Framework anbiete, koennen andere Entwickler die von mit angebotene Funktionalitaet ebenfalls in einem eigenen Thread starten. Das hat zur Folge, dass ich nicht den eigentlichen Gui-Thread erhalte. Natuerlich kann ich erzwingen, dass mir ein Sync-Objekt mitgegeben wird, aber nach Moeglichkeit soll dies ohne auskommen. Any idea? Oder uebersehe ich noch etwas?

Ich muss noch hinzufuegen, dass ich selber eine Instanz der WindowsFormsSynchronizationContext Klasse erzeugen musste, die ich an den neuen Thread weitergereicht habe, um dann aus dem neuen Thread einen Callback per Send(...) an den vermeintlichen Gui-Thread durchzufuehren.

Gruss,
DaMoe

Hallo!

Folgende Ausgangssituation ergibt sich bei mir:
Ich besitze einen sogenannten ThreadChangingInvoker, der automatisch erkennt, ob eine MainForm geoeffent ist. Falls ein Aufruf aus einem nebenlaeufigen Thread auftritt, kann anschließend mit dem Invoker aus dem nebenlaeufigen Thread in den Hauptthread gewechselt werden. Ich bediene mich, wie also oft hier im Forum zu sehen, der Funktionalitaet von Application.OpenForms, um die oben beschriebene Funktionalitaet zu realisieren.

Das eigentliche Problem:
Bis jetzt wurde die Funktionalitaet nur aus C# verwendet. Diese ist in einer Komponente eingebettet. Nun aber wird diese Komponente ueber einen C++/CLI Wrapper aus C++ aus angesprochen. Somit greift an dieser Stelle Application.OpenForms nicht, da keine Form in der Collection vorhanden ist.
Ich bin in der Lage mittels System.Diagnostics.Process.GetCurrentProcess() an das MainWindowHandle zu kommen. Leider kann ich weder ueber Form.FromHandle(...) oder NativeWindow.FromHandle(...) an die Form kommen. Das eigentliche Ziel ist es aus einem nebenlaeufigen Thread in den MainThread (Gui-Thread) zu wechseln. Die Ueberlegung ist, dass ich ueber das Hauptfenster an den Gui-Thread und entsprechend benoetigte Informationen komme, was aber nicht unbedigt der Adelsweg sein muss.

Hat jemand einen Loesungsvorschlag?

Gruss,
DaMoe

Hallo!

Die pragmatische Loesung, die mir auf Anhieb einfaellt waere, den Wert in String umwandeln und mit String Operationen arbeiten.

Gruss,
DaMoe

Kannst Du das nicht fueher ausfuehren?

Hallo,

wann rufst Du denn this.LayoutMDI(...) auf? Wenn die Form bereits angezeigt ist oder im OnLoad?

Gruss,
DaMoe

Hallo,

such mal nach dem Stichwort Plugin hier im Forum. Wenn Du richtig entladen moechtest, dann wir das schwieriger und Du musst mit ApplicationDomains arbeiten (momentan weiss ich auch nicht 100%ig ob das selbst da moeglich ist). Ein weiterer Stichpunkt in Richtung Plugin ist MEF sein.

Gruss,
DaMoe

Hallo,

die BasisKlasse System.ComponentModel.Component (davon leitet bspw. Form ab) enhaelt ein protected Property, welches "DesignMode" heisst und einen boolschen Wert zurueckliefert.

Gruss, DaMoe

Hi!

Rechtsklick auf das Projekt-> Unload Project -> Edit xxx.csproj -> schau dir mal die fehlenden Referenzen an.

Sind die Referenzen relativ? Kann es sein, dass Dein Projekt in einem tiefer verschachtelten Projektverzeichnis steckt und deshalb die referenzierten Assemblies nicht gefunden werden?

Gruss, DaMoe

Hallo!

Hast Du mal hier geschaut, was die Fehlermeldung genau bedeutet?

Compiler Error CS0246

Aller Wahrscheinlichkeit nach findet Dein Projekt gewisse referenzierte Dlls nicht. Das erkennst Du ganz gut daran, dass im Projekt unter "Referenzen" entsprechende Dlls mit einem gelben Dreieck versehen sind.\

Gruss, DaMoe

Hallo!

Zum einen versuche bitte, wie in meinem vorherigen Post angemerkt, einmal den ExpandableObjectConverter als Basisklasse zu verwenden. Du verwendest momentan noch den CustomTypeConverter.
Weiterhin solltest Du beachten, dass Deine Klasse wie folgt attributisiert werden muss:

[TypeConverter(typeof(MyTypeDescriptor))]

Gruss, DaMoe

Moin!

Ich kann Schlopp nur beipflichten. Es gibt 3 Timer in C#:

http://mark.michaelis.net/Blog/SystemWindowsFormsTimerVsSystemThreadingTimerVsSystemTimersTimer.aspx

Gruss, DaMoe

Moin!

Das lock-Statement verwendet intern Monitor.
lock ist an dieser Stelle vorzuziehen, weil es am "leichtgewichtigsten" ist.

Gruss, DaMoe

Moin!

Wird der TypeDescriptor richtig angesprochen? Hast Du mal geschaut, ob die Liste richtig sortiert ist? Von welchem TypeDescriptor hast Du abgeleitet? Das PropertyGrid ist da sehr empfindlich. Deshalb leite bitte von **ExpandableObjectConverter **ab und dann ueberschreibe die Methode.
Sollte das nicht funktionieren, wuerde ich in das .NET Framework debuggen. Ich habe das Verhalten des Grid ebenfalls so beobachtet (natuerlich auch den Reflector zur Hilfe genommen).

Gruss, DaMoe

Hallo Mighty,

ich habe nur eine Vermutung, weil ich vor einiger Zeit auch ein Sortierproblem hatte. Ich meine, dass das PropertyGrid intern mit einer PropertyDescriptorCollection arbeitet, die die zu visualisierenden Properties enthaelt. Ist diese Liste nicht richtig sortiert, dann wir das standard Sortierverhalten verwendet. Aus welchem Grund auch immer muss eine existierende Instanz der PropertyDescriptorCollection ueber die Sort-Methode mittels eines Arrays, welches die zu sortierenden Properties in bereits sortierter Reihenfolge enthaelt, sortiert werden also:

string[] sortedNames = new string[5];
sortedNames[0] = "b";
sortedNames[1] = "x";
sortedNames[2] = "d";

PropertyDescriptorCollection collection = new PropertyDescriptorCollection(...);
collection.Sort(sortedNames);

Die Descriptoren Liste habe ich dann aus der Methode

public override PropertyDescriptorCollection GetProperties(ITypeDescriptorContext context, object value, Attribute[] originalAttributes)

ueber einen TypeConverter zuruckgegeben.

Gruss, DaMoe

internal static System.Drawing.Bitmap NationalFlag {

Schau mal in Dein Outputverzeichnis. Kann es sein, dass Deine Datenbank in Debug\DatabaseData liegt und deshalb nicht gefunden werden kann?

Gruss, DaMoe

public class Facade
{
       private Dictionary<Type, object> myHandlers = new Dictionary<Type, object>();

       #region Constructor

       public Facade()
       {
               this.myHandlers.Add(typeof(Handler<B>), new Handler<B>());
               this.myHandlers.Add(typeof(Handler<C>), new Handler<C>());
       }

       #endregion


       private Handler<T> GetHandler<T>(T obj) 
       where T : A 
       {
              if(this.myHandlers.Contains(typeof(Handler<T>))
              {
                     return (Handler<T>)this.myHandlers[typeof(Handler<T>)]
              }

              return null;
        }

        public void Add<T>(T obj) where T : A
        {
            GetHandler(obj).Add(obj);
        }
    }

Hier musst Du nur bei GetHandler noch aufpassen, dass Du nicht null zurueckgeliefert bekommst, weil sonst die Methode Add eine Exception wirft.

Gruss, DaMoe

P.S.: Code ist ungetestet

Hi!

Ich sehe hier mehrere Moeglichkeiten, Dein Problem zu loesen:

private Handler<?> GetHandler<T>(T obj)

kann wie folgt aussehen:

private Handler<T> GetHandler<T>(T obj)

oder

private Handler<A> GetHandler(A obj).

Wenn Du mehrere Handler hast und mehrere If-Anweisungen vermeiden moechtest, dann verwende intern doch ein Dictionary, das als Schluessel den Handlertypen fuert und als Value die Handler-Instanz also:

Dictionary<Type, Handler<A>>
Koennte sein, dass Du da mit dem Casting von bspw. Handler<A> nach Handler<B> Probleme bekommst, somit kannst Du entweder das Dictionary wie folgt schreiben:

Dictionary<Type, object>

oder Du hast ein nicht generische Interface oder nicht-generische Klasse, sodass Du sagen kannst

Dictionary<Type, IHandler> bzw. Dictionary<Type, Handler>

Gruss, DaMoe

Hi mydani,

vielleicht bringt Dich die Klasse BindingSource weiter. Einfach eine Instanz erzeugen, Dein IEnumerable Objekt auf das Property DataSource setzen und wie folgt an Dein Control binden:

var bindingSource = new BindingSource();
bindingSource.DataSource = new Ast();
var textBox = new TextBox();
textBox.DataBindings.Add("Text", bindingSource, "name");

Mit Hilfe von BindingSource hast Du auf jeden Fall die Moeglichkeit, sollte der Standardalgorithmus nicht das gewuenschte Verhalten liefern (d.h. das Property aus der DataSource zu ziehen und nicht aus der in der Liste befindlichen Objekten), von der Klasse abzuleiten und GetItemProperties(...) zu ueberschreiben. GetItemProperties liefert eine Liste von PropertyDescriptoren zurueck. An dieser Stelle muesstest Du einschreiten und einen eigenen Descriptor zurueckliefern, der das Property aus der eigentlichen DataSource, also Ast, beschreibt.
Ein Tipp am Rande, es ist empfehlenswert nicht direkt Member Variablen nach aussen freizugeben, sondern Properties.

Gruss, DaMoe

Hi!

Ich habe zwar keine konkreten Preise gesehen, aber schau mal vielleicht hier:
http://www.microsoft.com/visualstudio/en-us/default.mspx

Gruss, DaMoe

Hi!

Klassen sollten mit dem Attribut [Serializable] markiert sein, damit man diese serialisieren kann.

Gruss, DaMoe

Hallo,

ich kann nur mutmassen, dass bei Dir eine Exception aufkommt, die an einer Stelle auftritt, die Du nicht beachtet hast. Sicherlich waere es sinnvoll, wenn Du ein wenig Code zeigt, wie Du die Fehlerbehandlung durchfuehrst.
Bist Du Dir sicher, dass der hervorgerufene Fehler wirklich auch dort auftritt, wo Du ihn erwartest? Hast Du versucht Dich mal an die installierte Version mittels Debugger zu haengen?

Gruss, DaMoe

Hallo zusammen,

wie der Titel schon andeutet, moechte ich die Pseudo-Lokalisierung von .Net Assemblies automatisieren. Was heisst das konkret? Ich suche eigentlich nach einem freien Tool, welches einfach zu handhaben ist und bspw. zu saemtlichen in einer Solution befindlichen Projekte eine Satelliten Assembly mit PseudoText erstellt. Ich habe mir einiges angeschaut und weiss, dass es kommerzielle Tool gibt wie z.B. Sizulizer und Co, allerdings benoetigt ein Entwickler nicht gleich eine ganze Uebersetzungs-Suite. Es genuegt, wenn ein Entwickler eben Pseudo Satelliten Assemblies erzeugt, seine Applikation startet und schauen kann, ob alles lokalisiert ist. Mir sind ResGen, AL und ResourceEditoren (von MS oder Lutz Roeder bekannt)bekannt, allerdings sind es alles nur einzelne Glieder, die erst zu einer Kette verbunden werden muessen. Ich habe auch Source Code um mir PseudoText-resx Dateien zu erstellen. Bevor ich aber das Rad neu erfinde, wollte ich Euch fragen, ob ihr ein bereits existierendes, freies Tool kennt (sei es Standalone oder als Addin fuer das VS), welche diese Aufgabe bewaeltigen kann?

Gruss, DaMoe

Hi SCRJ!

Wenn Du mal in der MSDN schaust, dann wird dort gesagt:

The MeasureString method is designed for** use with individual strings and includes a small amount of extra space before and after the string **to allow for overhanging glyphs...

Lies Dir mal die Remarks durch, vielleicht koennen sie Dir weiter bei der Loesung Deines Problems helfen:

http://msdn.microsoft.com/en-us/library/6xe5hazb.aspx

Gruss, DaMoe

Hallo torti!

da ich immer wieder die selben objekte übergeben muss (tw. bis zu 20 und mehr) ist es einfach unbequem dies anders zu machen

Wenn Du bis zu 20 und mehr Objekte uebergeben musst, wuerde ich ueberlegen, ob das grundlegende Design nicht falsch ist und ein paar Ueberlegungen anstellen, wie das eigentliche Problem zu loesen ist (eventuell eine Paraemter/Container Klasse oder Aehnliches). Meines Erachtens, soweit ich das hier aus den wenigen Informationen entnehmen kann, ist Vererbung, wie itstata bereits erwaehnt hat, eine schlechte Wahl. Bei Vererbung wird schnell das Liskovsche Substitutionsprinzip verletzt (LSP), was meistens ein Idikator, dass Vererbung ein schlechter Loesungsansatz war.

Ansonsten ist eine Mehrfachvererbung nur über Interfaces möglich.

Das kann ich leider so nicht stehen lassen. Mehrfachvererbung gibt es in C# nicht. Man kannt thematisch getrennte Inhalte in unterschiedlichen Interfaces auslagern und diese Interfaces anschliessend beliebig kombinieren, aber letztendlich benoetigt man doch eine Klassen die alle Interfaces impelmentiert, oder mehrere Klassen, die nacheinander jeweils abgeleitet werden.

Gruss, DaMoe

Bzgl. der Frage ob WinForms oder WPF gab es auf der Heise Developer Seite folgenden netten Artikel von Dr. Schwichtenberg WPF versus Windows Forms - Die Diskussion

Gruss, DaMoe

@jaensen: Das DGV besitzt fuer das erwaehnte Prop keinen setter. Es gibt nur einen getter, der soweit ich das gesehen habe, ein Event aufruft und dessen Rueckgabewert als Return-Wert zurueckliefert.

public bool IsCurrentRowDirty
{
    get
    {
        if (!this.VirtualMode)
        {
            if (!this.dataGridViewState1[0x40000])
            {
                return this.IsCurrentCellDirty;
            }
            return true;
        }
        QuestionEventArgs e = new QuestionEventArgs(this.dataGridViewState1[0x40000] || this.IsCurrentCellDirty);
        this.OnRowDirtyStateNeeded(e);
        return e.Response;
    }
}

@Fabian: Ich glaube nicht, dass nur der Blick auf den Stacktrace ausreichen wird. Zumal ich davon ausgehe, dass das BitHai schon gemacht hat, da es ein Grunwerkzeug des Debuggins ist/sein sollte.

Gruss, DaMoe

HI BitHai!

Als ich meinem Beitrag geschrieben habe, war nicht ganz klar was Du genau beabsichtigst bzw. was Dein Problem war. Nun weiss ich was Du meinst, allerdings kann ich talla nur zustimmen, wenn "IsCurrentRowDirty" eine "reine" Variable und kein Property ist, dass es schwierig wird auf eine Aenderung dieser zu reagieren.

Redest Du eventuell von DataGridView, welche das Property isCurrentRowDirty enthaelt?

Gruss, DaMoe

Hallo,

ich weiss nicht, ob ich wirklich Deine Frage verstanden habe:

und wenn die Bedingung erfüllt ist, anhalten ohne das ich einen Haltepunkt setze?

Was soll das denn fuer einen Unterschied machen, wenn man anhaelt ohne einen Haltepunkt zu setzen?
Ich versuche trotzdem mal ein paar Stichpunkte zu nennen, vielleicht zielt es in Deine Richtung ab:
Du kannst durch Abfragen im Code den Debugger programmatisch anhalten lassen (ist ja auch direkt uber das Setzen des BreakPoints moeglich, aber das weisst Du ja bereits) z.B.

if(condition)
{
 Debugger.Break();
}

Anstatt des oben gennanten Beispiels kannst Du auch mal nur Ausgaben auf der Console oder uber Debug.WriteLine machen, die das Verhalten der App. nicht so beeinflussen wie ein konkreter BreakPoint.

Gruss, DaMoe

Hallo,

habe gerade gesehen, dass Du tools fuer das CF suchst. Eventuell bietet der Artikel nicht das an Tools was Du suchst, allerdings macht er auf gewissen Dinge aufmerksam, die man vermeiden kann, um Memory Leaks zu erhalten.
Hast Du bzgl. Tools schon mal auf http://sharptoolbox.com/ nachgeschaut?

Gruss,
DaMoe

Hallo EagleEye,

vielleicht hilft Dir folgender Beitrag weiter:

New Article on Detecting Memory Leaks . NET Applications

Gruss, DaMoe

Moin!

Vielleicht hilft Dir das weiter:

WindowsIdentity wi = WindowsIdentity.GetCurrent();
// WindowsIdentity wi = new WindowsIdentity(logonToken);
string sid = wi.User.ToString();

WindowsIdentity befindet sich im Namespace System.Security.Principal.

Gruss, DaMoe

Hallo,

alternativ, wenn man Enums uebersetzen moechte, finde ich folgenden Beitrag auch ganz gut: Localizing .Net Enumerations

Gruss, DaMoe

Moin zusammen!

Abgesehen vom .Net Massdownloader bietet das VS 2008 so eine Funktionalitaet mittlerweile auch an. Ich meine, dass dies mit dem SP1 kommt. Unter Options sollte wie im Dateianhang zu sehen, unter dem Punkt Debugging -> Symbols eine Schaltflaeche auftauchen (Load symbols form Microsoft symbol server), mit der das VS dann initial einen temporaeren Ordner anlegt und die PDBs sowie Source Dateien herunterlaedt.

Gruss, DaMoe

lass doch einfach das "break" in einem Fall weg

Ich glaube, dass das nicht zu dem gewuenschten Verhalten fuehrt, zumal ich meine, dass sich der Compiler beschweren wird, dass ein implizites Fall-Through nicht moeglich ist. Soweit ich mich erinnere gibt es hier ein "goto case". Ob das aber so schoen ist, weiss ich auch nicht.

Gruss, DaMoe

Hi!

Das ist doch gut, dass der Compiler Dich darauf aufmerksam macht, denn Laufzeitfehler sind meistens schwerer zu finden als Compilezeitfehler. Zumal DateTime nur IComparable und nicht IComparable<T> implementiert.

Gruss, DaMoe

Nachtrag:
Da Du auf Performanz achtest ist mir noch Folgendes eingefallen:
Bei der Verwendung von Struct sollte man darauf achten, dass ein Struct nicht groesser als 16 Bytes ist. Da Du String verwendest, werden die Referenzen auf die Strings in Deinem Struct gespeichert. Die Groesse einer Referenz ist prozessorabhaengig und ist somit auf einem 32 Bit System, 4 Byte gross. Somit liegst Du mit drei Strings bei 12 Bytes was noch in Ordnung ist. Soll die Applikation auf einem 64Bit System laufen, dann enhaelt Dein Struct bei drei Strings gleich 24Bytes, was Performanzeinbußen zur Folge hat.

Gruss, DaMoe

Hallo!

Wie Jaensen schon erwaehnt hat, ist ein FindAll nicht gerade performant.
Was ich mir noch an dieser Stelle vorstellen koennte, ist, dass Du A und B zusammen als HashCode verwendest (ueberschreiben der GetHashCode Methode) in Kombination mit HashSet<T> verwenden kannst. Allerdings duerfen keine doppelten Elemente in dem Set enhalten sein.

Gruss, DaMoe

Hallo,

ganz genau kann ich Dir auf Deine Frage nicht antworten, aber vielleicht helfen, die Fehlermeldung zu verstehen.

Generell ist das IConvertible Interface laut Doku fuer folgende Aufgabe zustaendig:

Defines methods that convert the value of the implementing reference or value type to a common language runtime type that has an equivalent value.
...
This interface provides methods to convert the value of an instance of an implementing type to a common language runtime type that has an equivalent value. The common language runtime types are Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Decimal, DateTime, Char, and String.

If there is no meaningful conversion to a common language runtime type, then a particular interface method implementation throws InvalidCastException. For example, if this interface is implemented on a Boolean type, the implementation of the ToDateTime method throws an exception because there is no meaningful DateTime equivalent to a Boolean type.

Interessant ist nun fuer Dich, von welchem Typ Object ist.

Gruss, DaMoe

Hallo,

momentan arbeite ich mit dem PropertyGrid aus dem .NET Framework und stehe vor der Problematik, dass ich die Properties in einer bestimmten Reihenfolge (nicht alphabetisch) anordnen muss. Dazu habe ich zwei Loesungen erarbeitet, die sich unterschiedlich verhalten. Zum einen kann man das ICustomTypeDescriptor Interface verwenden (siehe dazu Custom Sort Order for PropertyGrid). Hierbei ist es wichtig das "PropertySort"-Property des Grids auf "none" zu setzen (was nicht explizit erwaehnt wird), ansonsten funktioniert die Sortierung nicht korrekt. Sobald die Kategorisierung wieder eingeschaltet ist, verliert man innerhalb einer Kategorie seine Sortierung.
Der zweite Loesungsansatz ist, dass ich vom ExpandableObjectConverter ableiten muss (von TypeConverter abzuleiten reicht nicht aus) und entsprechende GetProperties-Methode ueberschreibe. Dadurch erreiche ich eine Sortierung innerhalb der Kategorien und verliere, ausserdem nicht die Sortierung, wenn ich ueber entsprechende Schalftflaechen im PropertyGrid die Sortierung umschalte (z.B. schalte Kategorien kurzzeitig aus). Das Verwunderliche ist, dass sich die GetProperties-Algorithmen vom ICustomTypeDescriptor und ExpandableObjectConverter nicht wirklich unterscheiden, jedoch das PropertyGrid hier eine Unterscheidung macht.

Meine Frage: Wisst Ihr warum an dieser Stelle das PropertyGrid die Property-Reichenfolge unterschiedlich interpretiert?

Gruss, DaMoe

Hallo!

Zum einen wuerde ich an Deiner Stelle die Stop-Methode immer zuerst in einer Methode ausfuehren. Ausserdem solltest Du den EventHandler nur einmal registrieren. Da bei Dir die set-Methoden eventuell mehrfach aufgerufen werden, registrierst Du die Events mehrfach, genauso setzt Du das Intervall mehrfach (was weniger schlimm ist), aber unnoetig. Das von Dir beschriebene Debugging-Problem liegt wahrscheinlich daran, dass Dein Timer "recurring" ist, d.h. dass der Timer immer wieder das Event feuert solange kein Stop aufgerufen wurde. Wenn Du nun einen BreakPoint setzt bevor der Timer gestoppt ist, dann wird der Timer weiterarbeiten. Also stop ganz nach oben in die Methode, Break-Point nach der Stop-Methode setzen und somit solltest Du besser debuggen konnen.

Gruss, Moe

Edit: System.Windows.Timer ist Single-Threaded weshalb eigentlich meine Vermutung nicht ganz richtig sein kann bzgl. des Debuggings. Das Problem wird wahrscheinlich haupstaechlich durch die mehrfache Registrierung kommen wodurch sich nach einer gewissen Zeit immer mehr ein Zeitverschub einschleicht.

Hi!

Ich denke, dass Du mit dem aufgefuehrten foreach Probleme haben wirst, da Du eine Collection nicht aendern kannst, wenn Du mittels foreach durch die Collection iterierst.
Kannst Du denn nicht anstatt ObservableCollection<T> BindingList<T> verwenden, denn diese bietet ein Property (RaiseListChangedEvents) an, mit dem Du unterbinden kannst, dass ein Event geworfen wird, dass sich die Liste geaendert hat.

Gruss, DaMoe

...Eventuell kommt da ja auch noch ein OpenSource Reflector von irgendwem den es ankotzt das er jetzt kommerziell geworden ist.

Warscheinlich noch von Lutz Roeder 😄 😄

Moin,

das Framework hat Dir doch in der Exception Nachricht bestimmt noch angegeben, welcher Parameter ungueltig ist?
So viele Parameter hast Du ja nicht. Du hast nun zwei Moeglichkeiten: Entweder ist der Uebergabewert an den Konstruktor von JPEGStream falsch oder video_NewFrame ist inkorrekt.

Gruss, DaMoe

Da ist schon etwas dran, was vbprogger sagt. Anscheinend kannst Du debuggen und somit laeuft der Kompilierdurchgang durch?

Wie sieht es bei dir mit den geladenen Modulen aus? Hast Du das auch mal ueberprueft? (daran sieht man, welche PDBs geladen wurden)

Gruss, DaMoe