The version 11/9 is much better than before but if you resize the "heading 2 is too long to fit" (reduce the width to make it wrap) then the same overwriting of the buttons still happens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have retested using IE7 and ZKfreshly7/12. The current solution is still nowhere near perfect so I have opened this again. Please try the following (using the same test program as before)
Ex1 - In the 2nd Listbox the headings (1, 2, 4) are not fully displayed event though there is enought room to do it. IMO the headings should be displayed fully when it is possible to do so.
Ex2 - Bug. In the 3rd Listbox make the "heading 3" column wider (by dragging it from the right-hand-side). After this the data no longer lines up with the column headers!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are my answers.
Ex1- If you don't specify the width of header, the client engine will specify the column size of the first row from the content body.
In your case, you need to specify the width of each header.
Ex2- In your example, though you have specified the width for each of the four header as 60px, but the headers become bigger if the width of listbox is bigger than 264px (real size 66px *4) since the width of header is not restricted to your pre-defined width if the width of listbox is big than the sum of all headers' widths. So, when you resize the width of "heading 3" manually, ZK will "ONLY" update the width of header 3 (performance issue). And, the width of the rest of headers is adjusted by the browser since the width of table is modified. To avoid this problem, you should let the sum of width of headers be bigger than the width of listbox, then the browser won't adjust the width of headers automatically.
The formula as follows,
60 + 6 (border and padding) = 66
66 * 4 = 264 (total size of listbox)
For example, you should specify the size as below.
You said: "you should let the sum of width of headers be bigger than the width of listbox"
But with lots of live data the Listbox may have a vertical scroll bar. If the sum of header width is >= Listbox width then when there is a vertical scrollbar I will also lose 1 row to a *horizontal* scroll bar which may not be necessary.
--
I really wanted to avoid scattering these sort of hardwired numbers like 6 (heading border) and 20 (scrollbar width) in my code just to render a Listbox without problems.
Maybe I am being naive but why can't the "Ex1" example make a better calculation of the column width *automatically*. When calculating the col width based on the content why can't the client engine simply restrict it so the col width cannot be less than the width of the col heading? That way it would render much better and developers would not have to jump through hoops to set fiddly widths correctly - isn't that the idea of "zero code".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>a *horizontal* scroll bar which may not be necessary.
To display a necessary horizontal bar is a native issue on IE browser. If we want to avoid the issue, we need to calculate a precise size.(If developer had told us)
If you don't want to specify a precise size to listbox's header, it will show a wrong layout when the sum of header width is less than Listbox width and you are dragging the header to be bigger size.
At most of the time, end user care the content of body or not header, so according to our previous version, we need to back work compatible the ZK specification. When develop don't specify the header width, we will specify the width of the body content dynamically.
/Jumper
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
test code and readme file
Logged In: YES
user_id=1684431
Originator: NO
Fixed since 11/29.
Logged In: YES
user_id=1836662
Originator: YES
The version 11/9 is much better than before but if you resize the "heading 2 is too long to fit" (reduce the width to make it wrap) then the same overwriting of the buttons still happens.
Logged In: YES
user_id=1684431
Originator: NO
Fixed since 11/30.
I think the best solution is that line-break is forbidden in IE, because the IE's behavior is different from others'.
Do you agree?
/Jumper
Logged In: YES
user_id=1836662
Originator: YES
I have retested using IE7 and ZKfreshly7/12. The current solution is still nowhere near perfect so I have opened this again. Please try the following (using the same test program as before)
Ex1 - In the 2nd Listbox the headings (1, 2, 4) are not fully displayed event though there is enought room to do it. IMO the headings should be displayed fully when it is possible to do so.
Ex2 - Bug. In the 3rd Listbox make the "heading 3" column wider (by dragging it from the right-hand-side). After this the data no longer lines up with the column headers!
Logged In: YES
user_id=1684431
Originator: NO
Hi,
Here are my answers.
Ex1- If you don't specify the width of header, the client engine will specify the column size of the first row from the content body.
In your case, you need to specify the width of each header.
Ex2- In your example, though you have specified the width for each of the four header as 60px, but the headers become bigger if the width of listbox is bigger than 264px (real size 66px *4) since the width of header is not restricted to your pre-defined width if the width of listbox is big than the sum of all headers' widths. So, when you resize the width of "heading 3" manually, ZK will "ONLY" update the width of header 3 (performance issue). And, the width of the rest of headers is adjusted by the browser since the width of table is modified. To avoid this problem, you should let the sum of width of headers be bigger than the width of listbox, then the browser won't adjust the width of headers automatically.
The formula as follows,
60 + 6 (border and padding) = 66
66 * 4 = 264 (total size of listbox)
For example, you should specify the size as below.
<listbox height="100px" width="264px">
<listhead sizable="true">
<listheader width="60px" label="${each}"
forEach="${longcolheadings}" />
</listhead>
Logged In: YES
user_id=1836662
Originator: YES
You said: "you should let the sum of width of headers be bigger than the width of listbox"
But with lots of live data the Listbox may have a vertical scroll bar. If the sum of header width is >= Listbox width then when there is a vertical scrollbar I will also lose 1 row to a *horizontal* scroll bar which may not be necessary.
--
I really wanted to avoid scattering these sort of hardwired numbers like 6 (heading border) and 20 (scrollbar width) in my code just to render a Listbox without problems.
Maybe I am being naive but why can't the "Ex1" example make a better calculation of the column width *automatically*. When calculating the col width based on the content why can't the client engine simply restrict it so the col width cannot be less than the width of the col heading? That way it would render much better and developers would not have to jump through hoops to set fiddly widths correctly - isn't that the idea of "zero code".
Logged In: YES
user_id=1684431
Originator: NO
Hi,
>a *horizontal* scroll bar which may not be necessary.
To display a necessary horizontal bar is a native issue on IE browser. If we want to avoid the issue, we need to calculate a precise size.(If developer had told us)
If you don't want to specify a precise size to listbox's header, it will show a wrong layout when the sum of header width is less than Listbox width and you are dragging the header to be bigger size.
At most of the time, end user care the content of body or not header, so according to our previous version, we need to back work compatible the ZK specification. When develop don't specify the header width, we will specify the width of the body content dynamically.
/Jumper