WinUI Stuff: accessing the properties of another control (named element) using x:bind

x:bind is a quite powerful command and feature in XAML. You can get the data for your XMAL-control from (almost) anywhere. You can even get it from another control, and you do not write (almost) a single line of code.

Let’s say you have a SplitView and you want to hide/unhide the pane of the SplitView by another control, let’s say by a ToggleSwitch.

You could write for the SplitView:

<SplitView x:Name="MySplitView"
           IsOpen="{x:bind MyToggleSwitch_ForPane.IsOn,
           Mode=OneWay}">
  <SplitView.Pane>
  ...
</SplitView>

Instead of hardcoding, the state of the pane, like IsOpen=“true“ (if the pane is visible) of IsOpen=“false“ (if the pane is hidden), we ask another control – MyToggleSwitch_ForPane – what to do.

We implement the ToggleSwitch and set it initially to „true“ (which means the pane will be visible initially as well):

<ToggleSwitch x:Name="MyToggleSwitch_ForPane" Header="Enable/Disable Pane" IsOn="true"/>

So, the SplitView control uses the IsOn property of the ToggleSwitch to hide/unhide its pane.

You could do the same thing with the SplitView using the binding attribute instead of x:bind:

<SplitView x:Name="MySplitView"
           IsOpen="{binding ElementName=MyToggleSwitch_ForPane
           Path=IsOn, Mode=OneWay}">
  <SplitView.Pane>
  ...
</SplitView>

Personally, I prefer x:bind instead of binding, since it is the stronger binding.

However, using x:bind you might see an error like „MyToggleSwitch_ForPane is not a member of MyPage in line … (where you use the SplitView)“ (assuming, MyPage is the wrapping <Page>). So what happened? As always, nothing is free and therefore, also the using x:bind is „not for free“. Means, you need some additional code. Even though, the error statement is not really helpful (if you don’t know the behinds), it tells the problem: the XAML-interpreter does not know about MyToggleSwitch_ForPane.

If you want to reference named elements using x:bind, they need to declarated in the IDL file:

Windows.UI.Xaml.Controls.ToggleSwitch MyToggleSwitch_ForPane{ get; };

Basically – and this is quite understandable when you’re familiar with XAML – x:bind needs a getter to access the control. There is no need to declare the function in the header file or even to define the function in the .cpp (assuming your code is winrt/C++) file. Same is for the .cs file (assuming your code is winrt/C#).

Where to go from here:

About the IDL, XAML and header file: https://stackoverflow.com/questions/69125714/what-properties-functions-have-to-go-in-an-idl-when-using-xaml-and-c-winrt

About the pros and cons of strong binding using x:bind versus weak binding using binding: https://github.com/microsoft/microsoft-ui-xaml/issues/6411

About binding a control in a XAML file: https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

In einem Hotelzimmer 1.200 Meter über dem Grand Canyon – oder: Virtual Reality

Es war im Sommer 2016 als ich das erste Mal richtig mit VR (Virtual Reality) in Kontakt kam. Zuvor hatte ich immer wieder Videos von VR-Aufnahmen gesehen. Auch die eine oder andere Augmented Reality Anwendung hatte ich bereits zuvor gesehen. Es war der Sommer, in dem Pokémon Go Augmented Reality einer breiten Öffentlichkeit zugänglich machte. Lego hatte bis dahin in seinen Verkaufsprospekten immer wieder Augmented Reality integriert. Aber AR und VR sind ja nicht wirklich das Gleiche.

Zu diesem Zeitpunkt arbeitete ich als Verantwortlicher für New Business für eine Berliner Kreativagentur, die sehr stark „digital unterwegs“ war. Bei einer Klausurtagung zeigte ein Berliner Startup, was im Bereich der Virtual Reality derzeit (wie gesagt, wie sprechen über das Jahr 2016) Stand der Technik war. Das Setting war so einfach wie effektiv. Klar VR-Brille und VR-Controller für die Hände und: ein Brett auf dem Boden. Mit der VR-Brille wurde aus diesem „Brett“ mit einem Mal ein „Steg“. Und aus dem Teppich des Hotelzimmers wurde der „Gran Canyon“. 1.200 Meter ging es links und rechts des „Stegs“ in die Tiefe. Die Aufgabe: auf den „Steg“ hinauslaufen, an dessen Ende eine Vase holen und diese zurückbringen.

Ich bin zwar nicht schwindelfrei, leide aber auch nicht unter Höhenangst – und trotzdem

Klingt einfach? Nicht für mich. Ganz, ganz vorsichtig stieg ich auf das Brett pardon, den Steg. Mit der Fußspitze hatte ich zuvor die Brettkante ertastet. Jetzt stand ich da auf dem Steg und hatte eine großartige Aussicht über den Grand Canyon. Ich bin jetzt nicht ganz schwindelfrei aber ich leide auch nicht gerade unter Höhenangst, trotzdem bewegte ich meine Füße nur millimeterweise nach vorne. Ich spürte Schweiß an den Händen und auf der Stirn. Erst als ich mir sagte: „Moment – das ist nicht der Grand Canyon, das ist ein Hotelzimmer, da geht es keine 1.200 Meter in die Tiefe, sondern eineinhalb Zentimeter bis zum Teppich, erst dann ging es (etwas besser). Ich war zumindest in der Lage, zwar sehr zögerlichen Schrittes, aber wenigstens war eine Bewegung erkennbar, mich sukzessive in Richtung Stegende und damit zur Vase zu bewegen. Dann noch bücken – ohje, ohje, geht das hier tief herunter – und die Vase greifen. Erleichtert konnte ich den Rückweg antreten, wie immer wenn es hinter einem sicher ist, ging das Zurück deutlich schneller. Erleichtert und meinen Humor wieder gefunden, entschied ich mich kurzerhand, die Vase in den Grand Canyon zu werfen.

Während ich über dem Grand Canyon „schwebte“, sah das für die Zuschauer im Hotelzimmer so aus. Da das Video bei meinem zweiten Ausflug auf den Steg gemacht wurde, bewege ich mich schon deutlich sicherer.

Brille auf und weg – trotz „Low-Poly“

Bis heute faszinieren mich insbesondere zwei Dinge an diesem Virtual Reality Erlebnis. Erstens: man ist sofort drin. Ich hatte die Brille aufgesetzt und fast im gleichen Augenblick stand ich an der Kante des Grand Canyon. Es hatte keine Sekunde gedauert, bis mein Kopf umgeschaltet und komplett „vergessen“ hatte, dass ich mich eigentlich in einem Hotelzimmer befand. Und zweitens: die Grafik – sie war nicht einmal besonders gut. Wer heute „Red Dead Redemption 2“ oder vielleicht noch ausgefeiltere 3D Welten gewohnt ist, wäre entsetzlich enttäuscht. Der Grand Canyon war mit ziemlich großen Polygonen nur grob modelliert. Und trotzdem: es hat dem Erlebnis und dem „Realismus“ keinen Abbruch getan.

VR, das „Next Big Thing“?

Ich war damals der festen Überzeugung, dass „VR“ das nächste „Big Thing“ sein wird. Im Grundsatz teile ich diese Überzeugung noch heute. Allerdings lässt sich feststellen, dass der Moment des „Big Thing“ noch weiter auf sich warten lässt. Wie gesagt, war ich damals für New Business verantwortlich und ich habe eine Reihe von Kunden aus der High-Tech-Industrie auch strategisch beraten. Also habe ich mir viele Gedanken gemacht, wie sich „VR“ über den Gaming-Sektor hinaus nutzbringend einsetzen lässt. Die grundsätzlichen Probleme sind bekannt und auch heute zum Teil gelöst. Das sind vor allem die Kabel, die nicht nur recht schwer sind, sondern einfach durch ihre Länge und Materialität die Bewegungsfreiheit einschränken. Nicht so einfach zu lösen ist die Frage, wie sich Bewegungen wie Gehen, Laufen, Rennen über die VR abbilden lassen. Schnell zeigt sich, dass für viele Anwendungen, die über das Sitzen und Stehen hinausgehen, größere Räume benötigt werden. Diese sind zwar leer – das Ambiente kommt von der VR – aber der Platz für die Bewegung wird trotzdem gebraucht. Und damit kommen wir zur zweiten Herausforderung: VR ist meist nur etwas für „wenige“. Ich hatte einige Zeit später ein Konzept für eine Messe entwickelt mit der Idee, ein Produkt in einer VR-Welt zu präsentieren. Aber Messen sind dafür gemacht, ein breites Publikum zu interessieren. Gut, kann man sagen, dann hat man eben ein paar mehr VR-Brillen auf dem Messestand. Trotzdem bleibt das Problem, das VR-Erlebnis haben nur „wenige“.

VR macht nicht einsam

Ich habe den Eindruck, dass viele Überlegungen, was sich alles mit VR anstellen ließe, im Kern Anwendungen sind, die tendenziell „einsam machen“. Oder, weniger pathetisch formuliert, die sich auf den Einzelnen fokussieren. Da ist die Idee ein großes Bauvorhaben einem Investor mittels VR vorzustellen, da sind die meisten Spieleideen, die den Gamer mit VR-Welten beeindrucken. Ich habe habe mich gefragt, ob das „next big thing“ nicht vielmehr darin bestehen könnte, mit VR Menschen zu verbinden (vielleicht ist die Idee des Metaverse von Meta ja genau dieser Ansatz – aber das ist einen anderen Blogeintrag wert). Ich hätte eine konkrete Idee für VR, die gleichzeitig auch kein Platzproblem hat (wer daraus übrigens ein Geschäft machen will, ist herzlich eingeladen – ich selbst werde es wohl nicht mehr machen – einzige Bedingung: haltet mich auf dem Laufenden – und wenn es jemand erst meint, schreibe ich auch gern das Konzept zu dieser Geschäftsidee): Warum nicht das „virtuelle Klassenzimmer“ mit VR realisieren? Ich bin zutiefst davon überzeugt, dass Menschen gemeinsam besser lernen. Ich glaube, dass das Klassenzimmer oder der Hörsaal die besseren Orte sind, um zu lernen. Es braucht diesen gelegentlichen Blick zum Nachbarn auf der linken und zur Nachbarin auf der rechten Seite. Es braucht die Möglichkeit, den eigenen Blick kurz über die anderen „Leidensgenossen“ schweifen zu lassen, die ebenfalls in genau diesem Moment versuchen, den Stoff zu verstehen. Und alles das, können keine YouTube-Tutorials und kein Home-Schooling leisten. Dabei wäre es ganz einfach: jeder Schüler oder jede Studentin bekommt eine VR-Brille und gemeinsam lernen sie im virtuellen Klassenzimmer. Egal wo jeder und jede auf der Welt in Wirklichkeit gerade sitzt. Entscheidend ist, dass sie zum gleichen Zeitpunkt gemeinsam lernen. Ach ja, und ich glaube nicht, dass bei dieser – ich höre schon die Ausrufe: wie altmodisch: Frontalunterricht (geht übrigens auch in der Seminarversion) – Art des Unterrichts die Wissensvermittlung über einen CG-Avatar funktionieren kann. Auch hier bin ich davon überzeugt: Menschen lernen nicht nur am besten mit Menschen, sondern auch von Menschen.

Erst eins, dann zwei, dann hunderttausend

Webbasierte Software mit PHP/MySQL zur fertigungsbegleitenden Erfassung und Auswertung von Messdaten in der Großserie für einen Automobilzulieferer

Einerseits sind Zerspanungsprozesse hochgenau und dienen beispielsweise in der Motorenfertigung zur Herstellung von Präzisionsbauteilen. Anderseits unterliegen sie prinzipbedingt der Gefahr von Toleranz- und Maßschwankungen. Es addieren sich die Toleranzen in der Werkzeugmaschine, die Toleranzen des Spannmittels und die Toleranzen der Bearbeitungswerkzeuge. Zumindest eine regelmäßige Messung von Stichproben, um Warngrenzen und Eingriffsgrenzen in den Fertigungsprozess rechtzeitig zu erkennen, ist unumgänglich. Zur Analyse von Trends, zum Nachweis bei dokumentationspflichtigen Bauteilen oder zur Ursachenforschung bei Reklamationen müssen die Messdaten gespeichert und ausgewertet werden.

Für einen Automobilzulieferer, der Komponenten für Einspritzsysteme von Dieselmotoren in Großserie herstellte, wurde eine Software zur Messung, Speicherung und Auswertung von Geometriedaten entwickelt. Die Software wurde mit Webtechnologien, also zur Bedienung über gängige Webbrowser, mit serverseitigem PHP programmiert. Die Daten werden in einer MySQL-Datenbank gespeichert.

Messdaten erfassen

Die Messdaten gilt es „nur“ in Stichproben zu erfassen, so dass eine automatisierte Messung nicht erforderlich ist. Zum Einsatz kommen elektronische Messchieber, die die gemessenen Geometriemerkmale direkt auf Tastendruck an den PC und damit in das Formular der entwickelten Messsoftware übertragen. Geometriedaten, die über ein Messgerät mit Hinterleuchtungstechnik erfasst werden, übernimmt die Software über eine speziell geschaffene Schnittstelle. Alle Messdaten werden in der MySQL-Datenbank (Merkmal, Bauteil, Charge, Benutzer, etc.) gespeichert.

Messdaten speichern

Durch die große Anzahl der gefertigten Teile und gemessenen Merkmale kommen schnell siebenstellige Datensatzmengen zusammen. Im Vorfeld der Programmierung wurden umfangreiche Performance-Messungen mit der MySQL-Datenbank gemacht, um dann ein optimales Datenbankdesign zu finden. Gleichzeitig ist die Software in der Lage ältere Datensätze zu exportieren und bei Bedarf wieder zu importieren.

Messdaten auswerten

Mit der Grafik-Bibliothek GD erstellt die Software eine Reihe von graphischen Auswertungen. Abweichungen und Trends im Fertigungsprozess lassen sich dadurch schnell erkennen. Die wichtigsten statistischen Kenngrößen werden automatisch berechnet.

Überblick

Programmiersprache: PHP, MySQL

Plattform: Apache, Linux

Schnittstellen: GD-Library; ImageMagick

Know-How

  • Arbeiten mit sehr großen Datenmengen

X-Packed

Windows File Explorer in C++ verarbeitet Einzelbilder zu Clips in der Computeranimation und PostProduction

Eine Filmsekunde sind 24 Bilder. Das sind 24 Einzeldateien im Dateisystem.

Software zur Erzeugung von Bildern am Computer (CGI), wie beispielsweise Autodesks Maya oder Cinema4D von Maxon/Nemetschek legt jedes Bild in einer einzelnen Datei ab. Das Arbeiten mit diesen Dateien auf Dateisystemebene (z.B. Windows Explorer) gestaltet sich dadurch unübersichtlich und mühsam. Allein das Umbenennen eines solchen „Films“ ist aufwändig, muss doch jede Datei einzeln umbenannt werden.

In enger Zusammenarbeit mit einer Münchener Post-Production entstand die Software X-Packed. Sie ersetzt in der Vollversion den Microsoft Windows Explorer vollständig oder arbeitet als „Shell Extension“ als Plug-In in den Microsoft Windows Explorer. Die Software erkennt zusammenhängende Einzelbilder als Bildsequenz und zeigt sie als „Clip-Objekt“ an. Die Anzeige und das Abspielen als Clip, sowie das Konvertieren in andere Bildformate machen die Software zu einem kompletten Tool für den Workflow in der Computeranimation und PostProduction.

Clip Detection

Im Kern der Software erkennt eine „Clip Detection“ die Einzeldateien eines Clips anhand ihres Namens als zusammengehörig und erzeugt daraus ein internes Clip-Objekt. Dieses Clip-Objekt kann – in einstellbarer fps-Geschwindigkeit – angezeigt und abgespielt werden, es kann umbenannt werden und die Dateien können in andere Einzelbild- oder Streamingformate konvertiert werden.

Zum Einlesen der hochauflösenden Bilder ermöglicht die Multithreading-Architektur der Software das parallele Einlesen von Bildern auf mehreren Prozessor-Cores.

Das Einlesen der Bilder kann entweder über die proprietären Lesemodule der Software (BMP, IFF [Maya, Shake], JPG, RLA [3D-Max], SGI, TIF, CT (Mental Ray) geschehen oder über die integrierte Adobe Photoshop Schnittstelle, die beliebige Photoshop- oder AfterEffects PlugIns ansteuern kann.

Clip Erzeugung

Über die integrierte Apple-Quicktime-Schnittstelle können die aus den Einzelbildern bestehenden Clips in QuickTime integriert werden. Alle in QuickTime zur Verfügung stehenden Streamingformate (MOV, MPEG-2, MPEG-4) können erzeugt erden.

Überblick

Programmiersprache: C++ mit MFC

Plattform: Microsoft Windows

Schnittstellen: Adobe Photoshop, Apple Quicktime

Know-How

  • Lesen/Schreiben von 2D-Bildformaten (BMP, JPG, SGI, IFF, TGA, TIF, CT, RLA)
  • Einbindung und Ansteuerung von Adobe Photoshop, Adobe AfterEffects PlugIns
  • Schreiben von Streamingformaten (Video und Audio) über Apple QuickTime
  • Multithreading-Architektur zum Einlesen von Einzelbildern mit maximaler Performance
  • Anzeigen von Einzelbildern in Echtzeit in einstellbarer fps-Rate.

Gute Nacht, Kleine Katze

Aus Druck-Vorstufen-PDFs macht eine CAM-Software in C++ via ProfiNet Daten für die Beleimung bei Kinderbüchern.

Kinderbücher zum Entdecken

Die Seiten von Bilderbüchern für Kleinkinder bestehen aus Kartons, die an ihren Rückseiten stabil miteinander verleimt sind. Wäre es für die kleinen Leser nicht spannend, wenn man nicht flächig verleimen würde, sondern wenn es Aussparungen und Klappen gäbe? Klappen, hinter denen sich Bilder und weitere Teile der Geschichte entdecken ließen?

Solche Bücher ließen sich bisher im Hochlohnland Deutschland nicht kostendeckend produzieren, denn ein selektiver Auftrag des Klebers war bis dato nur in Handarbeit möglich. Und die automatische, flächige Verleimung verklebte die Klappen.

Eine große, überregionale Druckerei beauftragte ein darauf spezialisiertes Unternehmen mit der Entwicklung und dem Bau einer Maschine, die den Kleber auf die Buchseiten selektiv aufträgt und ausgewählte Bereiche ausspart. Damit die Maschine weiß, welche Bereiche ausgespart werden müssen, entwickelte Agent Smith hierfür eine spezielle CAD/CAM-Software.

Modul 1: Lesen der PDF-Dateien der Druckvorstufe und Berechnung von Beleimungsdaten

Druckvorstufen arbeiten – wahrscheinlich in Druckereien auf der ganzen Welt – mit dem Seitenbeschreibungsformat PDF von Adobe. Mit den DTP Programmen Adobe Indesign und Adobe Illustrator erstellt die Druckvorstufe Vektordateien. Sie beschreiben die nicht zu beleimenden Bereiche mit Linien und Splines. Diese Dateien werden im Format Adobe Acrobat PDF gespeichert. Die von Agent Smith entwickelte Software extrahiert aus den PDF Dateien – für die einzelnen Seiten des Buches – die relevanten Geometriedaten und wandelt sie in ein proprietäres Format, aus dem dann Beleimungsdaten für die Maschine generiert werden.

Modul 2: Senden der Beleimungsdaten an die Maschine über Profinet

Druckvorstufe und Produktion sind nicht nur räumlich voneinander getrennt. Ein zweites, von Agent Smith entwickeltes Modul, öffnet die o.g. proprietären Daten und berechnet daraus die Daten für die selektive Beleimung und übermittelt sie an die Maschine. Spezielle Einstellungen des Bedienungspersonals (z.B. Dichte der Beleimung) werden bei der Berechnung berücksichtigt und ebenfalls an die Maschine übermittelt. Software und Maschine kommunizieren bidirektional via ProfiNet in Echtzeit. Zustände der Maschine werden ebenfalls auf dem Industrie-PC von der entwickelten Software angezeigt.

Überblick

Programmiersprache: C++ mit MFC

Plattform: Microsoft Windows

Schnittstellen: Adobe Acrobat; ProfiNet