Embedding subforms onto continuous form

roniestein · September 4th, 2003, 05:54 PM

I am using Access XP to develop a small test application.

When creating an access report grouping objects together can be easily done is there a way to accomplish this in a form

The example is a report which looks like this

Customer: 1
-----------------
Order: 1
item 1 < -- purchased line items
item 2
item 3
total: $xxx

Order: 3
item 1
item 2
item 3
total: $xxx

Customer: 2
-----------------
Order: 2
item 1
item 2
item 3
total: $xxx

I would like to create a form of the same nature, with some active buttons beside each specific order.

Customer: 1
-----------------
Order: 1 [u] 
item 1 |[u]Action 1|
item 2 [u] 
item 3 |[u]Action 2|
total: $xxx

Order: 3 [u] 
item 1 |[u]Action 1|
item 2 [u] 
item 3 |[u]Action 2|
total: $xxx

Customer: 2
-----------------
Order: 2 [u] 
item 1 |[u]Action 1|
item 2 [u] 
item 3 |[u]Action 2|
total: $xxx

I have tried everythings my books have to offer, yet they seem to leave out any more advanced UI concerns.

The closest idea I can find is a continuous subform inside a continuous from, yet that seems not to be possible. A single form breaks after each details section which is not helpful.

Thanks in advance for any light you may shed on this topic
-Roni

Roni Estein
[email protected]
https://www.e-drugsCanada.com

Bob Bedell · September 4th, 2003, 09:50 PM

Hi Roni,

I suspect that the reason your books don't touch on this particular UI design is because its madness!!! Just kidding. :) Please don't take that the wrong way, but don't do it to yourself! :):)

The most advanced UI principle I've ever stumbled aross is: choose the simplest model possible. Joel Spolsky's three assumptions are helpful here:

People can't read
People can't control the mouse
People can't remember anything

And lastly, but most importantly, people always have better things to do with their lives than figure out how our applications work.

I make a point of showing the user only what they need at the moment, and make it as intuitive as possible to get to that. If they need to see a list of customers or orders or order items they get it in a read-only list box, sometimes a couple on a form if parent/child relationships apply. Double-clicking a list box item, or clicking an Add or Edit button with an item selected in the list opens a columnar form displaying the one record they need to edit (or a blank form for inserts). They can only physically edit one record at a time, so thats all they get. I've challenged myself to never use another subform again, especially for editing. They're an Access-specific GUI control. The design techniques you learn with them aren't transferrable to other platforms (i.e., Visual Studio and Visual Studio.NET); the design techniques you learn with list controls are.

"Simplify, simplify...Our life is frittered away by detail. An honest man has hardly need to count more than his ten fingers, or in extreme cases he may add his ten toes, and lump the rest. Simplicity, simplicity, simplicity!...instead of a million count half a dozen, and keep your accounts on your thumb nail."

Thoreau still beckons, as long as I can take my laptop.

Best,

Bob

SerranoG · September 5th, 2003, 07:23 AM

Roni,

I second Bob's thoughts. I never use continuous forms or subforms. I think the easiest and clearest way to get what you want is have a single form that has navigation buttons to get to each customer one at a time. Then have a single subform (not continuous) in that form with navigation buttons that shows each customer's order (with its items and total), again one at a time. You don't need to see all of them all of the time on a form. On the main form, if you like, you can have a grand total of all the orders for that customer summed up. If you need to see everything laid out in plain view, that's what the report is for.

This approach will require much less work and stress on your part.

Greg Serrano
Michigan Dept. of Environmental Quality, Air Quality Division

roniestein · September 5th, 2003, 11:15 AM

Hi Bob and Greg,

I really appreciate your advice on this matter, and it may a better way to go. Perhaps if I elaborate a bit you could point me in the right direction.

The specific environment we work in has customers placing refill orders on a regular basis. Our prices are constantly changing on a number of items depending on a series of variables some of which are beyond our control.

One action we wold have with each order is the ability to place a new (refill) order with all the current prices for the specific products. Another action might be to place a refill order with the prices listed in a particular order, and there are others yet.

This second might be done for several reasons, like giving our customers the best deal we can, for customers who have paid in advance, or others that may crop up.
Originally we thought to only including the last two orders but sometimes people place orders in parts that may be consolidated for a better savings, or move through a 4 order schedule. Being able to scroll through a customers history and perform these actions seems like the most logical way to plan this aspect of our functionality.

A second part of this question, would an interface developed in visual c++ or visual basic run as fast as an access front end?

Thanks for your input on this thread.:)

-Roni

Roni Estein
[email protected]
https://www.e-drugsCanada.com

Bob Bedell · September 5th, 2003, 07:16 PM

Hi Roni,

Sounds like you just need to have a field in your db to track historical prices of products (prices associated with past orders) and current prices (prices associated with new orders, which can be adjusted manually). Thats often accomplished by placing the historical price field in an order details table, and placing the current price field in a products table. The order details table functions as an "association" or linking table between the products table and the orders table. The linking table allows you to implement the many-to-many relationship between products and orders. The primary key of the the products table and the primary key of the orders table are placed in the linking table where they do double duty by serving as both foreign keys and a composite primary key for the oder details table. Have a look at the table schema of the sample Northwind.mdb that ships with Access and you'll see what I'm talking about. When you need a customers historical prices for a given product, simply join the products and order details table in a query. This is all set up in your table schema though, and not your user interface.

Don't think the question about interface performance is really answerable though. If the number of users hitting your db is small enough to make an Access backend viable in the first place, probably doesn't make much difference which interface you use. All the processing gets done on the client machine regardless.

HTH,

Bob