Natürlich ist das wrappen des Streams hier nicht optimal gelöst, ich denke, ich muss noch ALLE methoden, die den Ursprungs-Stream benutzen und über das festgelegte offset und limit hinausgehen, "clampen", also die gewünschte Position auf den Bereich limitieren.
Ich denke du schießt gewaltig über das Ziel mit der Implementierung hinaus.
Das Einzige was du überschreiben musst sind die abstrakten Members von Stream - alle anderen kannst du genau so lassen wie sie sind. Ganz besonders macht es keinen Sinn Member zu überschreiben und dann den Basis-Member wieder eins zu eins aufzurufen...
Zitat von gfoidl
.. der eine "View" über den _innerStream legt, dabei zu Beginn von Außen Offset := 0 und Länge := das Limit ist.
Intern kann das ja auf den _innerStream umgerechnet werden. Z.B. beim Setzen der Position halt den Offset berücksichtigen.
Wie schon gesagt wurde ... du muss lediglich Position, Length, Read und Seek so anpassen dass nur der gewünschte Bereich von außen sicht- und zugreifbar ist und der Rest verhält sich dann wie gewünscht.
Hier ein grober Ansatz, den du ausbauen kannst (Parameterprüfung von ctor, Position etc.):
public class StreamLimiter : Stream
{
private readonly Stream _stream;
private readonly long _offset;
private readonly long _length;
public StreamLimiter(Stream stream, long offset, long length)
{
_stream = stream;
_offset = offset;
_length = length;
Position = 0;
}
public override bool CanRead => true;
public override bool CanSeek => true;
public override bool CanWrite => false;
public override long Length => _length;
public override long Position
{
get { return _stream.Position - _offset; }
set { _stream.Position = _offset + value; }
}
public override int Read(byte[] buffer, int offset, int count)
{
long remaining = Length - Position;
if (remaining == 0)
return 0;
count = (int)Math.Min(count, remaining);
return _stream.Read(buffer, offset, count);
}
public override long Seek(long offset, SeekOrigin origin)
{
long position = origin switch
{
SeekOrigin.Begin => offset,
SeekOrigin.Current => Position + offset,
SeekOrigin.End => Length + offset,
_ => throw new ArgumentException(nameof(origin))
};
if (position < 0 || position > Length)
throw new ArgumentException(nameof(offset));
Position = position;
return position;
}
public override void Flush() => throw new NotSupportedException();
public override void SetLength(long value) => throw new NotSupportedException();
public override void Write(byte[] buffer, int offset, int count) => throw new NotSupportedException();
}
die Wrapper Klasse wäre vermutlich der einfachste Weg.
Jedoch solltest du nicht SetLength auf dem gewrappten (File)Stream aufrufen. Dadurch verkleinerst deine gewrappte Datei (schneidest Daten am Ende ab), was vermutlich nicht gewollt ist.
mir ist bewusst, dass man 0.5ms nicht zu 100% erreichen kann ... dies waren eben die ersten sinnvollen Google-Treffer wenn man nach der verwendeten Win-API Funktion gesucht hat. Es sollte lediglich den TE auf diese Option hinweisen.
Hallo ill_son,
vielleicht wäre es besser anstatt eines Sleep Ansatzs einen Timer zu verwenden.
Ich vermute einfach mal frech, dass du deinen Sensor immer im selben Takt abfragen möchtest. Da würde ein Timer, der in regelmäßigen Intervallen auslöst, vermutlich passen.
Da du eine hohe Präzision möchtest, würde ich dir den Multimedia-Timer empfehlen. (Es gibt auch andere Implementierungen im Netz, falls diese nicht zusagt). Dort kannst du die gewünschte Auflösung in ms angeben. (Ja auch hier wirst du nicht auf die ns genau sein, aber besser als Sleeps oder Spin-Locks).
Versuche mal bitte Urzas Vorschlag plus den Scrollviewer um das gesamte ItemsControl zu legen.
Ggf müsste dieser vielleicht sogar noch weitere Ebenen im XAML nach oben.
hier gibt es ein Projekt für globale Mouse- und Keyboard-Hooks: Global-Low-Level-Key-Board-And-Mouse-Hook
Mit drei Zeilen Code hast du deinen Hook erstellt - Beispiel ist auch vorhanden.
mit folgendem Code kannst du die Berechtigungen eines Ordners abrufen:
var info = new DirectoryInfo(path);
var accessControl = info.GetAccessControl();
var rules = accessControl.GetAccessRules(true, false, typeof(SecurityIdentifier));
foreach (FileSystemAccessRule rule in rules)
{
NTAccount account = (NTAccount)rule.IdentityReference.Translate(typeof(NTAccount));
...
}
Du kannst über die DirectorySecurity.AddAccessRule(FileSystemAccessRule) Methode deine gewünschte Regel hinzufügen.
Dass diese nur für den Ordner alleine gilt müsstest du glaube ich PropagationFlags.NoPropagateInherit verwenden (nicht getestet).
Du könntest diese Methode als Grundlage für dein Vorhaben anpassen:
Woran liegt es, dass der Fehler nicht durch die Event-Handler für die Unhandled Exceptions gefangen wird? Ist ein Memorydump der einzige Weg die Ursache zu ermitteln?
Sollte es sich um eine SEHException handeln (müsstest du mal prüfen), dann kann diese ab .NET FW 4 nicht mehr (ohne Weiteres) über die von dir verwendeten Event-Handler gefangen werden. CLR Inside Out - Handling Corrupted State Exceptions
Ich würde ebenfalls den von dir versuchten Weg gehen und einen Memory-Dump anfertigen.
du kannst eine .NET 5 (oder .NET Core) Assembly in einem C++/cli Projekt verwenden.
Dafür musst du ggf. die Projektdatei entsprechend anpassen (geht auch über die Projekteingenschaften).
Einen Ausschnitt aus einem Projekt, dass .NET 5 verwendet:
Raw Input könnte die Lösung sein. Wenn man weiter zu Mauseingaben geht, gibt es relative Bewegungsinformationen. Allerdings weis ich nicht, ob diese von Windows am Bildschirmrand auch abgeschnitten werden. Das müsste man noch evaluieren.
In welcher Art von Umgebung benötigst du diese Information? 3D (Spiel)?
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.