I'm basically having the same problem as this guy. The thing is, I want there to be a certain number of rectangles on the screen, depending on the screen size/resolution. Now the first comment on that question says "creating UI elements in procedural code in XAML-based technologies is discouraged, cumbersome, probably a bad idea, and just plain wrong".
So is there another way in which I can achieve my goal?
One way I can think of would be to have a minimum of 3x3 rectangles, but add UI code for 6x3 and make the last 3 rows visibility collapsed. In app load, I could figure out if I could fit more rows, and selectively make them visible. I'd still like to know if there is a cleaner approach.
I won't paste my code here since it's very similar to the linked question, but I will if asked, and it helps to clarify things a bit.
I understand the general sentiment that a XAML app should declare as much of the UI as possible in the XAML. But I also believe it's possible to be too dogmatic about things. If one genuinely has a scenario where the layout of UI elements one would otherwise select during design-time is unknown until run-time, then why not populate the UI at run-time based on that information?
Barring some clearly-written and compelling argument detailing why run-time creation of UI elements is actually bad, I'm going to keep on doing it when appropriate. I will happily design as much of the UI in advance, but if there are parts that depend on information known only at run-time, I will write code to do that.
A person can wind up with a lot of really awful code and maintenance hassles trying to shoe-horn a specific design goal into some constrictive, prescriptive dogma.
I went ahead and posted an answer to the question you've linked to. I don't know if that's actually something you needed, but if so you can look there. It seems to me that the main question here is "is it really so wrong to configure my UI at run-time?" and my answer to that is, as you can see, "no, not necessarily".