I think I am going to loose my mind very soon if not already. Everything is working well on Sticky columns except if you move the mouse to quickly. At first I thought this was due to the onmousemove event being kind of chunky when it dispatches or that the event cue was filling up due to the time it takes to calculate the subsequent columns.

In order to test this theory I created a one line event that simply sets the current X on a global var. The actual resize funtion is called on a timer that first tests to see if the previous X is different from the current X. If they are the same it exits. Fairly routine and amounts to two lines of code so how much more effecient could it be.

Alas the same blasted problem still exists. If you move the mouse to quickly it misinterprets the far right border and starts to shrink the columns before they are sticky. It even reports that they are sticky yet they are not.

I am not sure if the existing datagrid has the same problem. The test that was provided to me by Ruben already has the columns stuck on rendering so this is not an issue. Tomorrow I shall modify the example and rip through there code to see how there solution was done. I have already spent some time reviewing there DGServer code and as far as I could tell not much different than what I am doing.

I think it is perhaps time for a brain break on this problem. Perhaps a game of Age of Empires to clense the cranium is called for.

I spent the better part of todays daylight hours completing some long over due laundry tasks while I let my brain wander on column resize behavior. You might think a whole day is a lot of time to do laundry but when you have a 6 month old and a 2 year old, laundry is a never ending repetitive sequence. As I folded and argued with the wife over clothe organization, a contentious issue of hang or fold, my mind kept comming back to sticky columns.

First lets get a few things clear. Design decisions made as a result of past decisions that result in the convulating of something simple into something overly complex simply demonstrates poor planning, or does it? It is often the case, despite the best laid plans, that interface behaviors lend themselves to further behaviors that only become apparent once the initial behaviors are in your face. This is called being led down the garden path and often results in us, we developers, writing some realy cool shit that nobody realy gives a dam about, specially an end user. But hey, its realy cool though right and thats good enough for us, right? Well in a utopion world sure why the hell not but lets take a step back to reality and food on the table and talk about STICKY columns.

Your basic datagrid has a bunch of columns that you can resize. I resize a column larger and the ones to the right move to the right as a result, if I shrink a column the behavior is obviously the opposite. When the columns exceed the width of the containing window-object-viewport you get a horizontal scroll bar, very simple and obvious. You should be asking yourself right now why is that so obvious. Well the answer is that because that is how the windows explorer works or the Mac Finder works. The next question in your head should be but why does it work that way? The answer is because its simple and most people can understand it and more importantly it is now institutionalized in the computer vernacular! So STICKY columns, where getting there.

On the web people are used to things being dynamic, when they resize there window the contents resize with it. This is all fine and dandy but as many of you know it can also be a real pain in the behind. Since this is an expectant behavior in a web gui lets introduce columns with widths as percentages. From a presentation point of view the behavior of the grid is still the same. If the sum of the percentages is greater than 100 then the column(s) that exceed the 100% do not appear in the grid and a horizontal scroll bar appears. Again what is STICKY?

Now lets introduce 2 behavior delimiters to our grid columns. These are min-width and max-width. The behavior mods obviously limit the size of the column width and also obviously, you should be able to set them as either as percents or fixed pixel. So does our grid behavior now change, yes, but only slightly. If the parent object is resized the columns again resize themselves but if in doing so can only go up to its max width and vice versa when resizing the parent object smaller. When the user resizes a colum larger or smaller the same rules hold true. Resizing is stopped when either the min or max is reached. Almost to Sticky!

Lets introduce one final datagrid property. Lets call it NoHorizontalScroll, NHS for short. As you might expect when this behavior mod is turned on it prevents the grid from showing a horizontal scroll bar. This means as the user resizes a column, columns to the right could end up disappearing and be unaccessible. Now from a gui perspective NHS results in a completely unacceptable interface behavior, content disappears!!! This would freak your average user and they would start hitting the refresh button like mad and sending you weird support emails with lines like 'my data has been deleted' or 'do I need a bigger monitor?'. Sounds silly but we have all heard the stories of user stupidity and some of us have even been in them. Again what about Sticky?

Now we have a problem, we obviosly can not allow columns to be hidden and become innaccesible. So our solution is we have to prevent the user from resizing a column to large that it results in forcing other columns of the grid. But what if the grids' width is already at 100% with columns. Well, thats where min-width comes in. If the user resizes a column larger, the columns to the right are pushed to the right until the last column reaches the far right of the grid container. Then as the column continues to be enlarged the subsequent columns are decreased in width until they reach ther min-width. Once all the columns have reached there min-width the column being enlarged can no longer be made any larger. A little more complex of a behavior for sure but again this seems to make complete sense. But what about when the user resizes the column smaller? If they have resized there column as wide as it can go then make it smaller do the columns to right simply move to the left. Remember now that those columns are at there min-widths so there content might be unreadable. Again from a gui perspective this would seem a bit obtuse and ugly so obviously we have to do something a little better and smatter.

At last sticky columns!! Given our previous scenario what we need to have happen is the columns to the right need to automatically make themselves larger as more space is made available when the user shrinks the original column. This means that the far right column remains STUCK to the right hand edge of the datagrid, hence Sticky Columns! It remains stuck until such time as its max width has been reached and then it begins to move to the left but only when all other columns between it and the column being shrunk have reached there max-widths. For the last time from a gui perspective this would be ther expected behavior.

Now, if you have read up to this point you are most likely saying to yourself that yes the above makes complete sense. If this is so then I have some boots for you because you are firmly on the garden path!

"To Stick or Not to Stick, that is the question?" Lets remember that a datagrid is a grid with a bunch of columns that you can resize and when they are to big a horizontal scroll bar appears and that is it!! How far have we strayed from this tried and true lexicon of gui? Is there such an apparent reason to? Why havn't the O.S. developers with there bags of money and industrial phsycologists made this astounding leap in gui logic? The most basic and simple answer is because its overkill. It makes something simple and apparent work in a way that is conterintuitive to your average user.

All you young developers out there seem to think that this is all so obvious but a majority of users can't find a web page link unless its blue and underlined. I did a nice little web page for a client where the links where a dark blue with no underline but changed color on mouseover and he got complaints from people because they did not no where to click. I kid you not!!! Interfaces have to be obvious and improve the quality, quantity and accuracy of the targetted audience. If you are designing something to go to market keep it simple. Chances are if its obvious to you its not obvious to your users. Interface is the most important aspect of any system. I know dba's will argue its the database, .NET, ASP, PHP, CGI folks will argue its the middle tier because thats the business layer but they all count for nothing if your interfaces suck. You know why? Because know one is going to use your terrible gui to that incredible business middle tier and 5th modal form database!

The above brain dump is the result of to much time thinking while doing laundry. Now I am off to finish my sticky column code because ITS REALY COOL!!!

Well its late but after a nice bottle of Merlot and far to many cigarettes I am close to resolving the column resize issue when the grid has noHorizontalScroll set to true. Its a real brain task in debuggin but overall is actually only about 20 lines. The column resize issue is probably the most difficult task to code for. After this it should be smooth sailing for data and skin integration plus the bells and whistles I want to put in. Think I am going to hit the sheets now as I believe I am on deck to get up and feed the baby at 6AM. I think this classifies as a ramble :-)

Completed the data loading feedback interface. Tried to be a bit smart with the grid dataloading. Only the initial page of data is created on load in order to reduce render time. As the user scrolls down the necessary cells are created. If the user pages down or scrolls to the bottom they get a percentage loading feedback in the middle of the grid. I ran some volume tests on the control with 2000 records displaying between 1 and 5 columns and it performed fairly well.

Completed the min/max width functionality plus the column resizing on document resize.

It has been a couple of days since I have been able to do any work on the datagrid control and it has been longer since I have updated these pages. Given this I thought it prudent to start a bit of a blog on the current progress.

Before Ruben left on holidays in warmer climates we had the chance to have some discussions of the column auto sizing features. It came down to two choices, either support mixed column formats, i.e. % and PX, and bind the the body.onresize event or do not allow mixed formats and do not bind to the body.onresize event. The reason this has to be discussed is that if you start to bind your control to DOM elements outside of the control you run into the nasty situation of destroying those bindings when the object is destroyed. Now if we could reli on programmers to be good little programmers then not a problem but that is not how you should develop a widget, it should be self encased.

Now why the body element you say. Well it turns out that despite what mozilla docs say, the onresize event does not fire on any dom object, only on the body element. This means that if we are going to do this then we will always bind to the body element for consistency. Luckily Ruben provided me with a Javeline base class solution for this, no surprise there, which means we will allow for mixed column formats as orginally planned for.

So today I will complete the resizing issue and work on "Sticky" columns. There has to be a better name for a column that is fixed to the right border, sticky column sounds a bit naughty to me ;-)

I also promise to get around to updated the CSS/HTML Implementation document.