A Failed Experiment - Part One

A Story About Overengineering, Curiosity, and Debugging Reality

It had been a long time since I last wrote a blog. A lot has changed since then, and I found myself struggling to return to coding and writing - like someone trying to escape quicksand, where every movement feels heavier than the last.

As the title suggests, this post will be a little different.

Most people write about what went right in their work. Today, I want to do the opposite. I’m sharing a failed experiment - partly to reduce my ego (consider this a public service announcement to my own overconfidence), and partly to remind both myself and others that mistakes are not only normal, they are necessary for learning.

Alright, enough philosophy. Let’s dive into the technical aspects.

One day, while working on yet another half-finished project (you know, the kind of project that exists mainly to remind you how many other unfinished projects you already have) I reached a point where I needed to use theme resources.

The requirement sounded simple: I needed those resources to be dynamic and accessible from code-behind, not only from XAML.

And that’s where the problem appeared.

The only official way to use ThemeResources was through XAML. That limitation pushed me to write a proposal requesting support for accessing theme resources dynamically from code. You can see it here: GitHub Issue microsoft-ui-xaml/issues/9464.

… and yes, after checking the date, I realized I wrote that proposal two years ago. Apparently, time moves faster than feature requests - or maybe my proposal entered a long-term archival program also known as “we’ll look into it someday.”

After a lot of testing, experiments, and questioning my life choices, I eventually discovered a workaround: using a lightweight style that holds the ThemeResource and applies it to the control indirectly.

The workaround is documented here: GitHub Comment microsoft-ui-xaml/issues/9464.

This workaround, however, came with its own problems.

What happens if we try to apply it to a FrameworkElement that doesn’t even expose a Style property? Or what if we simply want to modify theme resources without touching XAML at all?

Yes, I know what you’re probably thinking right now: “WTF is Zakaria talking about?”

Honestly… nothing revolutionary. Just layers of abstraction - maybe unnecessary today, but possibly useful to someone, somewhere, someday. Or at least that’s what I told myself at 2 a.m. while convincing my brain this was still a reasonable idea.

So I created a small project called NoXamlTheme. I was genuinely excited because, for a moment, I thought I had solved the problem.

Until… I hit another wall.

At that point, the only way forward was to dive into the Microsoft.UI.Xaml source code itself to understand what was really happening under the hood.

And since I’m currently fighting my way back into both writing and coding, this feels like a good stopping point for today’s blog.

I’ll leave the code here if you’re curious to explore it: NoXamlTheme GitHub Repository.

I’ll explain the details in Part Two.

Bye.