Prev: Creating a Custom Class for a modeless dialog popup
Next: Screen Capture of Windows Media Player is distorted
From: David Given on 3 Feb 2010 16:50
By default Windows handles sizing and moving using a modal event loop.
That is, when the user presses the mouse button on the window border, a
separate event loop is started up that handles the sizing or moving.
It's only when the user releases the button that the application's own
event loop is returned to.

Unfortunately the app I'm porting has to have control over its event
loop. Unless flow of execution goes through the event loop, it doesn't
do stuff like redraw. Which means that right now, the app doesn't redraw
while being resized.

It would actually be easier for me to write my own window resize code
than it is to rearrange the app. So, before I do this --- is there any
way to persuade Windows *not* to use a modal sizing event loop, and
instead to use the application's normal event loop instead?

This is all with low-level GDI and Win32 calls --- no frameworks.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
From: Seetharam on 3 Feb 2010 17:16
When in a modal resizing loop, don't you receive the WM_SIZING or
WM_WINDOWPOSCHANGING messages?

-Seetharam

From: David Given on 3 Feb 2010 17:35
On 03/02/10 22:16, Seetharam wrote:
> When in a modal resizing loop, don't you receive the WM_SIZING or
> WM_WINDOWPOSCHANGING messages?

Yes. But I can't return them to the app because I'm no longer in the
app's event loop, I'm in a nested event loop belong to something deep
inside Windows.

The application's event loop looks something like this:

for (;;)
{
event = getevent();
if (event == redraw)
redraw();
}

The problem is that because getevent() won't return until the user lets
go the mouse button, the application never receives the redraw event.

I can't change this logic; it's dictated on me by the way the
application works (it's a cross-platform thing). All I can do is change
my implementation of getevent().

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
From: Random on 3 Feb 2010 18:07
On Feb 3, 2:35 pm, David Given <d...(a)cowlark.com> wrote:
> Yes. But I can't return them to the app because I'm no longer in the
> app's event loop, I'm in a nested event loop belong to something deep
> inside Windows.

You should be able to call your application's redraw() function in
response to WM_PAINT inside of whatever function you're passing into
RegisterClass for the window procedure.

> The problem is that because getevent() won't return until the user lets
> go the mouse button, the application never receives the redraw event.

There's no way to change this logic. Also worth noting: This is not
the only time Windows will spin up a new even loop inside your event
loop. MessageBox() is a trivial example, but there are others.
You'll need to special case those as well if you're not handling
WM_PAINT in a normal Windows-ish way.

From: David Given on 3 Feb 2010 18:20
On 03/02/10 23:07, Random wrote:
[...]
> You should be able to call your application's redraw() function in
> response to WM_PAINT inside of whatever function you're passing into
> RegisterClass for the window procedure.

No, I can't. The application is not arranged around a call-out
structure, where the event loop calls into my business logic; it's
arranged around a call-in structure, where the business logic explicitly
asks for events when it's ready for them.

[...]
> There's no way to change this logic. Also worth noting: This is not
> the only time Windows will spin up a new even loop inside your event
> loop. MessageBox() is a trivial example, but there are others.
> You'll need to special case those as well if you're not handling
> WM_PAINT in a normal Windows-ish way.

Hm.

I did get one suggestion from a friend that I may find it easier to use
two threads: one which runs the Windows event loop, and one which runs
the application event loop. That way I'm not restricted by whatever
weird and wonderful things Windows is doing with its event loop. My
first reaction is that that would turn into a nightmare of
synchronisation, but it does sound like it might be necessary.

I don't suppose there's any easy way of doing synchronous RPC between
two event loops, is there?

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
 |  Next  |  Last
Pages: 1 2 3
Prev: Creating a Custom Class for a modeless dialog popup
Next: Screen Capture of Windows Media Player is distorted