Hi,

I have a seven column edittable. Columns 1-5 have one row entries. Column 6-7 can have as many as 5 rows. How do I manage this?

Marty

Marty,

You have to store the @SVM (or whatever delimiter you are using) data in a hidden editline control and programmatically update your columns with the first element for display purposes. Then you need to give your users a way to "drill" into the cell to see the array of data linked to that cell. Usually you would just display a dialog box with it's own edittable and pass in/out the array of data.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Marty,

I use a different method to Don's. See . But I run the risk of running out of space - each cell can only contain 999 chars.

- Oystein -

Oystein,

Plus the end user has to see the delimiter. Uff da!

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Marty,

Possibily… you could associate the MV's. I am not sure you can do that with your data.

Kinda like if you got a table that audit trails the printing of 2 types of invoices. Delivery and revenue. So you would have 2 sets of associated MV's. The delivery association and the revenue association.

So the columns for the delivery might be like… Print_Date, Print_Time, Print_UserID. And the columns for the revenue might be like… Print_Date, Print_Time, Print_UserID. If so, I would make up two edit tables, one for the delivery MV associations with columns for the print date, print time, and print userid. And another for the revenue MV associations.

Basically I seperate the MV's into seperate edit tables. One edit table for each associated group of MV's.

Don,

Neida. The edit table is hidden. Data is presented and manipulated through a non-bound control.

- Oystein -

Marty,

Read your posting again. One row entries? Why do you have the "one row" data in the edit table at all?

- Oystein -

Oystein,

Ah, didn't catch that the edittable holding the delimited data was hidden.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Oy,

I'm entering a whole array of data. I could have up to a hundred different entries. For example:

Column 1=Part Number

Column 2=Description

Column 3 - 5=Some other fact

Column 6 - 7=Components to make up sub-assembly 1 and 2

To make matters worse, I'm importing this data from individual data and creating this edittable.

Marty

Marty,

What exactly is the purpose of your window? You say the data is imported into the window, but what happens after that? Does the user just browse the data? Or may the user change the data?

One possibility might be to split the data over two edit tables. In the first edit table you show parts data from columns 1-5, in the second one components data from columns 6-7. If the user clicks the first entry in the parts edit table, the component data for the first part shows in the components edit table. If the user clicks the second entry in the parts edit table, the component data for the second part shows in the components edit table. Etc. So the user can only see component details for one part at a time. Is that acceptable?

Exactly how this should be implemented might depend on your data.

One possibility could be to keep columns 6 and 7 in the parts edit table also, but hidden from the user. That's what I suggested

in my other posting. Some handlers, e.g in the parts edit table would keep the components edit table updated from these hidden columns.

But this method would not work if the data for columns 6 and 7 is too voluminous. Each cell can only store 999 chars.

What are your columns 6 and 7? Is 6 a component id - a foreign key to a components table, while 7 is a symbolic Xlating some textual description from the components table? Then you don't need column 7 in the parts edit table, only column 6.

- Oystein -

Oystein,

I sure didn't know what I was getting into when I started this. The end user is me.

The product that we are talking about is mattresses. All mattresses must have a tag on them displaying the internal contents. The 999 character limit is not a problem. Most won't even reach 150.

The company that I do this for uses a code for the internal contents. There is also an entry window for the specifications to be entered. This window uses the code. The key elements are (1) the cover number and (2) the description of the mattress.

In order to check on the accuracy of the specifications, it was a multi step process:

1. Create an S/List of specifications

2. Print it out

3. Review

4. Go back to specifications to make any changes.

I am trying to create the window whereby all the specifications are in one location and I can make the changes directly. I thought that an edittable would fill that need. So, I envision the edittable to look something like this:

Cover Desc Customer … … Fill1 Fill2

1000 Whitney Bed Store Data Data Foam Cotton

                                      Pad     Foam 

                                      Fiber   Steel 

1001 Houston Sleep Shop Data Data Pad Foam

                                      Fiber   Cotton

                                              Steel

The amount of components under "Fill1" and "Fill2" can vary from none to five.

Ideally, all this would be on one edittable and there would have to be the proper amount of empty rows on the edittable. If I have to use two edittables then the VScroll would also have to be synchronized.

Well, there you have it!

Marty

Oystein,

The example didn't come out very well in my other note. I'll try again differently.

Column1=Cover

Column2=Description

Column3=Customer

Column4=Misc Data

Column5=Misc Data

Column6=Mattress Fill

Column7=Box Spring Fill

The components under "Fill1" in Row1 are Foam, Pad and Fiber.

The components under "Fill2" in Row1 are Cotton, Foam and Steel.

The components under "Fill1" in Row4 are Pad, Fiber and Steel.

The components under "Fill2" in Row4 are Foam and Cotton.

Hope this helps.

Marty

Marty,

Here's your format, with everything in one edit table:

+----+----+----+----+----+----+----+

|covr|desc|cust|msc1|msc2|mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|covr|desc|cust|msc1|msc2|mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

I can see the advantages of that approach. You can get away with almost no programming, but it demands a disciplined user. If I did it this way I'd like to have some programming to aid the user in filling out correctly. And I'd think through if there were cases where the program will have problems interpreting the data. E.g, what does the following mean? How many mattresses?:

+----+----+----+----+----+----+----+

|covr|desc|cust|msc1|msc2|mfil|bfil|

+----+----+----+----+----+----+----+

|covr|    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|covr|desc|cust|msc1|msc2|mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

|    |    |    |    |    |mfil|bfil|

+----+----+----+----+----+----+----+

Three if the second line is interpreted as an entry with some data missing. Two if the value in that second line's first column is interpreted as an error - a cell that was meant to be empty.

Have you got horizontal space for the following format?:

+----+----+----+----+----+------------------+------------------+

|covr|desc|cust|msc1|msc2|mfil,mfil,mfil    |bfil,bfil,bfil    |

+----+----+----+----+----+------------------+------------------+

|covr|desc|cust|msc1|msc2|mfil,mfil,mfil    |bfil,bfil,bfil    |

+----+----+----+----+----+------------------+------------------+

With this alternative you will need a collector window for the values of the "fill" cells (columns 6 and 7), with another edit table:

+----+----+

|mfil|bfil|

+----+----+

|mfil|bfil|

+----+----+

|mfil|bfil|

+----+----+

|    |    |

+----+----+

|    |    |

+----+----+

What I suggested in my earlier posting actually was to have both edit tables - the main window's and the collector's - in the main window. These edit tables should not be synchronized as such. The second edit table's task would be to show details ("fill" data) for just one mattress - the one currently selected in the first edit table.

- Oystein -

Marty,

(Hope my posting's better formatted this time.)

Here's your format, with everything in one edit table:

+----+----+----+----+----+----+----+
|covr|desc|cust|msc1|msc2|mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|covr|desc|cust|msc1|msc2|mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+

I can see the advantages of that approach. You can get away with almost no programming, but it demands a disciplined user. If I did it this way I'd like to have some programming to aid the user in filling out correctly. And I'd think through if there were cases where the program will have problems interpreting the data. E.g, what does the following mean? How many mattresses?:

+----+----+----+----+----+----+----+
|covr|desc|cust|msc1|msc2|mfil|bfil|
+----+----+----+----+----+----+----+
|covr|    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|covr|desc|cust|msc1|msc2|mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+
|    |    |    |    |    |mfil|bfil|
+----+----+----+----+----+----+----+

Three if the second line is interpreted as an entry with some data missing. Two if the value in that second line's first column is interpreted as an error - a cell that was meant to be empty.

Have you got horizontal space for the following format?:

+----+----+----+----+----+------------------+------------------+
|covr|desc|cust|msc1|msc2|mfil,mfil,mfil    |bfil,bfil,bfil    |
+----+----+----+----+----+------------------+------------------+
|covr|desc|cust|msc1|msc2|mfil,mfil,mfil    |bfil,bfil,bfil    |
+----+----+----+----+----+------------------+------------------+

With this alternative you might need a collector window for the values of the "fill" cells (columns 6 and 7), with another edit table:

+----+----+
|mfil|bfil|
+----+----+
|mfil|bfil|
+----+----+
|mfil|bfil|
+----+----+
|    |    |
+----+----+
|    |    |
+----+----+

What I suggested in my earlier posting actually was to have both edit tables - the main window's and the collector's - in the main window. These edit tables should not be synchronized as such. The second edit table's task would be to show details ("fill" data) for just one mattress - the one currently selected in the first edit table.

- Oystein -

Oystein,

While I'm the end user, I think that I will go for the horizontal example. I think it would be extremely difficult to program the import of the data to space out correctly. I didn't want to spend this much time on this project so I will settle for this solution.

I appreciate the time that you spent helping me out. Thank you!!!

Marty

View this thread on the forum...