Windows XP SP3 x32
Geforce 6800GT
Blender 2.56 beta official and r30581, r33965, r34050
1) Ctrl+R loopcut the object then slide it into position, click to confirm
2) Now I can't minimize/maximize/close the blender window using the Windows titlebar icons
If I open the UserPrefWindow using Ctrl+Alt+U, it opens, but does not take any input and can only be closed using the taskbar
It does not even help if I undo the cut / enter object mode / add an additional multicut / delete the object / edge slide / Esc / ...
3) The effect only ends if I minimize/maximize the window via the taskbar or if I toggle fullscreen mode. After that it acts normal again until I do the next loopcut.
This does only occur if doing one loopcut, if I do multiple, everything behaves like it should, so perhaps blender somehow stays in sliding mode ?
This problem seems to reach back at least as far as r30581, but it does not occur on Ubuntu 10.04, so I tagged it OS-specific.
Description
Event Timeline
A similar issue occurs with Grease Pencil from r.34051 onwards when 'Use Sketching Sessions' is enabled.
What these two operators have in common appears to be the use of ED_area_headerprint() and that they are both modal operators (though their return codes for the modal() callback are different). Commenting out the code which makes use of ED_area_headerprint() in the Grease Pencil code (line 1639, or the call to gpencil_draw_status_indicators() in gpencil_draw_modal()) makes this problem go away.
Windows Vista.
---
Assigning to self for now to see if it's an easy Blender-side problem or whether it's more of a low-level Ghost bug for jesterKing :)
Scratch that... I can't seem to replicate the Grease Pencil problem anymore, but I can replicate the issue with loopcut. Reassigning to jesterKing for further investigations...
I can reproduce with official build, but not with r34059. Please try this or newer revision and report back.
ED_area_headerprint() is used all over, like for every transform action.
How the window itself (i assume that's the titlebar?) becomes inactive? That's only possible on ghost library level... or does the reporter mean the Blender top bar (Info)...
We're talking about the system-level window, indeed. In official build indeed the minimize, maximize and close buttons don't respond after loopcut, but with r34059 I can use these buttons normally.
Sorry, but I still have the problem in "Blender 2.56 (trunk) rev34059 32bit + patches + contrib & external add-ons + API Doc" by filiciss and my own r34063 build.
Ok, you can work around the problem by maximizing blender using blender's own maximinzing function. Then go back to normal and you have control over your title bar again.
Even more simpler work around: take out the focus from the blender window, eg. LM-click on other window or desktor or windows taskbar. Then resume to your work!
Additional detail: just noticed that this bug only occurs using the mouse, when doing the Loopcut with my Wacom digitizer pen, the buttons stay functional.