Eigene Titelleiste für (Dialog)Fenster

Also ich hatte ja Code in C# gepostet, den kannst du nicht 1:1 kopieren, du must in übersetzen.
Wenn man in C# eine Typ-Umwandlung machen will, geht das so:

Man schreibt den gewollten Typ einfach in Klammern vor dem was man umgewandelt haben will, so einfach ist das.
Ich entknobel die Zeile ein wenig, denn der Scope von der Umwandlung hat dich vermutlich irritiert.

Nun solltest du das selbst richtig übersetzen können, zum Umwandeln nimm hier DirectCast(was, ZielTyp)

Edit @kafffee
Aber ErfinderDesRades hat schon recht, solche Pinvoke Sachen können schnell zu abstürzen führen(StackImbalance ist mein Favorit). Aber widersprechen tuh ich @ErfinderDesRades mit den DatenTypen, gibt mehr als genug. Wobei viele sogar identisch sind nur anders heißen, hat aber was mit lesbarkeit/wartbarkeit zu tun, auch wenn es auf den ersten Blick unnötig kompliziert wirkt. Nehmen wir HRESULT, eigendlich ein LONG(schau im Anhang), sieht ein C++ Dev das ein HERSULT von einer Funktion zurückkommt, weiß er das es sich um COM Sachen handelt. Würde da auch ein LONG kommen, wäre das nicht so offensichtlich. Das ist nur ein Beispiel, da finde ich das auch Sinnvoll, aber es gibt auch Sachen die ich nutzlos finde, aber das würde hier jetzt zu weit gehen.

Edit2 @kafffee
Ich hab die Mappe jetzt soweit das du experimentieren kannst, hab das auf's Minimum reduziert. Es funktioniert wie ich das wollte. Ich war zwar erst ein wenig auf dem Holzweg, aber hab es gebacken bekommen.
Gibt eine Klasse Titlebar(Titlebar.cs), ein ResourceDictionary mit ControlTemplate(Titlebar.xaml), im Konstruktor weise ich das nicht der Template Property zu wie ich erst wollte, sondern füge sie zu den Resourcen hinzu, wenn noch nicht drin.

Jetzt hab ich auch verschiebbare Popups. Da ich dich jetzt nicht überfordern will hänge ich diese Mappe später an.
Studiere erstmal die Mappe aus meinen letzten Post, sag Bescheid wenn du soweit bist, dann häng ich die Mappe mit verschiebbaren Popup an.

Das Verschieben der Popups ist ohne API gemacht, aber wieder mit AttachedProperty. Wenn ich mit den API Funktionen das PopUp verschieben wollte, wurde statt des PopUps das Window verschoben, scheint als wenn das PopUp selbst das gleiche Handle wie das Window hat.

kafffee schrieb:

(...) Leute ich hab die Lösung, einfacher gehts nicht: (...) Ist halt Code Behind...

Das man auf so viele Sachen in WPF nicht mehr draufkommt, könnte auch damit zusammenhängen, dass man das eigentliche Programmieren zum sogenannten „Code Behind” erklärt/degradiert hat und man sich die Anwendung quasi in XAML mit Bindungen mit der Maus zusammenklicken möchte – die Dogmatiker und Kleriker haben diese Programmierwelt erfolgreich auf den Kopf gestellt. Das eigentliche Programmieren ist eigentlich das, was im „Code Behind” steht oder besser gesagt – stehen sollte – und nicht die Klickerei in einer XAML-Datei. Wenn man beides – sowohl Programmieren als auch XAML-Klicken – kann, kann so ein Programmierkonzept sehr praktisch und hilfreich sein; wenn man nur Xamelln und Binden einigermaßen beherrscht, wird es immer wieder zu scheinbar unlösbaren Problemen und hoffnungslosen Situationen kommen.

Es gibt bei diesen Fenstern in WPF, insbesondere beim DialogFenster, noch einen interessanten Aspekt – als DialogResult bekommt man nur einen Boolean und dann auch noch mit so einem komischen Fragezeichen als Modifizierer des Bools dahinter, also an eine Info, was eigentlich gedrückt worden ist – OK, Abbrechen, JA oder NEIN – kommt man nicht so leicht oder sogar schwer dran. Wenn man eine eigene InputBox gemacht hat, möchte man ja auch irgendwie an den oder die Inhalte der Eingabe(n) des Benutzers kommen, diese auswerten und womöglich das Fenster wegen falscher Eingabe dann erneut öffnen etc, aber Close ist eigentlich close, wie Microsoft selbst schön erklärt (*1). An die ResultBool-Variable komme ich noch einfach konfliktlos dran, denn die wird ja noch vor dem Schließen automatisch als Kopie weitergereicht, aber an die sonstigen Ressourcen des Fensters (einer Klasse) darf ich nach dem Schließen normalerweise nicht mehr drangehen. Sie sind in dem Moment, wo sich das Fenster geschlossen hat, zwar noch im RAM (Speicher) vorhanden und man kann sie sogar auch noch auslesen, aber streng genommen darf (und sollte) man das nicht mehr machen. Wer's nicht glaubt, darf ausprobieren, was passiert, wenn man das DialogFenster nach dem Schließen einfach nochmal mit .ShowDialog aufruft/öffnet, damit der User seine Eingabe z.B. korrigieren kann. Ein normal – also nur mit .Show – geöffnetes Fenster lässt sich sogar scheinbar ohne Absturz unmittelbar nach dem Schließen wieder öffnen (habe ich seinerzeit auch mal getestet), so etwas sollte man aber auf keinen Fall tun, denn in irgendeiner anderen Konstellation wird es zum Absturz führen. Man muss – am besten ressourcenschonend die gleiche – Variable des Fensters wieder durch den Konstruktor mit New jagen, damit das Alte, Ungültige wieder zum Neuen, Frischen (um)gebaut wird. Und um an den Inhalt (einfache Variablen, Felder etc.) der Klasse eines geschlossenen Fensters zu kommen, muss man sich etwas einfallen lassen, damit unsere Anwendung nicht irgendwann mal – scheinbar spontan und dann auch noch nicht reproduzierbar – einen Unfall auf dem Bildschirm baut.

[*1] learn.microsoft.com/de-de/dotn…e?view=netframework-4.8.1
learn.microsoft.com/de-de/dotn…e?view=windowsdesktop-7.0
learn.microsoft.com/de-de/dotn…windows-window-showdialog

kafffee schrieb:

(...) Ich kann dich beruhigen, ich klicke mir nichts zusammen, den XAML schreib ich komplett von Hand (...)

Ich muss leider enttäuschen – das Klicken war in erster Linie eine Metapher für das Schreiben in XAML, jede Menge klicken muss (oder sollte) man dort aber trotzdem oder vielleicht sogar überwiegend, da man die Objekte aus der ToolBox holen und deren Eigenschaften einstellen muss – wer diese komfortable Funktionalität nicht nutzt, ist selber schuld – man könnte das natürlich alles per Hand schreiben, um zu meinen oder sich selbst zu belügen, dass man programmieren tut, aber mit Programmieren ist in der Regel etwas anderes gemeint, das Xamelln könnte man mehr mit „in Form bringen” und Konfigurieren vergleichen. Den richtigen Code dazu gibt es natürlich trotzdem – die (manchmal) Kilobytes an Code, die durch ein paar Zeilen und etwas Klicken in XAML entstehen, macht der Compiler für den „Klickser” oder „von Hand Schreiber” schön unsichtbar im Hintergrund. Relativ einfache Anwendungen – wie beispielsweise „ein Fotoalbum für meine Oma” oder einen Datenlogger/-visualisierer für meinen PC etc. – kann man so quasi ohne richtigen Code geschrieben zu haben kreieren, bei Anwendungen mit komplexen Sachverhalten wird es ohne das richtige Programmieren mit IFs nicht gehen, egal wie man sich in XAML mit Binden, Einstellen und die Objekte in Korrelation bringen anstrengen wird. Das sieht man eingentlich hier im Topic sehr schön – man strengt sich enorm an, eine einfache Titelleiste und ein paar Funktionalitäten für ein Fenster hinzubekommen, indem man sich an dem richtigen Programmieren vorbeimogelt, das richtige Resultat mit den gewünschten Funktionalitäten will aber einfach nicht auf dem Horizont erscheinen. Wenn es am Ende doch noch irgendwie auf Umwegen und mit viel Kuddelmuddel klappen sollte, wird man sich nicht sicher sein, woran es jetzt eigentlich liegt, das es irgendwie funktioniert; und das Wichtigste - ob es immer funktioniert.

@kafffee Ich habe gerade beim nochmaligen testen einen Fehler bemerkt, ich hatte einen Thumb(DragDelta) mit Attached Property benutzt, ein Thumb nimmt aber keine Childs auf. Ich mach das eben noch mal mit einem anderen Element.

Edit @kafffee

Ich bin zu der Erkenntnis gekommen, dass das mit den Popups schwachsinn ist. Wenn ich meine Maus auf maximale Geschwindigkeit stelle, was sehr schnell ist, rutscht der Cursor aus dem Rectangle und kein MouseMove wird dann mehr ausgelöst. Könnte man mit einer While schleife lösen, aber dann kommt kein MouseUp rein und wir hängen in der Schleife fest. Könnte man Threading nutzen, jetzt sollte jedem klar sein das das schwachsinnig ist. Mit dem Thumb klappt das wunderbar.

Empfehlung: Nimm entweder ein Window ohne Border + die Titelleiste, oder nimm das mit dem Thumb, man kann ja einen kleinen in irgendeine Ecke packen. Wobei auch das mit dem DragMove() im CodeBehind eine brauchbare Option ist.

Beim MouseDown könnte man einen Thread starten mit While Loop(also solange MouseDown ist), in diesem Loop muss dann ja auch auf den UIThread zugegriffen werden, und das bei jedem durchlauf der Loop, das heißt man muss einen Dispatcher haben und mit diesem hunderte/tausende male invoken und das nur um ein Popup zu verschieben. Es wäre zwar ein leichtes das umzusetzen, aber nur um verschiebbare Popups zu haben, welche man anders leichter und resourcenschonender umsetzen kann. Das mit dem Thumb finde ich absolut OK, die kann man sich auch schick stylen.

Warum PopUps nicht das gelbe vom Ei sind:
PopUps haben keine wirkliche X-Y Position, nur ein Offset relativ zum Window.
PopUps sind TopMost, das ist bei Splashscreens, Ladeanimationen, Fortschrittsanzeigen, Userinteraction oder um den User über etwas zu informieren OK, aber dauerthaft? Wenn ein Author meint das sein Programm so wichtig ist, das alles oder Teile davon immer vorne zu sein haben, deinstalliere ich es sofort, wenn ich das nicht durch Einstellung ändern kann. Ich hasse es wenn ich Fenster verschieben muss um dahinter liegendes sehen zu können, wenn man zich Fenster beim arbeiten offen hat, bremst das nur unnötig aus und das nervt auf Dauer. Ist man von einem Programm genervt, wird man es wohl kaum weiter nutzen, es gibt immer alternativen. Also niemals User nerven wenn du willst das sie dein Programm nutzen

Ich denke das PopUp ist eine Sackgasse in diesem Fall.

Edit @kafffee
Ich denke dein Problem ist einfach nur das du ein Handle brauchst um das VST-Element zu hosten. Da in WPF alle Controls das selbe Handle wie das Window haben, gestaltet sich das schwierig. Und genau dafür habe ich jetzt eine Lösung
Ein WindowsFormsHost! Die haben ein eigenes Handle, habe das erfolgreich getestet.

Sieh noch einmal genau hin was ich gemacht hab! Wo habe ich denn PresentationSource, HwndSource oder WindowInteropHelper verwendet? Nirgendwo. Brauchst du nicht. Wie kamst du auf die Idee das einzubauen, obwohl das bei mit nicht zu sehen ist? Ich enthalte dir sicher nicht absichtlich irgendwelche Informationen.(könnte zwar aus versehen passieren, aber das ist hier nicht der Fall)

Da du in meinen Schnippsel das offentsichtliche gerade nicht zu sehen scheinst, ließ hier mal alle Namen der Eigenschaften vom WindowsFormsHost durch, du könntest dich erschrecken, wenn du das dann sieht, weil das zu offensichtlich ist.

learn.microsoft.com/de-de/dotn…t?view=windowsdesktop-7.0

kafffee schrieb:

While HWND Is Nothing
End While

Wenn du vor der Schleife versuchst an den Wert zu kommen, dann in der Schleife landest, wodurch soll in einer leeren Schleife denn auf einmal HWND einen Wert bekommen?

Ob nun in Dezimal 0 oder in Hexadezimal 0x0 (oder &H) oder Binär 0b0, alles 0.

Jetzt frage ich mich aber warum du das in deiner Sevice Klasse hast.


Es ist bereits auf dem Window, wenn du das wie gezeigt im Window-XAML eingefügt hast, du brauchst keine zusätzliche Instanz oder die Instanz zwischenspeichern wenn du direkt drauf zugreifen kannst, siehe die XAML Zeile bei mir. Dieses WindowsFormsHost hat sogar einen Namen bekommen über den ich drauf zugreifen kann. Du weist der Variable nicht mal was zu, wo soll denn da dann ein gültiges handle herkommen? Ist doch klar das es dann 0 ist.

Warum erweiterst du deinen Code nicht einfach nur mit dem den ich dir zeigte? FensterSeviceInterface eine weitere funktion, dann natürlich auch in der Klasse die das Interface implementiert. Diese Funktion dann nutzen um das Handle zu bekommen.

Ich komme so überall im Projekt durch diese Zeile an das Handle.

Da dieser Code-Auszug vermutlich aus deiner Serviceklasse ist, reicht dort dann GetFormControlHandle(), oder anstatt die Funktionen einzubauen greif in der Serviceklasse einfach so wie ich drauf zu.

Ich versteh grad nicht wo bei dir der Schuh drückt. Aber ich glaube langsam das du keinen Überblick mehr über das ganze hast oder das immer noch ein Paar Grundlagen fehlen.

Xaml
<WindowsFormsHost Name="FormHost" />
ServiceKlasse
return window.FormHost.Handle;

Wenn der Groschen jetzt nicht fällt, kann ich dir nicht helfen.

Lade die Mappe mal hoch. Ich habe zwar Angst mich durch chaotischen Code buddeln zu müssen, aber ich schau mal rein. Aber alles kompilierte löschen(.vs, bin, obj) Ordner

Hast du etwa den Zugriffmodifier der FensterKlasse auf Friend gestellt? Das wäre nämlich ein möglicher Grund warum das nicht geht, falls du von außerhalb dieser Assembly drauf zugreifen willst. Wenn man schon Sachen anwendet, muss man auch wissen was diese bewirken, sonst wundert man sich schnell mal wenn dann was nicht klappt.

Ich kann dir nur empfehlen noch einmal Grundlagen durchzukauen, Zugriffsmodifier sind absolute Grundlagen. Wenn du anderen Code verwendest und nicht weist was was macht, Google damit füttern und lesen. DU kannst dir das Code schreiben deutlich einfacher machen. Sieh solche Recherchen als Investition in deine Zukunft. Am Anfang kostet das Zeit, aber hinterher kannst du das richtig und sparst Zeit, weil du nicht suchen musst, oder nicht fragen und dann auf Antworten warten.