Oh, I see... Are you saying that you calculate the lookups and actually update the update values to columns that are in the table? Would just have to have enough dummy columns to use so that multiple users could be running different forms each doing different kinds of lookups. Not a bad idea!
Or are you putting a value in an extra column and associating that with a lookup, say to a view? What I was thinking in my case is that the table always has the column CustPart in it, but of course that column is located on the form by itself with no lookup. If I had a view or temp table with the calculated Avg Production per CustPart, then I could have a computed column in my form table called something like CustPart2=Custpart, locate CustPart2 on the form, and have the lookup be to the view where custpart = custpart2 Karen -----Original Message----- From: Dan Goldberg <[email protected]> To: rbase-l <[email protected]> Sent: Sun, Jun 5, 2016 11:51 am Subject: RE: [RBASE-L] - DBGrids vs. Scrolling Regions You can do lookups in enhanced db grids. I just use extra columns that I do not use for the lookup column. I have a couple of them running in production. If you need an example, let me know. Dan Goldberg From: karentellef via RBASE-L [mailto:[email protected]] Sent: Sunday, June 5, 2016 9:14 AM To: [email protected] Subject: [RBASE-L] - DBGrids vs. Scrolling Regions Sitting here watching the French Open on a Sunday.. and thinking about something that I've always struggled with in RBase. Scrolling regions have been there for decades, used to be the ONLY way for us to display multi-row data! When DBGrids were introduced in 7.x, IMO they've always looked more professional, more windows-like. I wish I could replace every region I have with a DBGrid. But my only issue is when I am displaying lookups to other tables, data that has nothing to do with a column in the master table (unlike, say, displaying the name of a customer rather than the table's ID which is totally doable within a grid). Look at the print-screen below. The squared items are form variables located on each row, lookups to display daily production values and the last machine the item was produced on. These are lookups to other tables and have nothing to do with data in the master table other than using its part#. And the user wants to see the data on every row that displays, does not want to click on a row and have the data displayed off to the side (which of course would be easy to do with a grid), and also wants the data to be directly editable. Has anyone put this kind of data into multiple views, and then had "dummy" columns in the master table that you can link to the view using a "pre-defined expression" for the column? Anyone do that? Or another nifty trick I can use? Karen -- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email [email protected]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
