Welcome Guest Search | Active Topics | Sign In | Register

Column header background colour Options
colin
Posted: Tuesday, September 21, 2010 2:18:03 PM
Rank: Newbie
Groups: Member

Joined: 9/16/2010
Posts: 8
In a Grid control I have set the column header background like this:

detail.ColumnHeaderStyle.BackColor = Drawing.Color.FromArgb(240, 240, 240)

In Firefox this is fine. In IE8, however, this just sets the background colour of the text rather than the full cell.

<div style="position: absolute; left: 310px; top: 0px; width: 35px; height: 40px; z-index: 1008; overflow: hidden; -moz-user-select: -moz-none;" id="detail_c8">
<div class="eo_css_ctrl_detail1" eo_position="absolute" style="position: absolute; left: 0px; top: 0px; right: 0px; bottom: 0px;" id="detail_c8_i">
OUT
</div>
</div>

The background colour is defined in the CSS for the inner <div>, i.e. in eo_css_ctrl_detail1 in my example.

How do I get a background colour into the style of the outer <div>?



eo_support
Posted: Tuesday, September 21, 2010 3:05:54 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

Check whether you have the following at the top of your page (so that the page is in standard compliant mode):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

If you cannot put the page in standard compliant mode, you can create an image file with the background you wish to use and then set the style's BackgroundImage. I believe that image file will be horizontally tiled to fill the whole grid header.

Thanks!
colin
Posted: Tuesday, September 21, 2010 7:32:09 PM
Rank: Newbie
Groups: Member

Joined: 9/16/2010
Posts: 8
Well, that works in respect of the background colour, but it introduces a bunch of other problems. The top two are:

1) the Grid control now gets re-sized to the value of the Height property. If I set the Height property to the correct value then I get many unwanted extra rows rendered in HTML, as per our PM discussion.

2) the right-hand-side gridline in the cells is rendered one pixel to the left, leaving a white space where the gridline should be. The rendered <div> reads

<div style="position: absolute; left: 240px; top: 0px; height: 100%; width: 34px; overflow: hidden; z-index: 14;" gridlineapplied="true" id="detail_i2_c6">

when the column is 35 pixels wide.

There are other problems as well, but those two are the main problems with going to the doctype you suggest (or any other transitional doctype from HTML 4.01 onwards)
eo_support
Posted: Tuesday, September 21, 2010 8:12:26 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

I am not exactly sure what you mean by the Grid new gets resized to the value of the Height property. The Height property is what matters to the extra rows. As previous discussed, there is no way for you to completely remove that and whether DOCTYPE exist should not make any difference to that. The only thing you need to make sure is to give Height an explicitly pixel value. DOCTYPE does not matter.

#2 is the correct behavior. The width is one pixel off so that the total width of the DIV AND the grid line equals to your column width. What you see might have to do with your style settings. In fact all our samples runs with DOCTYPE enabled and they run just fine. So if you are seeing a lot of problems, then you might want to compare our samples with your styles and see whether you missed anything. It actually supposes to work better when DOCTYPE is enabled.

Once again if DOCTYPE does not work for you, you can always use a background image.

Thanks
colin
Posted: Wednesday, September 22, 2010 4:53:03 AM
Rank: Newbie
Groups: Member

Joined: 9/16/2010
Posts: 8
eo_support wrote:
I am not exactly sure what you mean by the Grid new gets resized to the value of the Height property. The Height property is what matters to the extra rows. As previous discussed, there is no way for you to completely remove that and whether DOCTYPE exist should not make any difference to that. The only thing you need to make sure is to give Height an explicitly pixel value. DOCTYPE does not matter.


My code sets the Height property to 40 pixels. Not because I want it to be 40 pixels high, but because I want to limit the number of extra rows. In both Firefox and IE, setting the Height property to 40 pixels makes no difference to the overall displayed height of the grid.

When I changed the DOCTYPE to your suggested alternative then, in IE, the grid is re-sized to be 40 pixels high. The Firefox rendering remains unchanged.
eo_support
Posted: Wednesday, September 22, 2010 7:58:14 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

In that case your only option is to use a background image. The Grid expects the Height to be the real height and many internal logics are based on that value. It's lucky that your method worked on both FireFox and IE without DOCTYPE, but it is impossible for us to support all these kind of "tweaked" scenarios such as style="height" and Height are intentionally set to be different.

Thanks
colin
Posted: Wednesday, September 22, 2010 8:23:55 AM
Rank: Newbie
Groups: Member

Joined: 9/16/2010
Posts: 8
I don't have a problem with having Height set the same as the style height, except that you use the Height property to derive the number of added rows to generate. I suggest that adding an additional property, called SpareRows or something of the sort, would provide a way to specify how many additional rows are rendered for scrolling without having to infer something from the Height property whose value is not reliably maintained.
eo_support
Posted: Wednesday, September 22, 2010 9:20:32 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Yes. That's the same issue as previous discussed via PM and we will be looking into it.

I do not expect you to be able to control the exact amount of extra rows since it has to do with our internal algorithm and it would not be wise for us to change it significantly, not to mention that the absolute majority of our users either do not care or do not fully understand what those extra rows is or for. Most of them simply are not interested in digging under the hood, so adding such an option without a clear purpose (this brings the question: why do you want to remove the extra rows? More on this below) will just adding more confusion in their head.

A number of other options are available: For one as you mentioned, it may not be needed if scrolling is not enabled; For two, we might be able to dynamically create it on the client side instead of having it rendered on the server side ---- not sure if this defeats your purpose though because we are still not quite clear why the extra rows bother you. If you are concern about the bandwidth, then dynamically creating those rows on the client side should address your concern. If you are concern about client side performance, then the extra rows should definitely stay because they are there to improve the performance. The only case you would not need those rows is when you will never scroll. It is still tricky to disable extra rows in that case because our Grid allows you to dynamically add rows on the client side.

We have many different customers who give us all kind of different feedbacks and all of those are very important for us. However we have to be able to understand the customer’s real intention in order serve them the best. So it would help if you can let us know what really bothers you about the extra rows. We may not do exactly what you wanted, but please be rest assured that we will do our best to address your real concern.

Thanks
colin
Posted: Wednesday, September 22, 2010 9:55:45 AM
Rank: Newbie
Groups: Member

Joined: 9/16/2010
Posts: 8
My concern about the extra rows is based on performance.

When I first saw the extra rows being generated it was after re-positioning the grid control using absolute coordinates. In VS2010 that caused the Height property to be cleared, and that in turn caused the generation of 230 or so extra rows, which caused an annoying delay in loading the form.

If the question becomes 'how many extra rows are acceptable for performance reasons' then the answer will always be 'as few as possible, and no more than are needed'. In my case I need no extra rows because I won't need to scroll the grid but there is no option that I can use to implement that.
eo_support
Posted: Wednesday, September 22, 2010 10:06:12 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
colin wrote:
In my case I need no extra rows because I won't need to scroll the grid but there is no option that I can use to implement that.


Excellent. Thanks for confirming. The 230 rows case is the extreme case when you do not set Height. Once you set the Height to the correct value, the number of extra rows should be reduced dramatically.

Nevertheless we will be looking into having a solution that would not have any extra rows as long as you do not need to scroll instead of adding an ExtraRows property as you previously suggested.

In the mean time, if you can provide a sample page to us that demonstrates the exact way you are using our Grid so that we can use it to verify our solution for you it will be very helpful.
eo_support
Posted: Friday, September 24, 2010 12:12:19 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

We have posted a new build that should address this issue. The new build will not render extra rows if you do not need to scroll. Please see your private message for the download location.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.