Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Microsoft Office > Access and Access VBA > Access
Password Reminder
Register
| FAQ | Members List | Calendar | 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 tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
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
Reply With Quote
  #2 (permalink)  
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

Reply With Quote
  #3 (permalink)  
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
Reply With Quote
  #4 (permalink)  
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
Reply With Quote
  #5 (permalink)  
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

Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


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



All times are GMT -4. The time now is 10:15 AM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.