Thanks for the sample project. I reproduced this straight away, and it's fixed for the next release.
What was happening: on a page with lots of controls and handlers, every designer change made Studio re-scan the entire page source once per control event. Your page has 24 controls that between them own around 380 events, so that's several hundred full re-parses of the same file (twice over!) before any useful work happened. Worse, the Add Event Handler dialog then repeated that entire cycle once for each selected event. Fifteen selected events times roughly a second of redundant work each is your minute of frozen UI. Nothing is wrong with your project; the cost just grew with controls × events × existing handlers, which is exactly what your page exercises.
The fix:
- The page source is now parsed once per operation instead of hundreds of times, and a duplicated preparation pass that ran on every change is gone.
- The Add Event Handler dialog now adds the whole selection as a single operation - near-instant on your project, and it comes back as one undo step rather than one per handler.
- Opening the project benefits from the same fix, so busy pages like yours load much faster too.
On your sample project, adding all fifteen RadioButtonGroup events drops from around a minute to effectively instant, and the behind-the-scenes work per edit fell from roughly 900 ms to 50 ms.
I also gave the desktop window designer the same treatment, since it had a milder version of the same problem on windows that use subclassed controls.
Tracked as bug #1539 (Web) and bug #1540 (desktop), both fixed for the next release. Thanks again for the clear report and the project - it made this easy to run down.
