Bitte genauer sagen, was Du ausdrücken magst, als nur "falsch".
Gerne.
Ich hätte erwartet, dass wenn ich das Icon für "Neue Beiträge!" (Text des Icons) sehe, dass dann dieses Forum auch wirklich Threads enthält die ungelesen sind.
Wir sind uns einig, dass dies aktuell nicht der Fall sein muss, wenn ich über "Aktive Themen" gehe.
Meine Meinung:
Aus Benutzer-Sicht ist dies nicht konsistent und verwirrend.
Nehen wir an es gibt seit meinem letzten Besuch 10 neue Posts in 10 verschiedenen Foren. Nun besuche ich 5 dieser Threads über "Aktive Themen" und gehe danach auf die Forenübersicht. Nun sind hier immer noch 10 Foren mit "Neuen Beiträgen!" markiert. In 5 Fällen gehe ich in ein Forum und sehe, dass ich den Thread schon gelesen hatte.
Ich würde, als stink normaler Benutzer, implizieren, dass das Icon eine Aggregation aus den einzelnen Threads ist. Enthält ein Thread im jeweiligen Forum einen ungelesenen Beitrag ist das Forum als ungelesen zu markieren, und nicht, dass ich manuell in das Forum navigieren muss um dieses als gelesen zu markieren.
Einen kleinen Bug scheint es mit der Anzeige ungelesener Beiträge zu geben, wenn man nicht das Forum, das den Thread enthält, direkt besucht, sondern nur über "Aktive Themen" geht:
Ich gehe auf die Foren-Übersicht und es wird mir in Forum X angezeigt dass es neue Beiträge gibt (orangenes Icon)
Ich gehe auf Aktive Themen (nicht direkt in das Forum) und sehe nun Thread Y ist ungelesen
Ich klicke auf den Thread um ihn zu lesen
Ich gehe eine Seite im Browser zurück (aktive Themen), refreshe die Seite und der Thread ist als gelesen markiert => korrekt
Ich gehe eine weitere Seite im Browser zurück, refreshe die Seite (Forenübersicht) und das Forum, das den Thread enthielt, ist immer noch markiert mit ungelesenen Threads => falsch
Ich klicke auf das Forum und es enthält keine ungelesenen Threads (Thread gerade gelesen)
Ich gehe wieder zurück auf die Forenübersicht, refreshe die Seite und nun ist auch dort die Markierung (oragenes Icon) weg
Ich fand diese Funktion auch sehr nützlich, da ich dies als Standardansicht für die Navigation im Forum verwendet habe.
Bin klar für eine Wiedereinführung
Vor dem Posten hatte ich die "Vorschaufunktion" benutzt und der komplette Text hinter dem URL-Tag wurde in der Vorschau gelöscht. Dann habe ich den Text wiederhergestellt und gepostet und der Text war wieder gelöscht.
Ich kann den Fehler aktuell auch nicht mehr reproduzieren ... aber auch mit einem nicht korrekt geschlossenem Tag passiert nichts ungewöhnliches. Merkwürdig.
Beim Versuch den Fehler zu reproduzieren habe ich Folgendes gefunden:
Beim Erstellen eines neuen Threads ohne Eingabe einer Überschrift => Vorschau => Error500
Also ehrlich gesagt, verstehe ich nicht, warum du eine WpfApplicaton als Konsolenanwendung missbrauchst.
Weil dann ein Konsolenfenster verfügbar ist, um schnell Debug-Messages, auf einem nicht-Entwicklungsrechner, auszugeben. Siehe Init-Methode. Darauf nun rumzureiten, obwohl es null mit der Ursache oder Lösung des Problems zu tun hat bringt doch garnix.
Zitat von Th69
Ich denke aber, daß der Fehler von einer nativen Komponente verursacht wird (z.B. direkt von der .NET-Laufzeitumgebung).
Dies sollte klar sein, dass die Laufzeit, Treiber oder sonstige Komponente ein Problem hat und nicht die Anwendung selber. Im Notfall die Runtime neu installieren, System auf Fehler prüfen oder Windows komplett zurückzusetzen.
ich habe mal deine kompilierte Variante probiert. Diese startet.
Dann habe ich den Code mit und ohne einkommentiertem TextBlock in Debug und Release getestet. Alle vier Kominationen starten ohne Probleme.
Wenn es eine unbehandelte Ausnahme gibt, wird das entsprechende Ereignis ausgelöst.
AccessViolationExceptions (genauer gesagt alle SEHExceptions) können seit .NET 4 nicht mehr einfach gefangen werden. Der Prozess wird beendet und ein Eintrag in das Ereignisprotokoll geschrieben.
Zitat
In version 4 and later, the CLR exception system will not deliver CSEs to managed code unless the code has expressly indicated that it can handle process corrupted state exceptions.
Was du versuchen könntest wäre einen Crash-Dump zu erzeugen und diesen dann zu debuggen.
Am einfachsten kannst du dies machen in dem du Procdump verwendest. Stürzt ein Prozess ab wird automatisch ein Memory-Dump erzeugt.
Mit folgendem Batch-Skript kannst du die automatische CrashDump Erstellung aktivieren:
cd %~dp0
md c:\procdumps
procdump -accepteula -ma -i c:\procdumps
Und mit folgendem wieder deaktivieren:
cd %~dp0
procdump -u
(Beide Skripte benötigen Adminrechte zur Ausführung. Beide Skripte zur Procdump-Exe kopieren vor der Ausführung.)
Den Crashdump (aus C:\procdumps) solltest du dann einfach via Drag&Drop in VS ziehen und debuggen können.
du wirst wohl nicht darum herumkommen die Argumentliste von neuen Instanzen an die laufende zu übertragen. Th69 hat dazu ja bereits eine mögliche Lösung gepostet (Stichwort IPC).
Ich würde in der primären Instanz eine Queue anlegen und dort die eigenen Einträge einfügen und diese in einer Schleife abarbeiten. Weitere Instanzen übertragen ihre Argumentliste an die primäre Instance, die ebenfalls in die Queue eingefügt werden. Ist die Queue leer beendet sich das Programm.
Leider kann man in dem Screenshot nicht sehen, was um die Zuweisungen, die du ja nun schon mehrmals gepostet hast, passiert. Poste bitte die _komplette_ Schleife, inklusive der Anzeige, wo das Programm sich gerade befindet (gelber Pfeil links). Und am noch den (wenn nötig gekürzten) Inhalt von Liste_Messung_Filter_Daten.
Vorschlag:
Trage alle diese Werte beim Debuggen in das "Überwachen" Fenster ein. Halte das Programm hinter der letzten Zuweisung an und mach einen Screenshot von VS in dem man das Überwachen-Fenster, den relevanten Code mit Breakpoint sehen kann.
Ich rate einfach mal: MovingSegment ist ein Index einer Schleife. Du inkrementierst diesen und vergleichst dann die Werte aus dem letzten mit denen aus dem aktuellen Durchlauf.
Oder, falls gewünscht global, mit diesem Code (siehe auch verlinkter Post):
FrameworkElement.LanguageProperty.OverrideMetadata(
typeof(FrameworkElement),
new FrameworkPropertyMetadata(
XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));
Kannst du z.B. im Ctor/OnStartup deiner Application-Klasse aufrufen.
Edit:
Du hast fast die gleiche Frage schonmal gestellt und eine Antwort bekommen, wie man diese umstellt.
Vielleicht sollte man mit klarem Kopf und ausgeschlafen an die Sache rangehen
was spricht gegen das Erstellen einer Wrapper DLL wie bereits vorgeschlagen wurde?
Ich würde dies als sinnvollen und umsetzbaren Lösungsweg ansehen.
Das gelinkte Beispiel macht 1 zu 1 was du brauchst.
Hast du von der verwendeten DLL die .h und die .lib Dateien?
Was hast du schon in die Richtung versucht?
PS: Wenn die DLL eine native C/C++ DLL ist, dann macht es wenig Sinn diese als Verweis hinzuzufügen.
wenn ich das richtig sehe, hast du einen String mit als Längen-Information.
Das erste Byte stellt die maximale Länge des Strings in Bytes dar.
Das zweite Byte die tatsächliche Länge des Strings in Bytes.
Danach folgen die N Bytes des Strings (nicht verwendete Bytes sollten mit 0x00 gefüllt sein).
Du solltest schauen, was in DBB11 steht.
(Alternativ scheint es dafür schon eine Hilfsmethode in der von dir verwendeten Lib zu geben: StringEx.FromByteArray. Hier müsstest du alle Bytes, inklusive Header, in ein Byte-Array kopieren und dann die Methode aufrufen.)
die Definitionen der structs im C# entspricht nicht denen aus dem C++ Code.
Zitat
IntPtr pElement = new IntPtr(aeusere.data.ToInt32() + Marshal.SizeOf(typeof(Innere)) * i);
Einen Pointer nach Int32 umzuwandeln ist keine gute Idee. Sollte dein Programm unter 64Bit laufen wirst du eine Exception bekommen. Verwende stattdessen besser den + Operator von IntPtr.
Wo ist emxArray definiert? Mir scheint hier, dass dies a) nicht kompiliert und b) zusammengewürfelte Teile sind.
Wenn du ein Array of structs übertragen willst, kannst du dies sehr viel einfacher machen indem du im C# direkt ein Array deiner Struct als Parameter angibst. Im C++ kopierst du dann einfach die Daten via memcpy in das Array.
Da du das Array natürlich im C# vorallokieren musst, und in C++ keine Länge da ist würde ich einen weiteren in/out Parameter für die Array-Länge anlegen:
struct Innere
{
int iValue1;
int iValue2;
double dValue;
};
[DllImport(DLLPfad, CallingConvention = CallingConvention.Cdecl)]
private static extern void GetData(Innere[] data, ref int size);
int size = 0;
Innere[] data = null;
GetData(data, ref size); // Länge abrufen
data = new Innere[size]; // Array allokieren
GetData(data, ref size); // Werte direkt ins Array schreiben
Komplexer machen es nur die Kombinationen aus mehreren Buchstaben.
Täusche ich mich?
Wenn ich beim Überfliegen der Texte richtig verstanden habe, können/müssten Buchstabenkombinationen wie 'sch' oder 'ch' und Zahlen, da A-J auch 1-0 sind, separat behandelt werden. Also wird einfaches Ersetzen eines chars mit einem anderen nicht klappen.
Mit diesen zwei Spezialfällen sollte trotzdem eine recht übersichtliche Lösung zu finden sein:
- Kommt eine Zahl => 'Zahl folgt' + alle Zeichen der Zahl (hier ist die Frage wie z.B. 1,23 umgesetzt werden - ich vermute dass kein zweites 'Zahl folgt' verwendet wird)
- Kommen Zeichen, die in einer Kombination zusammengefasst sind => Kombinations-char
- Ansonsten einzelnes Zeichen mappen
du kannst den Code der an einer anderen Stelle ausgeführt werden soll in eine Methode schreiben und diese dann über die Verwendung von Delegates an einer anderen Stelle ausführen:
public static void vier_mal_wiederholen()
{
for(int i=1;i≤4;i++)
{
// hier soll der Code rein der viermal wiederholt werden soll
}
}
public static void drei_mal_wiederholen()
{
for(int i=1;i≤3;i++)
{
// hier soll der Code rein der dreimal wiederholt werden soll
}
}
public static void Test(Action action)
{
action();
MessageBox.Show("hi");
}
public static void Main()
{
Action action = vier_mal_wiederholen;
Test(action);
Test(drei_mal_wiederholen);
}
ich habe die Vermutung, dass der Schatten des Fensters bei der Berechnung der Größe mitgezählt wird, da dieser bei FormBorderStyles.None nicht gerendert wird und hier das Fenster die erwartete Größe hat.
Ich meine, dass ich genau dieses Wunschverhalten schon viele viele Male gelesen habe, das in der Form aufgrund des Fernsterverhaltens des Betriebssystem jedoch leider gar nicht möglich ist; weil eben das Window Management hier den Fokus wechselt und Du dies nicht aktiv beeinflussen kannst.