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.


Where can I find out about this problems with CreateDIBSection? And does Ce have any other of the DIB APIs (like GetDIBits)? I hope so, or I'll have to skip using a background at all under CE... :mad:
Posted on 2003-07-15 07:51:52 by QvasiModo



Where can I find out about this problems with CreateDIBSection? And does Ce have any other of the DIB APIs (like GetDIBits)? I hope so, or I'll have to skip using a background at all under CE... :mad:


It maybe GetDIBit that doesn't exist, I can't remember, know it's atleast one of those two that doesn't.

I believe it is GetDIBits now, since I was using it, but CreateDIBSection was failing with an "Invalid Handle" (#87) on Win9x systems. See this reference for information on it:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q227617

If you can, avoid the GDI DIB code completely, it's too flakey under Win9x and some versions of Me.

From Windows CE documentation,

"For 16bpp or 32bpp non-palettized images, the color table must be three entries long; the entries must specify the values of the red, green, and blue bitmasks. Also, the biCompression field in the BITMAPINFOHEADER structure should be set to BI_BITFIELDS. BI_RBG is not supported for these bit depths."

Something for you to think on there.
Posted on 2003-07-15 09:57:29 by FunkyMeister



It maybe GetDIBit that doesn't exist, I can't remember, know it's atleast one of those two that doesn't.

I believe it is GetDIBits now, since I was using it, but CreateDIBSection was failing with an "Invalid Handle" (#87) on Win9x systems. See this reference for information on it:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q227617

If you can, avoid the GDI DIB code completely, it's too flakey under Win9x and some versions of Me.

From Windows CE documentation,

"For 16bpp or 32bpp non-palettized images, the color table must be three entries long; the entries must specify the values of the red, green, and blue bitmasks. Also, the biCompression field in the BITMAPINFOHEADER structure should be set to BI_BITFIELDS. BI_RBG is not supported for these bit depths."

Something for you to think on there.


Well, I guess I'll have to update my sample app... luckily getting support for CE is not that hard :)
However that GDI bug you pointed out is quite a problem... I was thinking of coding an alternative paint routine in case the window background color is 00FFFFFFh, using BitBlt only... and if my CreateDIBSection algo fails, use the "standard" one. Of course, if CreateDIBSection fails and the background color is not white, then the background would be always disabled, but I can't do anything about it :mad: .

I have Win98, and I never experienced any problems with CreateDIBSection, so I guess it's not such a common bug. The treeview control is not going to be 5000x5000 pixels, anyway :grin:
Posted on 2003-07-15 10:11:50 by QvasiModo
FunkyMeister: I've fixed the CreateDIBSection problem (now it won't crash if CreateDIBSection fails), but I didn't code an alternative painting routine in case th DIB calls fail. Could anybody test this on CE?

I have also added support for non fixed background (that is, now the background is supposed to scroll with the text). I say "it's supposed" because it actually scrolls FASTER than the text. :confused:

It's still a cool effect, too bad I have NO IDEA of why that happens, it's 100% voodoo programming :grin:

It also has a nasty looking bug, a black line that appears from from left, at the bottom of every "tile" of the background (I'm attaching an image that shows it). The vertical scrolling works fine, the problem's just in the horizontal scroll. Does anybody know why could this happen?

taff: I got rid of the hardcoded value. Instead, I calculate the scroll position from the scroll range and the size of the control. The value 16 was probably hardcoded in comctl32.dll too, so it was safer not to use it (you never know when Microsoft is going to change it).

Should work fine... but then again this could be the cause for the horizontal scroll bug. :confused:

EDIT: Deleted the attachments... to buggy :grin:
Posted on 2003-07-16 16:01:50 by QvasiModo



Well, I guess I'll have to update my sample app... luckily getting support for CE is not that hard :)
However that GDI bug you pointed out is quite a problem... I was thinking of coding an alternative paint routine in case the window background color is 00FFFFFFh, using BitBlt only... and if my CreateDIBSection algo fails, use the "standard" one. Of course, if CreateDIBSection fails and the background color is not white, then the background would be always disabled, but I can't do anything about it :mad: .


Actually, avoiding the CreateDIBSection and doing the work yourself would make it faster in the long run anyways (since the CreateDIBSection has a good deal of C in it). You can also get a better result if you do the work yourself, since you'll use less memory in the process.



I have Win98, and I never experienced any problems with CreateDIBSection, so I guess it's not such a common bug. The treeview control is not going to be 5000x5000 pixels, anyway :grin:


Actually, open Paint up, pull in a few BMPs with it, open other programs up, get your resources all mangled up (after a few hours of use), with the paint programs, your CreateDIBSection will bomb. Did on me earlier today after about 4 hours of programming. Only way out was to reboot. Besides, they say 5000 x 5000 isn't always the size. I was trying to use createDIBSection on a 1280x1024 picture size, failed. Now that's not all that non-standard. Essentially, if the machine has been used a lot, contiguous memory chunks aren't going to be easily obtainable (not in ram ones anyways), making the CreateDIBSection unreliable at best. Effectively, the 87 error means it couldn't get a valid handle of a memory address for the bitmap you need.

As for your scrolling horizontal, are you taking into account the fact that horizontally, pixels typically 4:3 scaled? Just a thought.
Posted on 2003-07-16 19:47:19 by FunkyMeister

As for your scrolling horizontal, are you taking into account the fact that horizontally, pixels typically 4:3 scaled?

I'm not taking it into account... actually I have no idea of what you mean :grin: I'm new in GDI, I'm taking on this problem mainly to learn, so feel free to suggest (and criticize ;) )

Well, I've solved all the problems, except that text is still scrolling at a different speed (it must be the scaling problem you're pointing out).

By the way, I deleted my previous attachment.
(I can't believe it had SO many bugs in it... it must be my new record :rolleyes: )
Posted on 2003-07-17 12:34:01 by QvasiModo


I'm not taking it into account... actually I have no idea of what you mean :grin: I'm new in GDI, I'm taking on this problem mainly to learn, so feel free to suggest (and criticize ;) )


You need to go through your GDI work, anything you create (Object) in ANY DC, keep the original that it returns for later return, even if it's blank (because it may not be, even if it's YOUR DC). Reason: Your program crashes GDI, because your resources aren't being properly unloaded.



Well, I've solved all the problems, except that text is still scrolling at a different speed (it must be the scaling problem you're pointing out).


Scaling IS what you need to do. It works (or looks like it's working fine) in vertical scroll, but put the treeview on a SQUARE pixel display output and it will work in both directions. Put it in a 3:4 ratio and Vertical scrolling will race. The thing is, your scrollers are percentages of the full amount, what you need to do is this:

The "Math" looks like this:

OffsetPercentage = ( ScrollerPos / ScrollerMax ) * 100

To get where you set your picture start X or Y (works for both):

AxisOffset = AxisMax / OffsetPercentage

Offset Percentage should be 0-100 and yep, watch for division by 0.

One way you can do this is to get the "units" the scroll bars will move the background at open/resize, then set those values and simply multiply it against the value of the ScrollerPos.

For that:

OffsetIndex = ( 1 / ScrollerMax ) ; gets the percentage of a single movement.

OffsetAmount = ( OffsetIndex * AxisMax) ; Amount to MUL by to get where each position goes up by.

Once you do that for each Axis (maybe make a Proc to do that calculation by passing values), you can physically mul by the return value on ANY screen dimensions and it'll scroll exactly the same.



By the way, I deleted my previous attachment.
(I can't believe it had SO many bugs in it... it must be my new record :rolleyes: )


Keep trying. :) There's more still in it.

And just for fun, here's a treeview fun I'm having...

(Because its along the same line, oddly, annoying and bizarre.)
Posted on 2003-07-17 16:01:36 by FunkyMeister
Well, I've been researching a little about scroll bars, and decided to give up on them. It turns out that scroll bars can be processed in any way, depending on the application. So, since we don't know how treeview handles (or will handle in future versions) them, the best solution would be to handle the bars outselves... and I'm not going into so much trouble just yet. Maybe I'll get into it later.
I'm attaching my latest version... please test it, and tell me if there's anything that should be changed.
Posted on 2003-07-21 11:44:11 by QvasiModo

Well, I've been researching a little about scroll bars, and decided to give up on them. It turns out that scroll bars can be processed in any way, depending on the application. So, since we don't know how treeview handles (or will handle in future versions) them, the best solution would be to handle the bars outselves... and I'm not going into so much trouble just yet. Maybe I'll get into it later.
I'm attaching my latest version... please test it, and tell me if there's anything that should be changed.


Ah, well, actually, scroll bars are typically going to be the same (or every program hereafter will break), since you can use scroll bars outside of normal controls (since they are one anyways). For the static picture, seems to be fine, though you may want to work on the highlight control some. Black text on a blue bar is extremely hard to read.
Posted on 2003-07-21 18:39:42 by FunkyMeister
I start tvbktest.exe (66'048 19.07.2003) under Default color scheme and change to Marine (High Color) color scheme.
Result
Posted on 2003-07-21 20:24:26 by P2M
FunkyMeister:
Thanks! I forgot to invert the text color when the item is selected. Fixed! :)

P2M:
That looks like an old bug to me, when I didn't pass the WM_SYSCOLORCHANGE message to the treeview control... Did you try one of the latest versions?
Posted on 2003-07-22 12:09:02 by QvasiModo

FunkyMeister:
Thanks! I forgot to invert the text color when the item is selected. Fixed! :)

P2M:
That looks like an old bug to me, when I didn't pass the WM_SYSCOLORCHANGE message to the treeview control... Did you try one of the latest versions?


On a related note, have you got the code down for reading the text out of the item? Say perhaps maybe overlay it somewhere in the background. The fun I'm having I think is due to sendmessage returning true but no text is because I've not made the memory accessable globally, wonder what the memory reqs are for that. Odd. How about highlighting the text based on the entry's settings, bold text, etc.
Posted on 2003-07-22 16:30:41 by FunkyMeister
QvasiModo
Did you try one of the latest versions?
tvbktest.exe (66'048 22.07.2003 13:59)
mistake did not disappear.
Posted on 2003-07-22 20:40:31 by P2M
P2M: I could not manage to reproduce the error in my computer... I found, however, a new one :grin: that I'll fix later...
Posted on 2003-07-23 13:37:21 by QvasiModo
Fixed!

P2M: I still don't know why it doesn't work in your computer. Could you give me some info more info? (like what Windows you're running, etc.). I'm running Win98 and works OK.
Posted on 2003-07-25 14:15:08 by QvasiModo
QvasiModo
I am sorry.
I think problem in software on my work computer (PII-450 video:sis620 os:w2ksp3).
At home all work properly (Cel Tualatin-1300, Radeon8500LE, w2ksp3).
Posted on 2003-07-27 19:33:13 by P2M

QvasiModo
I am sorry.
I think problem in software on my work computer (PII-450 video:sis620 os:w2ksp3).
At home all work properly (Cel Tualatin-1300, Radeon8500LE, w2ksp3).


I smell a DLL version difference. What version of DLL's do you have for COMCTL32.DLL in both machines? (If I recall thats the dll he's using the treeview from, been a while since I looked.)

QvasiModo, check your right click on items. Looks evil, original highlight, text stays same color.
Posted on 2003-07-28 19:34:40 by FunkyMeister
I have to say, this bad boy has come a long way! Great job!!

Just fount a glitch.. if I use the scrollbar, the image stays fine ( I like how the image is stationary and doesn't move with the scrolling), but if i use the mousewheel, the image gets screwed up (kinda like it paints a double or so on it's self)
Posted on 2003-07-28 19:57:15 by Gunner
FunkyMeister: That could be the problem... That bug used to be in an old version tvbktest, because I forgot to pass the WM_SYSCOLORCHANGE message to the treeview control. Perhaps an old version of comctrl32.dll does not handle this message properly, with similar results... The version in my computer is 5.81, running on Win98.

Gunner: You are absolutely right, that's exactly what's happening. This is because the control's entire client area must be invalidated on scroll events, and I'm not processing mouse wheel messages. I didn't think of it simply because I don't have one :P ). Will fix it soon.
Posted on 2003-07-29 09:26:57 by QvasiModo
Here's the fix. I could not test it, since my mouse does not have a wheel.


QvasiModo, check your right click on items. Looks evil, original highlight, text stays same color.


I still couldn't fix that one. When you right click, the "old" item is still marked as selected, and the "new" one is not... perhaps I'm missing something about this CDIS_* flags?
Posted on 2003-07-29 14:21:32 by QvasiModo