Possible bug in System.Windows.Application: Windows property

I'm trying to access the collection of windows that an application
contains using the Application.Windows property (returns a collection of
type WindowsCollection). It seems that this collection only returns
windows that are manually instantiated in C# code, but is missing the
window set as the startupURI for the Application. Take the following
example (I haven't displayed the window code here only the Application
code, any generic window will do):

MyApp.xaml:
<Application x:Class="WindowScaler.MyApp"
xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
StartupUri="Window1.xaml"
>
<Application.Resources>

</Application.Resources>
</Application>

MyApp.xaml.cs:

public partial class MyApp : Application
{
private const int NUM_WINDOWS = 2;

public MyApp()
{
// launch a number of windows
for (int i = 0; i < NUM_WINDOWS; i++)
{
Window1 w = new Window1();
w.Name = "Test Window" + i;
w.Show();
}


// Print out window names
foreach (Window w in Windows)
{
Console.WriteLine("Window Name: {1}", w.Name);
}
}
}

I'd expect this to output 3 window names to the console, one for the
window listed in the Application's StartupUri and the additional windows
created in the loop. However, this is what we get:

Window Name: Test Window1
Window Name: Test Window2

The one from the StartupUri is missing. Is this a WPF bug or by design?

Additionally, what if you don't really want to specify any startup URI
window, because you want all of your windows created through C# in a
consistent manner? Right now I get build errors when I don't provide
the StartupURI...

Thanks,
Jason

Re: the first problem you describe (the startup window being missing from
the Application's "Windows" collection), I believe the problem is the time
at which you are examining the application's "Windows" property.

I tested a simple application with a single window defined in XAML and
declared to be
the StartupUri of the application.

If I examine the application's "Windows" property while the program's flow
is in
the Application's constructor method -- which is what your sample code is
doing --
then indeed the "Windows" property does not include the startup window.

But that's because the examination is being done too early...

If I examine the application's "Windows" property when the flow has moved
into
the startup window's constructor method, then I *do* see the startup window
present.

So I believe this is strictly a timing issue -- the startup window is not
yet present when the
program's flow is still in the application's constructor.