Continuing to convert an ARev app….

I have an edittable in a form that displays information about invoices for a given customer. Several of the columns are XLATES from the invoice table. Each invoice is a separate record in the invoice table. In ARev, there can be up to 1000 invoices in the list. In OI, I upped it to 2000 (no more 64K record limit after all!).

In an ARev window, the window reads the rows by using @MV, so that if you are displaying, say, 10 rows at a time, only the visible rows get read until you scroll (i.e. {} only returns one value at a time). It appears that in OI, the edittable is reading the entire list, regardless of how many rows are actually displayed. On a slow network connection, this results in a many-second delay to XLATE all those rows.

Is there any way of controlling how many rows the edittable actually reads at one time (e.g. limiting it to the visible rows?) I am sure that I can jigger the symbolics to be aware of which rows in the edittable are currently visible by using SELPOS and manually setting @MV, but is there an easier way?

Thanks,

David

Dave-

Instead of an xlate, have you tried binding the xlated columns to the data table you grab the data from? It's usually faster than xlates…

Mike

No, honestly, I guess I still think of binding to multiple tables as some kind of kludge.

However, in this particular instance, it probably won't help: I oversimplified the portrayal. The edittable in question actually displays information about 3 differerent types of accounting documents (from 3 different tables), and so I need logic at each row to decide which table the particular information is coming from. (That is, I am displaying information about invoices, debit/credit memos, and payments, and the way the information is displayed for each row is dependent on what table the information is coming from). The XLATES are tried and true, and I hate to modify code that I know works if I don't have to.

However, I will keep this in mind….

David

David

David,

A few ideas:

(1) You haven't said how the data in the edit table is used (browsed). Does the user concentrate on narrow neighbourhoods (say a couple of hundred contiguous lines), or does he jump all over? Does he need real-time scrolling capabilities? (For lack of a better term, with real-time scrolling I mean the ability of a scrollable component to have its content dynamically follow the scrollbar thumb's movement, not waiting to update its client area until the thumb's been released.) What I'm after is - can you use some chunking strategy where not all the data is present in the edit table, until actually scrolled to? E.g, what about having all your rows filled in, except for the Xlated columns, which only would be calculated on demand, i.e, not calculated until actually scrolled to.

(2) Would Mike's suggestion work if the data did come from one table instead of three? If so - can you make it come from one table? What if you have a fourth table ALL, maintained by MFS-es on the three tables? The data you previously Xlated from the three tables could either be actually present in duplicate in data fields in ALL, or virtually, through symbolics.

(3) Your edit table must somehow contain foreign keys to the three tables. Now what if you had separate columns for each of the three keys? (Don't protest until I'm finished.) Then you could bind each column to the relevant table. For each row of data only one of the key columns would be filled in. Then have three sets of columns bound to appropriate symbolics in each of the three tables. Now make this ugly monster of an edit table invisible, and make a new unbound edit table with the layout you really want. Then make some handlers update the visible edit table from the hidden one, and vice versa if necessary.

- Oystein -

Oystein,

Thanks for giving some thought to this. I think "chunking" would be fine (like ARev). 95% of the time, users will be interested in only the top couple of dozen rows of the table, if that much. The rest of the time, the lag resulting from scrolling would probably be quite tolerable, especially if it was only in chunks. Actually, when run on my 1.2MHz machine locally, even reading 1000 rows is reasonably quick. When I am worried about speed, though, I test on a 10Mbit phoneline network connection (which is probably more like a 5Mbit connection), and it's a pig, then.

How do you know which rows of an edit table are actually visible at any given moment? (I know how to see which row is selected; but what if the table doesn't have focus?) My table shows 10 rows at a time. I think I would just like to read in 30 rows: the visible 10, plus the 10 above and below.

Thanks,

David

David,

Thanks for giving some thought to this. I think "chunking" would be fine (like ARev). 95% of the time, users will be interested in only the top couple of dozen rows of the table, if that much.

I though perhaps you'd prefer the alternative with all data values filled in initially, but where symbolics are only filled in on demand. Of course it depends on much time it takes to fill in all the data values.

How do you know which rows of an edit table are actually visible at any given moment? The TOPPOS property. (I know how to see which row is selected; but what if the table doesn't have focus?) My table shows 10 rows at a time. I think I would just like to read in 30 rows: the visible 10, plus the 10 above and below. More thoughts and questions: When scrolling/browsing in one direction - it seems you chuck out the chunks at the opposite end. Why? The user might want scroll back again. I thought your problem was processing time, not the total volume of data in the edit table? (I know you may have your reasons. I just ask to be certain you've thought things through.) Next question: How will you offer scrolling capability? Here are four alternatives: - Previous and Next Chunk buttons. - The edit table's own scrollbar. - A separate scrollbar control. One advantage is the range can be set to reflect the real number of data rows - not just the ones actually in the edit table. You could make it possible for the user to scroll to the middle or the very end of data in one go. But he would of course have to wait for the relevant chunks to be calculated and displayed. And he wouldn't get any real-time scrolling of the edit table. It's not possible to keep the edit table continuously in synch with the scrollbar control. Scroll first, then the edit table jumps, even if the scroll happened to be within the data actually in the edit table. You could object there would be problems with real-time scrolling that brings you outside the data actually in the edit table, because either there would be nothing to see, or there would be too much overhead in calculating the symbolics on the fly. - The scrollbar of a separate control, where the client area of the control is set to zero width so the whole thing just looks like a scrollbar control. This is what you could use if you for some reason wanted real-time scrolling after all. The reason it's not possible to keep an edit table continuously in synch with a scrollbar control is that there aren't enough messages from the scrollbar control. You need it to continually send messages about the thumb position, so a handler can keep the edit table in synch. But it's different with scrollbars belonging to other controls. They got plenty of neat messages you can qualify. Sorry for piling my thoughts so high. - Oystein - </QUOTE> —- === At 03 JUN 2002 04:30PM David Kafka wrote: === <QUOTE>Oystein, You are correct–it probably makes no sense to read in rows before they actually need to be displayed. You are also correct that it is only the symbolics that consume so much time, so the actual bound rows would be there the whole time. Just so you know where I am coming from, in the ARev version of this window, the user can either scroll through the AMV list using ARev's scrolling capability, or jump to any place in the list using a POPUP which does load the symbolics in chunks above and below the chosen row (i.e. it shows n full rows above and below the chosen row, including symbolics, and only real fields for the rows outside the range). Since the ARev POPUP is not real-time, I need to load in chunks on both sides of the target row before the POPUP is displayed. I wouldn't need to do that in OI, I don't think. I think, though, that the best clue you have given me is the idea of using the scroll bar from a separate control with a hidden client area. I need to think about that. But, wait, why wouldn't just using an unbound edittable instead of the bound one work? Hmm, and all I asked for was an easy way. Oh well. David </QUOTE> —- === At 04 JUN 2002 04:27AM Oystein Reigem wrote: === <QUOTE>David, I think, though, that the best clue you have given me is the idea of using the scroll bar from a separate control with a hidden client area. I need to think about that. It's not at all difficult to scroll an edit table from, say, the scrollbar of a list box. I did some experiments earlier this year, using what I found in this posting from Sprezzatura: . I can post my code if you're curious. - Oystein - </QUOTE> —- === At 04 JUN 2002 09:23AM David Kafka wrote: === <QUOTE>Oystein, you never have to ask re posting code! I learn more from looking at code than any other way (plus, if I get to cut and paste once in a while, it doesn't hurt.) I checked out the link you posted on the Qualify_Event thread re syncrhronizing list boxes. It's all very interesting. Seeing your code would certainly cement it for me. If you don't mind, of course! By the way, Oystein, I am learning a tremendous amount from your posts. I can't thank you enough. David </QUOTE> —- === At 04 JUN 2002 02:13PM Oystein Reigem wrote: === <QUOTE>David, OK. Here's how to scroll an edit table from the scrollbar of a list box: In the programming you need the following constants: <code> equate WM_VSCROLL$ to 277 /* "0x115" */ equate SB_LINEUP$ to 0 /* Scrolls one line up */ equate SB_LINEDOWN$ to 1 /* Scrolls one line down */ equate SB_PAGEUP$ to 2 /* Scrolls one page up */ equate SB_PAGEDOWN$ to 3 /* Scrolls one page down */ equate SB_THUMBPOSITION$ to 4 /* The user has dragged the scroll box (thumb) and released the mouse button. The nPos parameter indicates the position of the scroll box at the end of the drag operation. */ equate SB_THUMBTRACK$ to 5 /* The user is dragging the scroll box. This message is sent repeatedly until the user releases the mouse button. The nPos parameter indicates the position that the scroll box has been dragged to. */ equate SB_TOP$ to 6 /* Scrolls to the upper left */ equate SB_BOTTOM$ to 7 /* Scrolls to the lower right */ equate SB_ENDSCROLL$ to 8 /* Ends scroll */ </code> Say you have an edit table ET with NUM_VISIBLE_LINES$ visible lines. Put a list box to the right of ET. Name the list box LIST_SCROLL. The list box should have the same number of visible lines as the edit table. You may need to key in some data to be able to see the lines so you can set the height right. Don't bother with removing the data again. You will reset the content in the window's CREATE handler anyway. Since list boxes have a smaller line height than edit tables you may want to increase the font size for the list box to get the two controls better aligned. (Now you might want to use an edit table instead of the list box, edit tables are special and the method doesn't work.) Make LIST_SCROLL so narrow that just the vertical scroll bar shows. If you have problems getting it exactly right turn off grid snapping. Or just SIZE the thing programmatically in the window's CREATE handler. Come to think of it: I reckon it's important the list box is protected so the user can't tab to it. I don't know what's the best way to do this. Perhaps a GOTFOCUS handler that sets the focus to the next control in tab order. But what if the user backtabs… I leave this problem to you. Now in the window's CREATE handler qualify the WM_VSCROLL message for the listbox control: <code> UnUsed=Send_Message( @Window : ".LIST_SCROLL", "QUALIFY_EVENT", WM_VSCROLL$, 1 ) </code> In earlier postings I might have mentioned something about a lot of messages, but they're all WM_VSCROLL messages telling about different things the user does with the scrollbar. In CREATE you might want to set the width of the listbox too: <code> Size=Get_Property( @Window : ".LIST_SCROLL", "SIZE" ) Size=18 UnUsed=Set_Property( @Window : ".LIST_SCROLL", "SIZE", Size ) </code> Whoops. Last minute observation: 18 seems to be OK on Win2000, but XP might need 19. And of course with users who like to change their Windows settings you might expect anything. Unfortunately if you set the width too narrow what you get is not a clipped scrollbar, but a piece of client area. Well, another problem for you. Also you might need some dummy data in your edit table: <code> ETList=" for I=1 to NUM_DATA_LINES$ ETList[i]=row " : I next I UnUsed=Set_Property( @Window : ".ET", "LIST", ETList ) </code> And you need to fill the list box with the same number of lines. These lines can be empty: <code> EmptyList=Str( @FM, NUM_DATA_LINES$ - 1 ) UnUsed=Set_Property( @Window : ".LIST_SCROLL", "LIST", EmptyList ) </code> Finally, put the following code in the WINMSG handler of the list box. This is the programming that scrolls the edit table in synch width the list box scrollbar. <code> /* WINMSG parameters: hWnd, Message, wParam, lParam */ Hi=int(lParam / 65536) Lo=lParam - Hi * 65536 if (wParam=SB_LINEUP$) or (wParam=SB_LINEDOWN$) or (wParam=SB_THUMBPOSITION$) or (wParam=SB_THUMBTRACK$) or (wParam=SB_PAGEDOWN$) or (wParam=SB_PAGEUP$) then List_TopPos=Get_Property( @Window : ".LIST_SCROLL", "TOPPOS" ) UnUsed=Set_Property( @Window : ".ET", "TOPPOS", List_TopPos ) end </code> I think if you want to do more fancy stuff the Lo value can come in handy. I think it tells you the position while you're dragging the thumb. That's it. Hope I got it right. Had to extract it from a window where I tried several things at once, and clean it up somewhat. Of course you need to do the opposite process too - update the scroll of the list box if the scroll of the edit table changes. Even if the edit table hasn't got any scrollbar of its own, users can scroll it by using the arrow and tab keys. The following POSCHANGED handler should do: <code> ET_TopPos=Get_Property( @Window : ".ET", "TOPPOS" ) UnUsed=Set_Property( @Window : ".LIST_SCROLL", "TOPPOS", ET_TopPos ) </code> - Oystein - </QUOTE> View this thread on the forum...