Well it's been a long time since I joined and have hardly posted a thing. Work takes up too much time and RL commitments are time consuming - not much time to do anything else.

Anyway - I've attached my first program that I've done that messes with Bitmaps and DC's. It puts an image on the background of a treeview.

The concern I have is the main window paint. I use my own painting proc to remove flicker (when resizing or when a node makes the scroll bards appear) from the treeview, but I've had to use 2 Bitblts to complete it (see the code for more detail)
1) To paint below the tree view
2) To paint anything on the right hand side of the treeview
This leaves the treeview window unpainted (updated on it's own WM_paint proc)

The other problem lies with vertical scrolling on the treeview. I've hard coded a value in the source code for vertical increments (see the code for more detail) need some suggestions on how to remove this.

Anyway, comments would be appreciated - and be gentle with me :)

PS It uses the latest Masm includes and includes the radasm project
Regards

Taff
Posted on 2003-06-05 06:20:05 by taff
.ELSEIF uMsg==WM_PAINT
;==================================
;To reduce flicker do our own drawing
;==================================
invoke ourPaintProc,hWnd,uMsg,wParam,lParam
mov eax,1
ret


Why you are returning 1 ???


As i think it's good to use this one "mov wc.hbrBackground,0" when you dont need to show window background.

BTW. This is great at last someone made this so i can make proper working background in my prog. Thx. :)
Posted on 2003-06-05 08:26:09 by AceEmbler
Just read this from the win32 Programmers reference

Return Values

An application should return zero if it processes this message.


maybe I should return 0, but to be honest I'm still learning this stuff. The reason I put it in was to let windows know I had taken care of the painting.

I've justed tested it with both values and it doesn't seem to make any difference - maybe someone else could shed some light

Glad I could help

Taff :)
Posted on 2003-06-05 08:45:18 by taff
I think its pretty cool!

Great work! I havent checked out your code yet, but its use shows no problems to me...

Im impressed!
:alright:
NaN
Posted on 2003-06-05 21:54:53 by NaN
Damn - couldn't remove the previous file, so if a mod would be so kind and remove it for me :grin:

Some stuff fixed that was pointed out by QvasiModo.
The cause - I was pasting a Bitmap into a treeview sized DC, instead of making the DC the same size as the bitmap. This was causing a problem when the image was bigger than the control.

The treeview now resizes with the main window, so no need for a paint proc for the main window (it's still there just commented out)

Now uses a jpeg in the resource file rather than a bitmap (saves a lot more space in the final exe.)

There's also 2 different colour child nodes and a node with a different font - experimental :)


Taff
Posted on 2003-07-03 10:14:20 by taff
By the way, I have tried it in Win98 and the bitmap seems to be converted to 16 colors when the BitBlt SRCAND flag is used, but not with SRCCOPY (that, sadly, is can't be used in this example). Does that just happen to me? I'd like to read some comments on this algo working on different platforms...
Posted on 2003-07-03 13:30:24 by QvasiModo
Looks fine on my Win98SE (with most rescient service patches):
Posted on 2003-07-03 21:24:43 by NaN
Yes, I have also tried it in a friend's Win98 today, and it worked fine... must be a bug in my Windoze... :-P
Posted on 2003-07-04 19:12:53 by QvasiModo
On XP I seem to be having the same problem as QvasiModo.

But great work, very impressive.
Posted on 2003-07-04 20:26:41 by Eóin

QvasiModo:
I'd like to read some comments on this algo working on different platforms...


Seems to work just fine, here (XP Pro SP1).

Very nice, and very cool!

Jeff
Posted on 2003-07-06 04:03:12 by jayte
Also works fine on my XP Home SP1.
Actually wth is the difference between home and Pro?
(hehe not to start another thread, it just occured to me :) )
Posted on 2003-07-06 08:00:48 by RobotBob
QvasiModo
must be a bug in my Windoze
You use non classic scheme, i.e. default color background for treeview control is not WHITE.
!!! BitBlt(..., SRCAND) -> ANY_COLOR and WHITE == ANY_COLOR, ANY_COLOR and NO_WHITE == ???

taff
other possible problem: default item color (BLACK) on dark image
Posted on 2003-07-07 01:34:38 by P2M
P2M, you're right, I'm not using the default color scheme... I've changed the background color to a light gray instead of white. Is there any way to tell the treeivew control NOT to use the current scheme colors, but the ones we want it to use? That way the algo would work on any color scheme...
Posted on 2003-07-07 09:43:57 by QvasiModo
ya. basically format the DC's background color to white before your do the SCRAND copy by bitblt.

(With out directly studying the source this would be my quick fix answer ~ could be wrong tho... )

:NaN:
Posted on 2003-07-07 14:34:45 by NaN
The problem is you have to BitBlt AFTER treeview has done it's painting, so I'm not sure it would work if you set the DC background color before calling the treeview's window proc... probably it will just change the DC color back...:confused:
Posted on 2003-07-08 18:30:09 by QvasiModo
NaN:
I think I got what you meant, and I've tried, but it didn't work... perhaps I did something wrong?

So I commented it out, and tried something else:


;==================================
; QvasiModo:
; If the default background isn't
; white, paint it white (should
; work fine unless it's too dark,
; and font antialising is on)
; It's just proof of concept,
; THIS NEEDS OPTIMIZING!
;==================================
invoke GetSysColor,COLOR_WINDOW
.if eax != 00FFFFFFh
push ebx
push esi
push edi
mov ebx,eax
invoke GetClientRect,hWnd,addr rect
xor esi,esi
.repeat
xor edi,edi
.repeat
invoke GetPixel,memTVDc,edi,esi
.if eax == ebx
invoke SetPixel,memTVDc,edi,esi,00FFFFFFh
.endif
inc eax
.break .if zero?
inc edi
.until edi > rect.right
inc esi
.until esi > rect.bottom
pop edi
pop esi
pop ebx
.endif


Well, it works allright... but it's taking it 3 seconds to paint :grin:

It could be optimized by accessing the bitmap directly, I've seen something like that on the board, but I'll have to look deeper into it...

EDIT: I deleted the attachment to save space (34 downloads). Seemed pointless to keep it since it was a buggy version...
Posted on 2003-07-11 10:32:25 by QvasiModo
You know, I have a couple of exams news week, I should be studying algebra instead of coding... but ASM is like drug, once you start, you can't stop... or was it Pringles chips? whatever :grin:

So, I've improved it, now it accesses the bitmap's bits directly, and runs well... it's just a little bit slow, but you won't notice unless you maximize the window. Does anybody know how to optimize it further?

Ok, that's it, back to studying now... wish me luck :)
Posted on 2003-07-11 13:38:57 by QvasiModo

You know, I have a couple of exams news week, I should be studying algebra instead of coding... but ASM is like drug, once you start, you can't stop... or was it Pringles chips? whatever :grin:

So, I've improved it, now it accesses the bitmap's bits directly, and runs well... it's just a little bit slow, but you won't notice unless you maximize the window. Does anybody know how to optimize it further?

Ok, that's it, back to studying now... wish me luck :)


Yes, ASM is a drug (binary euphoria). Actually, your method with the GetPixel was a simular method I also tried (and found it was insanely slow). Better bet, is to get the bitmap structure and the bitmap raw data, handle the work yourself. Infact, when it comes to doing 24 bit data, GetPixel is far slower (since the overhead in cycles to "Get a Pixel" in any depth, but if you make optimized routines for each depth, you can rip through the bitmap yourself (A LOT faster).
Posted on 2003-07-11 14:07:11 by FunkyMeister
Ok, I'm back (for a while) into this...

FunkyMeister: Yes, raw bitmap access seemed like the best solution to me too... my last source did that. In theory, you don't need to support all different resolutions, since you can specify wich format you want in CreateDIBSection. So all access is always done in 32 bits resolution (even when the screen resolution is different).

Furthermore, I thought it was even better to simple do ALL painting with raw bitmap access. Since I had to change a lot of things, I decided it was better to simple recode the whole app (besides, it's a great way of showing off :grin: ). Mine still doesn't support scrolling the background, but I'm working on it :)

taff: I think the "hardcoded value" could come from the scroll range... I'm still learning about scroll bars, but if I find out anything I'll post it here.

Another thing I found out was that, when accessing 32-bit bitmaps directly, sometimes the highest byte is not cleared (although WIN32.HLP says it should be). I found this happens only in a small rectangle in the upper left corner of the treeview control, and the size of this rectangle is the item height. Weird... :confused:

Well, here it is, now it also supports 4 different backgrounds, you can change them through a context menu that appears when you right click on the background (NOT on an item).
Posted on 2003-07-14 16:19:47 by QvasiModo
I actually avoided using CreateDIBSection, due to the variety of problems it has with Win9x. The good ol' error 87. Microsoft has admitted there is a possible problem (and I've run into it under low resources) and there is no solution. If I'm not mistaken, CE has no CreateDIBSection.
Posted on 2003-07-14 16:46:20 by FunkyMeister