RE: My EuGrid improvement
Andy,
Many thanks for your post. Replies below:
Andy Serpa wrote:
> Two things:
>
> One thing that annoys me in EuGrid is the fact the it keeps scrolling
> far into the "empty" area after the rightmost column (horizontal scroll)
>
> is visible.
Sorry for annoying you! 
>To make it stop doing that, I stuck the following function
> into EuGrid:
>
> function get_hscroll_range(integer id, integer grid)
> sequence rect
> integer w, client_x, colw
>
> rect = getClientRect( id )
> client_x = rect[3]
>
> w = GridProperty[grid][EGW_ROW_HEADER_WIDTH]
> for i = length(GridCol[grid]) to 1 by -1 do
> colw = GridCol[grid][i][EGW_COL_WIDTH]
> if w + colw < client_x then
> w += colw
> else
> return i+1
> end if
> end for
>
> return 1
>
> end function
>
>
> Then, in the EGW_DrawGrid procedure I changed the following line:
>
> EGW_SetScrollRange( hwnd, SB_HORZ, 1, length(GridCol[grid]), 1, True)
>
> to
>
> EGW_SetScrollRange( hwnd, SB_HORZ, 1, get_hscroll_range(id,grid), 1,
> True)
>
>
> and in the EGW_OnHScroll function I changed the following line:
>
> GridTopCol[grid] = min(GridTopCol[grid], length(GridCol[grid]))
>
> to
>
> GridTopCol[grid] = min(GridTopCol[grid], get_hscroll_range(id,grid))
>
>
> Now it stops the scroll after the last column is visible, and sets the
> range so that the thumb acts more as you would expect. Basically, the
> top function starts at the rightmost column, and moves backwards adding
> up the current column widths to determine where it really needs to stop.
>
> It will still leave a little whitespace after the last column if it
> doesn't quite line up, but you could easily write a routine to
> dynamically resize the last column as needed. I think this has been
> discussed before.
>
> EuGrid has the same behavior with vertical scrolls, and I plan on doing
> something similar for that, but if Phil likes the idea, then I'll leave
> it up to him to put it in the next official version.
>
Seems like a perfectly sensible idea to me - particularly as I don't
have to do any work. I will put it into the next release.
I had already planned to do something with vertical scrolls to stop
paging off the bottom of the grid. This is slightly complicated by an
outstanding request to have user-resizable row heights. I haven't
started doing this yet as it involves a considerable change to an
already somewhat convoluted algorithm.
>
> Second thing, regarding sorting, and this has also mentioned before, but
>
> just to make clear: if you include my nat_sort.e file and change the
> compare() function in the sort routine to nat_compare_str() (preferred
> over plain nat_compare() since we're only sorting 1-d strings, i.e.
> faster), it should sort all columns -- numerical and otherwise --
> properly (including a "better" sort on strings that mix letters &
> numbers). My natural compare routine doesn't actually work with
> floating point numbers (it considers .001 and .00001 to be equal), *BUT*
>
> it will work as long as there is a fixed number of decimal places as I
> think would always be the case with numerical columns in EuGrid which
> uses sprintf to format them. Right?
>
The solution for sorting that I have come up with is that I will
continue to use the built-in Euphoria sort as the default sorting
method. I have fixed a bug in this which meant that the sorting
sometimes went awry.
However, you will be able to specify a sorting routine id at grid and/or
at individual column level to plug in any custom sort routine that you
want. I considered making nat_sort the default but one of my design
goals (yep I *do* have them) is to minimise dependencies on other
libraries. I think that this solution is the most flexible.
With regard to floating point numbers, at the moment the sort is
performed on the underlying data, rather than the sprintf'd
representation of it. As the underlying data can be a number then as it
stands there might be a problem in sorting fp numbers as in your
example. I could modify the sort code to always convert number data to
formatted strings before performing the sort comparison. This would
inevitably slow things down slightly when sorting large datasets. I
could also make this behaviour optional by a new grid/column property
e.g. EGW_SORT_STRING or something.
What do you think?
Regards,
Phil
|
Not Categorized, Please Help
|
|
