Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Microsoft Office > Access and Access VBA > Access
| Search | Today's Posts | Mark Forums Read
Access Discussion of Microsoft Access database design and programming. See also the forums for Access ASP and Access VBA.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old September 4th, 2003, 05:54 PM
Authorized User
 
Join Date: Sep 2003
Location: , , Canada.
Posts: 52
Thanks: 0
Thanked 0 Times in 0 Posts
Default Embedding subforms onto continuous form

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] </u>
item 1 |[u]Action 1</u>|
item 2 [u] </u>
item 3 |[u]Action 2</u>|
total: $xxx

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

Customer: 2
-----------------
Order: 2 [u] </u>
item 1 |[u]Action 1</u>|
item 2 [u] </u>
item 3 |[u]Action 2</u>|
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
Roni.Estein@e-drugscanada.com
https://www.e-drugsCanada.com
__________________
Roni Estein
Roni.Estein@e-drugscanada.com
https://www.e-drugsCanada.com
 
Old September 4th, 2003, 09:50 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

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

 
Old September 5th, 2003, 07:23 AM
Friend of Wrox
Points: 4,007, Level: 26
Points: 4,007, Level: 26 Points: 4,007, Level: 26 Points: 4,007, Level: 26
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Lansing, Michigan, USA.
Posts: 1,151
Thanks: 2
Thanked 14 Times in 14 Posts
Send a message via ICQ to SerranoG Send a message via AIM to SerranoG
Default

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
 
Old September 5th, 2003, 11:15 AM
Authorized User
 
Join Date: Sep 2003
Location: , , Canada.
Posts: 52
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
Roni.Estein@e-drugscanada.com
https://www.e-drugsCanada.com
 
Old September 5th, 2003, 07:16 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

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





Similar Threads
Thread Thread Starter Forum Replies Last Post
colour continuous form palmer Access 4 July 29th, 2009 03:26 AM
Continuous Form - Images nilkanth Access 9 July 29th, 2009 02:30 AM
Embedding Office Web Components form JSP sunildath_019 JSP Basics 0 March 17th, 2004 06:11 AM
Embedding Office Web Components form JSP sunildath_019 Pro JSP 0 March 17th, 2004 06:10 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.