...Rubber chicken graphs...

Yes, a Steve Martin invention. But the laser misting thing was something that came to mind. I read about some company that had a unit that would - if I remember correctly - drop a wall of mist and they could draw text and graphics in it with lasers (I think). Something like that. They were going to market it to companies displaying their wares at trade shows. You could position it over an isle and people would end up walking right through it. Kind of cool, but I've never seen one in action.

>Rubber chicken graphs, eh? I like that.
>
>Yes, there are problems for the user when columns are off too far to the right. For somebody who's looking at monthly data, such as on financial statements, this is impossible to avoid. Most of any users are avid Excel users, and are very familiar with spreadsheets too wide to see all at once.
>
>Of course, there are still things that can be done. LockColumns helps, of course. Placing most significant (whatever that means) columns first, to avoid scrolling, helps a lot too.
>
>I also use dynamic tool tips which can be attached to any cell in a grid. Like tooltips as you usually think of them, but dynamic (created on the fly), of any size, with control of color, font, and alignment. I put little triangles in the corners of cells having these tips, so users know to look for them. This allows for display of lots of information available just by mouse movement.
>
>Examples: (1) cell contains the inventory count at a particular location; tooltip shows detail by 'bin' within the location (2) cell contains total of open sales orders, tooltip shows customer, date, amount.
>
>Cheers,
>
>Jim
>
>
>>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