Tab control update

[Jon Griffiths]

Hi,

>It would be really nice to separate formatting changes from other
> changes. It's hard to see what's got changed and what not.

Agreed, see my reply to Robert on that.

>>"Only create a scroll control when/if we need one (like native)"
>Nothing got changed. It's being created when needed, and hidden
> when not longed used. Is there something else I missed?

Yes, we don't need a scroll control if the window is sized to 0,0
when items are added.

>>     Combine all Unicode/Ascii calls together
>I'm not sure here, but should it be based on the unicode state of
the
> whole control rather which message got sent to it? 

This refers to processing the messages using the same code. e.g.
between TAB_InsertItemA/W only 2 lines were different - the debug
trace and the line that sets the text pointer. Its better to share
the code so that we only have one place where the items array is
realloced on insert. Its also a lot smaller (see also get/set item
A/W).

>I can see how you can send ASCII message first and then send
>UNICODE message which will screw things up.

I don't know what you mean. Can you give an example?

>If this is the case we need to store pointers in array of pointers.

You misunderstand. Items are variable sized per _control_, not per
_item_. So array indexing is better, its just that the size of the
indexed item changes for each control depending on its data size.

>You missed insert items with text part inside create_tabcontrol.
> Besides as is it's failing for me. When I change text of the first 
> tab "Tab 123" it's changing returned width.

Its measuring the size of the text, so _of course_ it will fail if
you change the text. If it fails on a standard windows setup I can
rework the test to calculate the text width manually for the
comparason. But I don't have a win system setup here to test ATM. The
test works here with builtin and native comctl32.

>The reason why I didn't test this is because the width of the
>tab depends on it's text width. Which is kind of hard to test
(different
> fonts, different font sizes etc.).

If the tab doesn't have text and/or icons and tabs are not fixed
width the size is currently wrong. The patch fixes those cases (that
my app depends on) and doesn't break any other case that I tested.
Can you provide a case that I broke that wasn't already broken?

Cheers,
Jon



=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

jon_p_griffiths at yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail