I'm trying to create a database to add to my main application that will track our outgoing packages. What I wanted was a tableview sort of matrix, and I thought I had it working -- but then it came crashing back to earth. Here's a screenshot to make it a little bit clearer what I'm attempting.



Notice the three radio buttons at the top. Clicking on one of them will call a function that will generate the headers and the main body text underneath. I used a fixed width text for the 'title bar' at the top with the headings, and the main text area. The buttons at the bottom (ADD, HANDOFF, EDIT, DELETE) use FormAsDialog to call up popups that allow users to interact with the database.

My initial thought was to just use a tableview of the form itself, but couldn't picture how to make the title columns change depending on the 'view' of the database.

The nine fields below are only hidden to non-Admins, and my functions draw from those fields for heading names, fields to check, and the padding needed. Here are the two other 'views':





And it appeared to work, too! There's only one record in the database itself containing the values for the nine fields below that control the display. I've used FormNotify to ensure that users cannot add or delete records, etc. My plan was for the employee(s) who prepare packages add the records, and our sales reps can view this form and see what's available for pickup. Every package gets a unique package number. Our problem is that a lot of different people prepare packages and a lot of people hand off these packages to customers, messengers. The packages are also sometimes in multiple locations. Also, we do a lot of trade work, so often the end client (picking up the package) is not the name of the company that ordered the product.

("It's a mystery, inside a conundrum, wrapped in an enigma!")

So someone will ask for a package and have no idea what it is, who it is intended to reach, etc. Messengers often arrive only with an address for where the package is headed -- no company name. With this system I was hoping that our sales reps could tell the end user, "Your package number is #187." and it might reduce some of the companywide gyration required for finding someone's package.

Here's the hitch. If this one record is open for the shipping area, it appears as 'LOCKED' to the other users, and so the main area of the form cannot be updated, or even viewed. I'm pretty sure I've painted myself into a corner on this one, but figured I would ask if anyone had any ideas on how to salvage this, or a better way of achieving it.

As a workaround I tried to declare the contents of the nine bottom text fields using the 'On Retrieve Spec Open" area, but it doesn't allow for the main viewing area to update. My guess is that would rule out using global variables.
Any ideas?

Apologies for the overlong post.

Carl Underwood wrote on Apr 6^th, 2012 at 2:24am:


Ok, so I would make three forms all for the underlying database, but each only showing the relevant fields for that 'view'. And yes, you are correct in thinking that all the fields represented are in the same database. Sorry it took me a while to respond, Carl, I wanted to digest what you said carefully before responding.

Quote:


I'm not understanding the three different parent forms. I would need one parent form for 'WAITING' that displayed a table subform of a 'waiting'-optimized form of the PACKAGES database, and then a 'PICKED UP' parent form with the next specialized subform linked to it, etc.? Or could I have a single parent form, and the buttons would popup @FormAaDialog versions of the specialized subforms?

Maybe tabbed tableview subforms, with the radio buttons forcing switching to the tabbed view?

Thanks for the help Carl, I appreciate it.