Das sind alles gute Hinweise. Ich würde gerne ergänzen, dass bisher nur geschaut wird, ob die Übergabe überhaupt korrekt funktioniert (erste Verwendung eines MappedMemoryFiles meinerseits) und ich dabei direkt in besagten Fehler gerannt bin.

Es lag in der Tat am geschlossenen Stream beim Erstellen des Bitmaps. Ich interpretiere das so, dass obiger Code im Codebehind mehr oder weniger zufälliger Weise funktioniert, da der Garbage-Collector den Stream noch nicht abgeräumt hat. Scheinbar landet der Stream wohl in Gen1/0 des GC. Weiter habe ich mich da jetzt nicht eingelesen.

Zitat von Abt

Befindet sich derselbe Code im Codebehind meiner Testanwendungen passiert das nicht.

Wirklich 100% gleich, inkl. Aufruf und Verarbeitung? Eher nicht, oder? Daher ignorier ich mal die Aussage für meine Antwort.

Copy-Paste der Read-Funktion, ersetzen des Methodenaufrufs durch die Methode in der Klasse.

Ich vermute daher das, als Quelle des Problems.

Werde ich mal schauen, verstehe dennoch nicht, warum es im Code-Behind geht.

Zitat von BlonderHans

Warum dieses Stream zu Bitmap zu BitmapImage um eigentlich eine BitmapSource zu erhalten?

Wenn du das Bild per Binding übergeben möchtest, dann würde auch ein simples byte[] genügen, was dann automatisch vom ImageSourceConverter umgewandelt wird. Dieses byte-Array kannst du dann irgendwie in irgendeinem Thread-Kontext erzeugen und dann im UI-Thread an das Control übergeben.

Berechtigte Frage. Im Endeffekt soll am Ende eine BitmapSource stehen, der Anfang ist durch einen Stream vorgegeben. Dazwischen wird noch ein wenig an Bildverarbeitung stattfinden, das ist aber noch lange nicht implementiert. Das direkte Konvertieren aus byte[] werde ich mir aber merken, das könnte eventuell nochmal Verwendung finden.

Moin.

Ich habe hier die Aufgabenstellung ein Bitmap zügig zwischen zwei Anwendungen zu transferieren und teste gerade "MemoryMappedFile".

Nach erfolgreichen Tests innerhalb einer Anwendung und über zwei Test-Anwendungen hinweg, wollte ich nun das Schreiben und Lesen in eine eigene Assembly packen, um später noch Features wie Dateinamen-Logging oder sowas bequem einbauen zu können.

Das Problem ist nun, dass beim Konvertieren des System.Drawing.Bitmaps in ein BitmapSource über einen MemoryStream ein allgemeiner GDI+ Fehler auftritt, wenn ich die Lese-Funktion in eine eigene Assembly packe und darüber aufrufe. Befindet sich derselbe Code im Codebehind meiner Testanwendungen passiert das nicht.

Alles .Net Core 9 Projekte, alle Abhängigkeiten zu Drawing usw. sind identisch.

Hat jemand eine Idee?

Der Code:

BitmapSource ReadBitmapFromMemoryMappedFile(string mapName)
{
	try
	{
		using(var mmf = MemoryMappedFile.OpenExisting(mapName))
		{
			using(var stream = mmf.CreateViewStream())
			{
				Bitmap bitmap = new Bitmap(stream);
				return ConvertBitmapToBitmapSource(bitmap);
			}
		}
	}
	catch
	{
		return null;
	
	}
}

BitmapSource ConvertBitmapToBitmapSource(Bitmap bitmap)
{
	if(bitmap != null)
	{
		using(MemoryStream memoryStream = new MemoryStream())
		{
			bitmap.Save(memoryStream, ImageFormat.Bmp);
			memoryStream.Position = 0;
			BitmapImage bitmapImage = new BitmapImage();
			bitmapImage.BeginInit();
			bitmapImage.StreamSource = memoryStream;
			bitmapImage.CacheOption = BitmapCacheOption.OnLoad;
			bitmapImage.EndInit();
			bitmapImage.Freeze();
			return bitmapImage;
		}
	}
	else
	{
		return null;
	}
}
	

Moin, danke für die Antwort.

Jepp, ich brauche beide Einträge. Die Zip-Datei lässt sich bei mir leider nicht öffnen, keine Ahnung warum.

So oder so scheint es wohl keine vorhandene Lösung innerhalb des Controls dafür zu geben. Ich werden vorschlagen das GUI ein wenig anzupassen und die reinen Textboxen entweder zu ersetzen oder durch eine feste Liste zu erweitern, welche dann entsprechend der Eingaben gefiltert oder gefüllt wird.

Moin.

Ich habe hier eine für mich gerade nicht nachvollziehbare Merkwürdigkeit mit einer TextBox in Winforms .NET Framework 4.8 und der Autocomplete-Funktion.

txtType.AutoCompleteCustomSource = textitems;
txtType.AutoCompleteSource = AutoCompleteSource.CustomSource;

Beispiel:

textitems = new string[]{"Hallo", "HALLO"};

Resultiert bei Eingabe "Ha" in dem einzigen Vorschlag "HALLO".

Gewünscht wäre allerdings der Vorschlag "Hallo" oder zumindest beide Einträge in der Vorschlagsliste.

Kann man den Inhalt der Vorschlagsliste eventuell manuell überschreiben? Oder, was mir gerade erst einfällt, hat sich das Verhalten im aktuellen .NET geändert?

Danke schon mal.

👍 Danke, werde ich morgen direkt ausprobieren. 🙂

Hallo,

ich habe hier eine Assembly, aus welcher ich eine Methode mit einem String-Argument aufrufe.

In C# nach dem Prinzip:

[DLLImport("AssemblyName.dll")]
public static extern void StartMethod(string filepath);

public void Test()
{
StartMethod(@"C:\Test\test.ini");
}

VB:

Public Declare Auto Sub StartMethod Lib "AssemblyName.dll" (ByVal filepath As String)

Public Sub Test()
StartMethod("C:\Test\test.ini")
End Sub

Beide Aufrufe werden in der DLL ausgeführt, nur bei der C# Variante kommt dann eine Meldung darüber, dass die Datei nicht gefunden wurde und der angezeigte Pfad besteht aus chinesischen Zeichen.

Wenn das in VB funktioniert, wie muss ich denn dann den string in C# umwandeln, dass er identisch zu VB übergeben wird? 🙂 Liegt das evtl. an den Escape-Symbolen (@ -> double escape = no escape), weil es ein Pfad ist?

Also wäre es vielleicht so gemeint, dass sich HTML-Technologien verbreiten, weil viel in Richtung Multiplatform geht, aber reine Desktop-Anwendungen betrifft das nicht, sie werden nur weiter zurückgehen.

Gibt es überhaupt etwas, das mit MAUI-Blazor gar nicht geht? Dann würde sich doch eigentlich nur die Frage nach den Plattformen stellen. Wenn kein Interesse an Mobile und Web besteht, spricht nichts gegen WinUI (denke ich? 😄), ansonsten landet man zwangsweise bei Maui-Blazor

Ein weiteres Jahr ist verstrichen und ich für meinen Teil bin bzgl. der Frage nach "DEM" Framework für den Windows-Desktop immer noch nicht schlauer geworden. 😁 Weil es thematisch genau passt und ich mich auch auf Abts Blogeintrag beziehe, mache ich mal keinen neuen Thread auf.

Insbesondere habe ich mich bei dieser Vermutung ein wenig gewundert: "Für Desktop-Apps werden sich vermutlich HTML-Technologien wie Blazor durchsetzen, wobei mit Windows 11 auch WinUI3 viele Anwendungsfälle finden werden."

Welchen Vorteil hätte Blazor denn für eine reine Desktop-Anwendung gegenüber WinUI? Für mich klingt die Konstruktion einer Desktop-Anwendung (mit freiem Dateizugriff, usw) mit Blazor immer furchtbar kompliziert im Vergleich zu einem 'klassischen' Desktop-Programm. Zudem integriert sich die Oberfläche doch auch nicht so einfach in die System-Optik, oder?
Was wären denn Punkte bei denen man sage würde "mach das mal lieber mit Blazor/WinUI"? Oder geht die Überlegung eher in die Richtung: Kleine Programme WinUI, umfangreiche UIs eher mit Blazor? Ähnlich wie bei Winforms und Wpf quasi.

Befrag eine Suchmaschine deiner Wahl nach "c# pdf viewer", ich kenne nichts.

WebView2 (oder ein anderes Browser Control) sollte das doch können.