I'm working on a largely win32 gui based app, and as the project gets larger, I'm finding it harder to navigate the increasingly larger main source file. Does anyone have any tips on breaking up windows code? My first thought was 1 source/header per window class, but I'd like some more experienced windows programmers to chime in. In the mean time I plan to crack open Petzold's book and see if I can glean anything from the master.

Not sure what language this is, but if it's C++, then I've experienced it's good to wrap everything what the Win32 API is to proper exception handling. It's a bit tedious work at first, but pays off whenever you have more than two callsites for some win32 function.

If this is C++, then first natural step is to place one class per source/header, unless there's some good reason not to. Most likely this is an issue of layering classes from high-level to low-level.

I'm interested about what Petzold's book you're reading (I hope its not +10 year old book). I'm not fan of his earlier works, and now looking the bibliography it doesn't seem promising.

I believe it's the 6th edition, so yes likely 10 years old by now. But still useful as a reference when dealing with raw win32 in c++.

Book might be useful when dealing with Win32, but surely not when dealing with C++. Win32 is a C API. 10 years ago it was all clumped together as C/C++. C++ is totally different language than C.

Anyway, that was just a side-comment in my post.

I'm finding it harder to navigate the increasingly larger main source file.

Usually my main.cpp file is just a few lines. Then there's program.cpp or application.cpp. After that it gets more domain specific, high level class what the application does. Then there might be 10 more layers all down to the lowest level classes and functions. It all depends how big the program is. You should introduce higher level abstractions whenever the program grows too big, or if you know the requirements beforehand you can try to do it prematurely (beware of overengineering).

I'm sure if you can give an example, many of us can give our thoughts.

1 source/header per window type is a good start, but you should really be thinking about how to organize the data so that everything that needs to read or change the data is able to do so appropriately. After that, good project/file organization should reveal itself intuitively.

For example, I recently made a 2D map editor and I organized it like this: Each panel/window gets it's own file, but there's a central data structure that all the panels/windows have access to which provides all the functions to manipulate the map. The data structure itself is split up into multiple files logically based on the type of data being modified (for example there's one file for all the tile manipulation functions, another file for all the entity manipulation functions).

Work in 'Show All Files' (button in Solution Explorer), which allows you to work with real folders instead of the virtual ones.

Virtual folders (also called filters) seem to be standard in C++ IDEs, not only Visual Studio. This way you can organize the sources "logically" while preserving a flat real folder structure. To some degree it's a matter of taste, but e.g. I prefer having all .h of a project in one folder, so I don't have to deal with multiple include paths or paths in the #include directives.