Resizing in callbacks

BackupUser · Post by **BackupUser** » Mon Sep 23, 2002 1:27 pm

Restored from previous forum. Originally posted by tinman.

Hi,

Is there some specific features of Windows callback functions that they either have to respond within a certain time, or have a limited number of messages they can have stored up at any one time?

There's nothing mentioned in the Win32 API docs I have (that I can see) but I have noticed some strange behaviour of one of my programs when I am running some other CPU intensive programs.

If I resize a window by a large amount very quickly then I get some http://www.david-mcminn.co.uk/files/corrupt_resize.png.

The only thing my code does as the window is resized is that it calculates the new sizes and positions of the gadgets and then moves/resizes them using ResizeGadget(). It works all the time when I don't have the CPU intensive programs running.

Anyone else seen this sort of thing before?

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)

BackupUser · Post by **BackupUser** » Mon Sep 23, 2002 3:52 pm

Restored from previous forum. Originally posted by PB.

> If I resize a window by a large amount very quickly then I get some
> http://www.david-mcminn.co.uk/files/corrupt_resize.png.

Does the corruption happen if you try the example at this post:

viewtopic.php?t=932

If not, then your own resize code is the problem...

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Mon Sep 23, 2002 10:06 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by PB
Does the corruption happen if you try the example at this post:

viewtopic.php?t=932

If not, then your own resize code is the problem...

Not corruption, but if I change a couple of the gadgets to be string and text gadgets, then they disappear while I resize the window.

In fact, that reminds me. I had that same problem before and changed my code so that it redraw all the gadgets during resize. I'll bet that has something to do with it.

I also noticed that it happens even without my CPU intensive program running

Update: Here's some code that shows the effect. I'm pretty sure I asked about this before, but it was to do with button gadgets that time (since this is the same code

Code: Select all

if openwindow(0,400,300,300,140,#PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_MaximizeGadget|#PB_Window_SizeGadget, "Layout Test")

    if creategadgetlist(windowid())

        StringGadget(0,20,22,100,20,"First")
        StringGadget(1,20,46,100,20,"Second")
    
        TextGadget(2, 180, 22, 100, 20, "Third")
        TextGadget(3, 180, 46, 100, 20, "Fourth")
    
        while quit.w=0
            ev.l=WaitWindowEvent()
            If ev=#PB_EventCloseWindow : quit=1 : endif

            If WindowHeight()140
                ; Resize gadgets so they overlap
                ResizeGadget(0,20,44,100,20)
                ResizeGadget(1,20,91,100,20)

                ResizeGadget(2,180,44,100,20)
                ResizeGadget(3,180,91,100,20)
                quit=1
            EndIf
        wend

        quit=0
        while quit.w=0
            ev.l=WaitWindowEvent()
            If ev=#PB_EventCloseWindow : quit=1 : endif
        wend
        
    endif

    closewindow(0)
endif
end

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)

BackupUser · Post by **BackupUser** » Tue Sep 24, 2002 10:35 am

Restored from previous forum. Originally posted by PB.

> Here's some code that shows the effect [snip]

Personally I think you should be checking the #WM_SIZE event like my
example shows, rather than manually checking your window's size for a
change. And use a callback if you want the resize to be real-time.

However, try putting LockWindowUpdate_(WindowID()) before
the Resize commands, and LockWindowUpdate_(0) after them.

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Tue Sep 24, 2002 5:48 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by PB

> Here's some code that shows the effect [snip]

Personally I think you should be checking the #WM_SIZE event like my
example shows, rather than manually checking your window's size for a
change. And use a callback if you want the resize to be real-time.

This isn't my real code, just some way of triggering the resize to show the problem

However, try putting LockWindowUpdate_(WindowID()) before
the Resize commands, and LockWindowUpdate_(0) after them.

Hmm, works fine now - thanks. Guess I better go read what LockWindowUpdate does

However, if that is the only way around this problem, perhaps there should be a sanity warning in the ResizeGadget docs.

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)

BackupUser · Post by **BackupUser** » Tue Sep 24, 2002 5:55 pm

Restored from previous forum. Originally posted by PB.

> Hmm, works fine now - thanks.

No problem.

> Guess I better go read what LockWindowUpdate does

Well, in reality you shouldn't even use LockWindowUpdate to fix the
problem, because there actually isn't a problem with ResizeGadget in
the first place, if coded correctly. Unless I'm missing something...

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Tue Sep 24, 2002 6:02 pm

Restored from previous forum. Originally posted by PB.

> ; Resize gadgets so they overlap

Actually, I just noticed what this comment said... and the gadgets don't
overlap for me when I try your example -- ever. Are they actually
supposed to draw over one another?

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Tue Sep 24, 2002 10:02 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by PB

> ; Resize gadgets so they overlap
Actually, I just noticed what this comment said... and the gadgets don't
overlap for me when I try your example -- ever. Are they actually
supposed to draw over one another?

When I originally wrote that code, that is what the effect looked like. It seemed that as one gadget was resized and moved to a new position it overlapped one of the old gadgets (since the gadgets are moved/resized one at a time obviously). The new gadget got redrawn over the old one (the old one then seemed to keep the imagery from when it was drawn over when it was resized/moved).

The gadgets do not overlap after they have all been changed, only while they are being changed.

It seems that your tip of using LockWindowUpdate stops the gadgets being redrawn immediately after resizing, and so all of them are at their new positions before being redrawn. Therefore no overlap and no corruption.

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 3:09 am

Restored from previous forum. Originally posted by El_Choni.

Are they actually supposed to draw over one another?

Obviously! What a question!

El_Choni

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 10:14 am

Restored from previous forum. Originally posted by PB.

> > Are they actually supposed to draw over one another?
>
> Obviously! What a question!

Well it wasn't that obvious because they don't draw over each other,
which is why I had to ask. If the example was supposed to show the
problem, then it should actually show it... otherwise how can I see
the problem correctly and help?

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 2:41 pm

Restored from previous forum. Originally posted by El_Choni.

PB: I was just kidding, I thought you meant to be sarchastic with your sentence, because gadgets are rarely supposed to overlap.

Just that, bye,

El_Choni

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 4:02 pm

Restored from previous forum. Originally posted by PB.

> PB: I was just kidding, I thought you meant to be sarchastic with
> your sentence, because gadgets are rarely supposed to overlap.

Sorry, I have been a bit tired lately and not thinking properly before
posting. I'll shut up for a while.

PB - Registered PureBasic Coder

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 6:24 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by PB
Well it wasn't that obvious because they don't draw over each other, which is why I had to ask. If the example was supposed to show the problem, then it should actually show it... otherwise how can I see the problem correctly and help?

Are you saying you don't see the corruption when you resize the window? The example really does show the problem, honest

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 8:13 pm

Restored from previous forum. Originally posted by Berikco.

Originally posted by tinman
Are you saying you don't see the corruption when you resize the window? The example really does show the problem, honest

Tinman, i see the problem once, when i let my virusscanner run.
Old gadget whas still there.
Tried many times, clould not reproduce second time.
Got maybe something to do with CPU speed or Display driver.

Regards,

Berikco

http://www.benny.zeb.be

BackupUser · Post by **BackupUser** » Wed Sep 25, 2002 10:06 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by Berikco
Tinman, i see the problem once, when i let my virusscanner run.
Old gadget whas still there.
Tried many times, clould not reproduce second time.
Got maybe something to do with CPU speed or Display driver.

It will only happen once each time the program is run (since the gadgets are only resized/moved to 1 new position). The effect should be repeatable every time you run the example, or it is here anyway.

I doubt it has anything to do with CPU speed. It might be due to the display driver. It might be a bug in Windows98 that is fixed on later versions. It might even be a bug in PureBasic's default message handling code.

But thanks to PB I know how to stop it happening

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.30)