1. 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
2. RE: My EuGrid improvement
> >
>
> 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.
>
Yes, that is a better final solution. One thing you might do is to put
the nat_compare() function right in the eugrid.ew file (feel free) and
then you could possibly have it as one of the sorts easily available
just as a convenience thing -- just stick it in there and set a global
constant with its routine_id.
> 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?
>
Ah... I thought the fact that it was sorting strings instead of numbers
was the cause of the problem for numerical columns in the first place.
If it is sorting on the underlying set, then numerical columns should
sort correctly using regular compare already. I thought they weren't?
In my particular program, I have numerical columns, but they're all
sprintf'd in advance and none of them are specified as numerical in
EuGrid, so I need to use nat_compare_str() to get them right.
So to amend my earlier comments, if you alter the current version of
EuGrid, you should use plain nat_compare() instead of nat_compare_str().
nat_compare() will compare any two objects -- atoms or sequences -- and
so will do numerical comparisons on the underlying set correctly (it is
the same as compare() in that case). The "natural order" part only
kicks in when it is comparing two strings...
3. RE: My EuGrid improvement
Andy,
> Ah... I thought the fact that it was sorting strings instead of numbers
> was the cause of the problem for numerical columns in the first place.
> If it is sorting on the underlying set, then numerical columns should
> sort correctly using regular compare already. I thought they weren't?
Things have been a bit confused because there is a bug in the sort
routine in the current version of EuGrid. A few days more to test this
plus other changes and I will post the new version which uses the
regular compare function correctly. This this should give correct
sorting on numeric columns with no need to invoke other sort routines.
Regards,
Phil
