It wasn't Cetin you were responding to . . .

I use grids in a variety of ways. They are used to allow the user to quickly locate a record to edit. After locating the record, the user will often have a grid on the form that handles child data, which is populated by a parameterized view. So all the data input for a child record is handled via the grid. I use grids on forms that print reports often times. The user might be picking one or more records to print, a category of records to print, etc.

Anytime a user has to scroll left and right to enter data it's a pain. In your case, with mostly read-only data, it's a little different. But the human brain still has difficulty processing data that is so spread out and not all visible on the screen at one time. 120 columns and many row's, I'd imagine? In that case, people look for ways to summarize or visualize the data via bar charts, pie charts, holograms, laser misting, rubber chicken graphs, something! And so it's our job to try to accommodate them. Sometimes it's easier said than done. It's a challenge, no doubt. I confess that I'm glad I'm not developing the kind of app you mention. <g>


>Cetin --
>
>Ah, my programming universe is so different that yours.
>
>I work primarily with what I understand to be called "data warehousing". I read bunches of data from a SQL Server database, and my applications merely report on that data. Thus, for almost all the grids I have (and probably 90% of my forms have at least one grid), the grid is populated by a cursor, not a table -- and thus no data input at all.
>
>Furthermore, almost all grids are much too wide to fit within the form, and thus require horizontal scrolling. Most of these have periods of time, either past or future -- and the number of periods is user selectable. One application allows the user to select which columns to see, with the current max about 120.
>
>Cheers,
>
>Jim
>
>
>>Your "last question" is a good one. I imagine this might cause a problem, but I generally set my grids so that the user does not have to scroll horizontally. Of course, they can widen the columns and make it scroll, but when you have to scroll horizontally to enter data, it makes it a real pain to work with the grid, and I use another data entry technique.
>>
>>>Cetin --
>>>
>>>Thanks for your responses.
>>>
>>>About my last question. It seems like your answer about recno() and relativerow aren't quite the easy answer if the recordsource is either filtered or sorted.
>>>
>>>My intent was somewhat different -- along the lines of other threads that have asked about lines with alternating backcolors. If, during the refresh, I could learn which row was the first row, I thought I could then know which relative row I was in during the refresh -- and set dynamicbackcolor accordingly.
>>>
>>>I think that this technique would probably work -- until the users scrolls up or down, then all gets mucked up. Well, it was a nice thought, albeit a short-lived one.
>>>
>>>(I have another application of this, having to do only with the top line ....)
>>>
>>>Last question: does this technique with dynamicfontshadow work even if the user has scrolled to the right? (so that the first column was no longer visible?)
>>>
>>>Thanks,
>>>
>>>Jim