because iczelions gdi tutorials where not correct
and my examples in hutchs masm package simply
wrong i decided to release this stuff again... now
it's very small, simple to understand und of course
bug-*free*

i saw a couple of skinning tutes in the net based
on my work... mh what can i say, i wouldn't shuffle
those windows in 2k :grin:
Posted on 2002-04-23 08:25:24 by mob
Mob,

This one works fine on my win95b but then so did the last one. What is the difference ? Is it just tidier code ?

Regards,

hutch@movsd.com
Posted on 2002-04-23 18:59:08 by hutch--
the last one don't work with 2k platforms... just shuffle
the window around and see what happens, the whole
pallette seems to be f**ked up... the difference? in this
version i do not respond to WM_PAINT at all. because
the backgroundpic is already defined in the window-class
WM_PAINT causes strange effects... the key was
WM_ERASEBKGND... now it works fine. i rewrote it cause
i got a couple of mails describing the problem thats all :)
Posted on 2002-04-24 03:19:15 by mob

.ELSEIF uMSG == WM_PAINT ; MH, I HAD STRANGE ERRORS WITH THIS
; ONE. I STILL DON'T KNOW WHY BUT IF
; YOU LET WINDOWS DO ALL THE GDI STUFF
; WITH WM_PAINT YOU'LL GET A BAD SURPRISE
; WHEN SHUFFLING THE WINDOW AROUND...


When I move the window (NT sp 6.0) I get a weird erased background look (if I move the window across and open folder the items disappear for a second in that folder)... Not sure if this was the problem you were trying to fix

Sliver
Posted on 2002-04-24 19:48:33 by Sliver
i hope you meant *after* you let windows do all the
wm_paint stuff... if thats the case, yeah, i get the same
results then... thats really strange i think but in my
opinion thats because i defined the bgpic in the window-
class, that means the background must only redrawn
if the app gets a wm_bkgnderased, not on every wm_paint
because this causes overdrawing effects. this seems
be be a general problem because you also can draw
the background yourself (like in iczelion & hiro tutes)
but even then there are drawing problems.

so if one uses wm_bkgnderased for the actual background
and wm_paint for the controls and/or other grafical
elements everything should be working fine... i hope
so...

oh and if you meant the effect when you shuffle the
windows across for example the iexplorer window... thats
normal... it has something to do with the specific windows
paint-msg processing... try it with winamp (with a
transparent skin!!!), you'll get the same effect but 100x
more worse... it also has something to do with the
complexity of the shape, this one in the zip-file above is
*very* complex so it will take longer to erase the
background, but if you just use simpler shapes like
rounded edges you won't even notice these erasing
effects in the most cases...
Posted on 2002-04-25 03:44:48 by mob
look at this... i choosed a very simple shape and
i don't recognize any redrawing effects now...
Posted on 2002-04-25 04:22:23 by mob
hi..

nice code here... but i get some problems with my messagebox.. it appears behind the bmp :\
any help ?
Posted on 2003-10-14 15:37:09 by SlashZero
i didn't touched a single asm command in months now but
if you could clearly state whats your problem i could probably
help you out. examples aren't a bad thing either...
Posted on 2003-10-15 11:37:00 by mob
Greetings mob, I conducted an experiment with your code using double-buffering instead:


.ELSEIF uMSG == WM_PAINT
INVOKE CreateCompatibleDC, NULL
MOV cdc, EAX

; Use double buffering here ------>

INVOKE CreateCompatibleBitmap, hdc, PICTUREW, PICTUREH
MOV bdc, EAX
INVOKE SelectObject, cdc, bdc
mov hOld, EAX
INVOKE BitBlt, wParam, 0, 0, PICTUREW, PICTUREH, cdc, 0, 0, SRCCOPY
INVOKE SelectObject, cdc, hOld
INVOKE DeleteObject, bdc

INVOKE DeleteDC, cdc


It appears to work just as well as your method (on W2KSP4), but at the expense of additional code.
Posted on 2003-10-17 19:28:38 by Poimander
mob, I discovered using a double buffer doesn't work after all even if you use it to process WM_ERASEBCKGND. I was trying to illicit further discussion. In anycase it is experimentally evident that WM_ERASEBCKGND requires a fast routine to update the screen otherwise you end up with the same distorsion problem. Your technique is truely a sound one. Thanks for sharing it with us.
Posted on 2003-10-21 16:10:50 by Poimander

mob, I discovered using a double buffer doesn't work after all even if you use it to process WM_ERASEBCKGND. I was trying to illicit further discussion. In anycase it is experimentally evident that WM_ERASEBCKGND requires a fast routine to update the screen otherwise you end up with the same distorsion problem. Your technique is truely a sound one. Thanks for sharing it with us.

no problem. yeah it gets quite weird, i tried out everything but this was the
only way that worked well, well it's only a line so this became a standard for
me from there on. as i am a more or less a defunct member of this community
(because of my work) it's kinda hard for me to discuss, sorry. i just don't want
to get in touch with computers in my freetime, i'm pretty fed up when i leave
work and have plenty of other things to do then :)
Posted on 2003-10-22 10:57:51 by mob
Since i found a good source of inspiration in mob's example, here is what i think would improve greatly the performance of this custom shaped window algo:
do not create the memory DC at every WM_ERASEBCKGND & WM_PAINT message, instead create one at WM_CREATE and only blit it when needed.

Eugen
Posted on 2003-12-04 21:17:49 by Eugen