Currently I use the following statements to set the color of even numbered rows…
LAST_ROW=GET_PROPERTY(FOCUS,'LIMIT')
FOR ROW=2 TO LAST_ROW STEP 2
RESULT=SEND_MESSAGE(FOCUS,'COLOR_BY_POS',0,ROW,COLOR)
NEXT ROW
So, I was wondering if there was a way for the "SEND_MESSAGE" statement to be called only once, rather than lots of times. With an edit table having 4,000 rows the "SEND_MESSAGE" statement would be called 2,000 times.
I was just wondering if there was a way.
You could set a user-var after the key .. call it @BEEN_HERE and set it to False (0). Then when you hit the table:
IF @BEEN_HERE THEN RETURN 1 ELSE
.. your code
@BEEN_HERE=1END
RETURN 1
Or something like that
Don M.
Richard,
I never heard of a way to do this with one message.
What about the following approach:
- Only colour the lines that are currently visible
- Have some handlers that refresh the colouring when the content is scrolled.
In addition to some handler doing the initial colouring I think you need one handler on POSCHANGED (to handle scrolling with the arrow and page keys) and one responding to scroll bar events (to handle scrolling with the scroll bar). You must qualify the latter.
If the colours flicker when you refresh perhaps somebody else can suggest how to avoid that.
Btw - can the user insert or delete rows in the edit table? If so - do you re-colour the lines so you don't get similarly coloured adjacent lines?
- Oystein -
Thanks for the input.
And Oystein, yes… After every deleterow and insertrow the routine is performed so as to maintain the "every other" color pattern.
One good thing is that if there is to be deleting and inserting, there are usually a very few rows involved. Only when the user is viewing and not updating, is there many rows involved.
I am just suprised that the edit table does not have an option for alternating colors.
If the table can change, then all bets are off (insert, delete, etc.). If it's static, then that's a different kettle of fish. You could pre-color the table before it's visible (all of it) then the scroll event should take care of itself (maybe). Otherwise, constant resetting of color can indeed be tedious.
Don
Richard,
After every deleterow and insertrow the routine is performed so as to maintain the "every other" color pattern.
Phew. That's an argument for trying my suggestion.
But there might be problems I didn't think about. It will certainly be difficult to refresh the stripes fast enough when the user drags the scrollbar thumb.
- Oystein -
Naw… I have a stored proceedure that handles all my custom "edit table" proceedures. All the rows in the edit table are already set to the proper color so scrolling has no effect. Just the deleterow and insertrow has effects.
I was just trying to efficiently produce the effect. It is nothing when a user deletes or inserts in an edit table with 10 rows, It is something when they do it in an edit table with 1,000 rows. And still no noticible delay really occurs. I just don't want a new customer to have one computer running a 133mhz and then complain that takes too long.
Richard,
I think I understood from the start what your problem was, with possible delays when the number of lines is large or the computer slow. That's why I suggested painting just the few lines the user actually sees, on demand, i.e, each time the user scrolls. But as I said one possible problem with that approach is being able to paint fast enough when the user scrolls by dragging the thumb.
But perhaps you can improve on your own approach by sticking to painting all the lines, but doing the visible lines first. Then at least the visible effect will not be delayed. Or?
- Oystein -