I’m trying to get a simple grid of line items on a form. I say simple, but there are 70 lines with 8 items for each line. That’s 560 fields (I didn’t create this database).
When I use the constructor template for line items, it creates about four or five full size fields for the last two lines but all the rest are just black squares. If I try to stretch them out I can see that they are actually text editor objects, but trying to stretch all those out and line them up would be worse than doing it manually.
Is there a limit to the amount of fields the default template will create?
Also, while I’m editing the template, it starts making the line items out of the blue. If I add a tag, or delete a field, off it goes. Not always, but I never know when it’s going to happen. With 560 fields, it really slows down my progress.
Not that I am aware of, and I can’t think of any reason for a limit other than the maximum dimensions of a form (which I think. you should be well under).
No reason I know of for that to happen. Obviously I used this heavily when creating this feature and I never experienced that.
Maybe I’m wrong, but to me line items are like Qty1, Qty2, Qty3, Price1, etc. That would make your database above A1,A2,A3, B1,B2,B3. Then your grid would be A1, A2, A3; next record would be B1,B2,B3, etc.
If I could get the template to work, it would be nice to be able to open a form and tell it to make line groups 1-10, them open a second form and make 11-20.
Aha – the widths of the line item fields are all shrunk down to the minimum possible width! That’s the cause of the problem. When you first open the Constructor window, it defaults to setting the line item widths to the width used in the data sheet. In this case that turned out to be ZERO! as you can see here.
So it constructed exactly what was asked. I simply edited the widths in the template to more reasonable values before pressing the Construct button, and it worked immediately. Here’s my revised template.
That’s an ok idea, but it’s really pretty easy to just generate all of the items at once, then copy and paste them to other forms. So I probably won’t bother to implement this partial generation idea any time soon. It certainly wouldn’t have helped any with this issue.
In the future, I would suggest not making the line items super narrow like this, instead just hide them. Panorama X 10.2 has a handy Hide Line Item Fields command that can do this for you in a jiffy. On the other hand, the template should never default to zero width, so I’ve made a note that that should be fixed. In the meantime, the fix is super easy, and in any case, you are almost certainly not going to want to go with the default widths in this case. You probably want to tweak the column titles as well.
First off, this is not my database but one I am converting for a someone. I would never create a database with 75 sets of line items. Also, I have never shrunken fields to 0 so, good catch.
Besides noting that the template should never default to zero, you should be aware that it also gave me an error right off the bat that sent me down this rabbit hole. When the default width is zero, the template doesn’t get created at all but instead an error is displayed in red at the bottom of the template which said “QtyΩ is not a valid line item field name”. I tried each of the field names, watched the Automatic Form Construction videos and played with it for hours. I thought the omega was causing it not to recognize the field name. Nothing was mentioned about getting that error or that 0 field widths would cause such a problem. Not complaining; just an observation. So I guess if you fix the fact that the default can’t be zero, it will also fix that incorrect error message.
Well, I didn’t know it caused such a problem, because it never occurred to me to try to generate a template with field widths of zero. When I opened the Constructor window, the zero widths immediately jumped out at me, especially since your screen shot seemed to show a problem with the widths. So the first thing I did was change the width values, and presto, a good form!
