Major Input Problem

[DS]

I have a main form called Orders. on it is a listbox, you choose from
the listbox and the selection goes into the Subform Order Details. This
works great..no problems. The problem is on that Listbox I have a
linked Listbox that pops up and I choose from there to input further
onto the subform. This is listbox is from a completely different table.
What I'm doing is modifying an Item lets say Burger on the main form.
The second form would have Rare. This modifier is attached to Burger so
I would guess it's like a subform on a subform, but this is sloopy
looking. Is there a way to have an unbound form to input this onto,
then when your finished, hit a button where this would be saved to a
record. Or maybe any other suggestion. Lost in the Sauce.
Thanks
DS

 

[DS]

I often use a "side by side" arramangte ment.

Take a look at the screen shots here, and I have a few examples of
sub-subform stuff.
http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm

Thanks, but I'm even having trouble with that to work...What I need is
something like this, Go to www.alohapos.com
then go to products, POS solutions, then table service...
I need a screen like that where I can enter stuff into off of my
listbox. Its got to be a clean white screen. I did it using only the
main product, but it fails when I try to add a modifier to that main
product. My products and modifiers are in two different tables. If
they came from the same table it would work, but since each product can
have several modifiers I need seperate tables. Thanks, your input is
appreciated.
DS

 

[Albert D. Kallal]

I often use a "side by side" arramangte ment.

Take a look at the screen shots here, and I have a few examples of
sub-subform stuff.
http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm

 

[DS]

In looking at that screen, I would use a listbox, or likely a continues form
on the left side.

On the right side for the "large" blue buttons, I would also use a sub-form.
(especially if the buttons need to be changed for different types of
"customer choices" on the left side. As an alternate, the right side buttons
would likely be programmatically filled in by code.

However, I am most confused by:




I don't really understand the above as being a problem? And, I don't see any
problem designing that screen shot either you showed me. If you look at my
grids examples, there are several examples with a left side, and on the
right side, those records belongs to the left side. I mean, the real issues
here is how the left side things like "Lemon Pie" gets into the list in the
first place. However, being able to modify the price of the pie etc. would
not be a problem.

And, there is little, or no reason why the right side can't be some nice
large blue buttons you make on the form...

Hi, Thanks for the response..
Heres what I have...
I have a list of Products in one table [Burgers, Soup...etc.]
In another table I have a list of Modifiers [Rare, Med, Cheese...etc.]
On the Main form I have a Listbox with the Products in it.
Whenever I click on it the Product goes into a continous form that I
have on the Main form. It goes right in without any problem. The
problem arises when I click a button I have called Mods. This brings up
the Modifiers for that Product. This also works just fine and Dandy.
Now heres the hitch...whenever I click on the Modifier to send it to
that continous form it won't go in. The reason being is that the
Modifiers table is set up to work as one to many relationship. The
product is one and the Modifiers is the many. You can't mix the many
within the ones records in the continous form. So i set up another
Subform with a Subform on it, that kind of workd but it was sloppy.
The other problem is this has to look like a Guest Check where the items
stay together Modifiers with Products and keep a running total. I hope
I explained better that before. Is there any way to send the info to
the tables underneath without using a form, then having an unbound
listbox on the main form, send the stuff to there?
Thank you once again.
DS

 

[Albert D. Kallal]

In looking at that screen, I would use a listbox, or likely a continues form
on the left side.

On the right side for the "large" blue buttons, I would also use a sub-form.
(especially if the buttons need to be changed for different types of
"customer choices" on the left side. As an alternate, the right side buttons
would likely be programmatically filled in by code.

However, I am most confused by:

I did it using only the main product, but it fails when I try to add a
modifier to that main product. My products and modifiers are in two
different tables. If they came from the same table it would work

I don't really understand the above as being a problem? And, I don't see any
problem designing that screen shot either you showed me. If you look at my
grids examples, there are several examples with a left side, and on the
right side, those records belongs to the left side. I mean, the real issues
here is how the left side things like "Lemon Pie" gets into the list in the
first place. However, being able to modify the price of the pie etc. would
not be a problem.

And, there is little, or no reason why the right side can't be some nice
large blue buttons you make on the form...

 

[Albert D. Kallal]

I just re-read your original post.

so, that 2nd choice of "rare" "medium" etc. can either be a combo box, or
likely some kind of pop up form here. In fact, I might even make the "right
side" show nice big blue boxes (that you can use a touch screen) with the
options for rare, medium rare..etc.

 

[Albert D. Kallal]

Is there any way to send the info to
the tables underneath without using a form, then having an unbound
listbox on the main form, send the stuff to there?


Sure, but I don't see any reason why the form you pop up (or display on the
right side..or whatever) can't return the value selected to the continues
form

Lets pretend we got:

Menu Item Modifer
Steak Sandwich Medium rare
Coffee no sugar, no cream
etc. etc.

Ok, so on our form, the modify above will likely store the "id" from our
table of Modifiers, but in fact show the description text (this most common
in a database system). Now, either we make the modify field a combo box, or
in fact place a button (or key to press) that pops up a form with our list
of modifies (and, of course the current on selected modifier would show if
any selected).

There is no reason after the user selected a particular modify, when we
close the form, we then stuff the value backing to above continues form.

Lets do the coffee one. Lets press our key, (or whatever we decide to do),
pop up the modifier list. We get:

<no sugar, no cream> the "<>" simply shows this one is selected
in this email!!!
sugar
sugar + cream

So, we got 3 choices here. (and, to be fair, I would consider a design that
allows one to select multiple options, as down the road this will be Much
more flexible. But, lets attack one thing (concept) at a time. So, lets
assume we change the above select to sugar + cream. We now have:

no sugar, no cream
sugar
<sugar + cream>

At this point you either hit enter key, or mouse click (or one of a billion
possible user interface ideas you adopt for this form). When the form close,
we simply stuff in the new value for the modifier like:

frmPrevous!subFormMenuIems!ModiferID = me!lstModifers

The above ONE line of code would grab the current ID we selected from the
above list (sugar, sugar + cream etc), and shove the value into our menu
list form (which is a sub-form in this example). At this point, the form
will automatic update to now show:

Menu Item Modifier
Steak Sandwich Medium rare
Coffee sugar+cream

So, I don't really see the problem as to getting the form to "change" or
return a value. Of course, the above continues form would likely be based on
a query that joins in the modify table id, but DISPLAYS the text. You can
use a combo box to do this, but often it is MUCH SIMPLER to write a query
that joins to the tables, and displays the text. You then base the continues
(sub form in our example) on this query.

The actual code to shove the value back is only one line. For sure more code
and how you setup the "filter" for the popup form would take some work..but
it certainly is doable, and not really that hard at all.

 

[DS]

the tables underneath without using a form, then having an unbound
listbox on the main form, send the stuff to there?


Sure, but I don't see any reason why the form you pop up (or display on the
right side..or whatever) can't return the value selected to the continues
form

Lets pretend we got:

Menu Item Modifer
Steak Sandwich Medium rare
Coffee no sugar, no cream
etc. etc.

Ok, so on our form, the modify above will likely store the "id" from our
table of Modifiers, but in fact show the description text (this most common
in a database system). Now, either we make the modify field a combo box, or
in fact place a button (or key to press) that pops up a form with our list
of modifies (and, of course the current on selected modifier would show if
any selected).

There is no reason after the user selected a particular modify, when we
close the form, we then stuff the value backing to above continues form.

Lets do the coffee one. Lets press our key, (or whatever we decide to do),
pop up the modifier list. We get:

<no sugar, no cream> the "<>" simply shows this one is selected
in this email!!!
sugar
sugar + cream

So, we got 3 choices here. (and, to be fair, I would consider a design that
allows one to select multiple options, as down the road this will be Much
more flexible. But, lets attack one thing (concept) at a time. So, lets
assume we change the above select to sugar + cream. We now have:

no sugar, no cream
sugar
<sugar + cream>

At this point you either hit enter key, or mouse click (or one of a billion
possible user interface ideas you adopt for this form). When the form close,
we simply stuff in the new value for the modifier like:

frmPrevous!subFormMenuIems!ModiferID = me!lstModifers

The above ONE line of code would grab the current ID we selected from the
above list (sugar, sugar + cream etc), and shove the value into our menu
list form (which is a sub-form in this example). At this point, the form
will automatic update to now show:

Menu Item Modifier
Steak Sandwich Medium rare
Coffee sugar+cream

So, I don't really see the problem as to getting the form to "change" or
return a value. Of course, the above continues form would likely be based on
a query that joins in the modify table id, but DISPLAYS the text. You can
use a combo box to do this, but often it is MUCH SIMPLER to write a query
that joins to the tables, and displays the text. You then base the continues
(sub form in our example) on this query.

The actual code to shove the value back is only one line. For sure more code
and how you setup the "filter" for the popup form would take some work..but
it certainly is doable, and not really that hard at all.

Thanks, Albert...
So your saying base my continous form on a Query based on the main item
and the modifiers? I have the main form based on [ORDERS}, the
Continous Form based on [ORDER DETAILS], which has the [Order Number],
[Product ID]. So I should attach the [MODIFIERS] to this as well...So I
have a Query with 3 tables [ORDER DETAILS] [PRODUCTS] [MODIFIERS]....is
this correct? So the continous form would read [ORDER NUMBER],
[PRODUCT ID], [MODIFIER ID]....which means.....now I'm lost...one field
would not always be filled in? How do you add multiple modifiers to an
item them?
Thanks
DS

 

[DS]

Thanks, Albert...
So your saying base my continous form on a Query based on the main item
and the modifiers?

No, I am saying that you can use a query to pull in description text from
another table. (so, I don't care if you got 2 tables, or 20 tables...I was
JUST giving a good suggestion how to display description text in a column
when you only got the id.

So, in your case:

Continous Form based on [ORDER DETAILS], which has the [Order Number],
[Product ID]. So I should attach the [MODIFIERS] to this as well...

Yes, I would think the above makes sense. Remember, I talked about the issue
of do you allow only ONE modifier for each details, or do you allow "many"?
This is simply a design consideration of yours. If you only are going to
allow ONE modifier, then you get:

Order Number, Product ID, Modifier

In my example, I had:

<no sugar, no cream> the "<>" simply shows this one is selected
in this email!!!
sugar
sugar + cream

So with the above, we simply store the Modifier ID in the Modifier. Of
course, this is not really a relation, but simply a look up value. And,
since we store only the "id" of the modify (along with product id, order
number etc.), then we need a way to display the "description" text from the
modifiers table.

I mentioned, that perhaps a better design would be to allow MORE then one
modifier. This would make the UI for the user simpler, and also make the
system more flexible (however, then to select sugar + cream, it would take
two steps...but likely a better solution (and, you would not have to list
all possible combinations of modifiers for a given detail)). Of course this
better one to many design will takes more work, and more skill on your part.
So, in place of simply storing a simply modiferID, we now are talking about
allow "many" modifiers. So, this would be a one to many relationship. This
would mean we dump the above modiferID, and thus now have to create a
another table. We could call it

"DetailsModiferList"

This table would simply be a "list" of the modifiers the user selected.
Again, we only need to do this if you are going got allow MORE then one
modifier for each details. Thus, our above list now becomes:

sugar
cream
whipping cream

In the above, if we don't select anything, the coffee is black. If you want
sugar, you select sugar. And cream, you select cream. This design would thus
allow MORE then one modifier (and, it is now clear this is what you want)..

<sugar>
<cream>
whipping cream

So, we select the above two modifiers, and when we close the form, we would
NOT stuff the mod id back into the continues form (with order number, and
product id). What we would do is add two records to our table called
OrdersModifedList. (or, we have a design such that you have to add/enter the
modifiers in this pop up continues form. So, really, either you have some
listbox that lets the user select some modifiers, and then write these
modifiers into our OrderModifedList table (by using some code), or have a
form that actually edits the OrdersModifedList table directly (this would
requite less code, as the form would be adding the records..but some code is
going to be needed in either case).

Anyway, my point about using sql to join stuff in was simply to use sql to
display the "text" of the modifier in place of the id. Often, we will and do
use a combo box to do this. However, often we also can use a query to
accomplish this. Much of how this works will be based on how you want the
final UI to work. If the modifier pop up form is a continues form based on a
comb box, then VERY little code would be needed. I would consider building
this form first to get a prototype working. As time progress, I would
probably make this a list box so the user can simply click on each extra
modifier they want (and clicking again on a modifier would un-select it).
Also, there is question of do we use some type of popup form that appears
WHEN you want to change modifiers, or simply a side by side type arrange
(like many of my grid examples have). My bets are a side by side type system
where as you scroll up and down through the details list, on the right side
the "modifies" list shows ..and could be changed at that point (or, you have
to popup a form..and then select the modifiers -- this is extra step but
again, this kind of UI stuff is up to you, and one approach is going to be
preferred over the other depending on how the uses will work with this
stuff).

Thanks Albert, I'm going to digest this and play around some more.
I'll let you know how it works out.
DS

 

[Albert D. Kallal]

Thanks, Albert...
So your saying base my continous form on a Query based on the main item
and the modifiers?

No, I am saying that you can use a query to pull in description text from
another table. (so, I don't care if you got 2 tables, or 20 tables...I was
JUST giving a good suggestion how to display description text in a column
when you only got the id.

So, in your case:

Continous Form based on [ORDER DETAILS], which has the [Order Number],
[Product ID]. So I should attach the [MODIFIERS] to this as well...

Yes, I would think the above makes sense. Remember, I talked about the issue
of do you allow only ONE modifier for each details, or do you allow "many"?
This is simply a design consideration of yours. If you only are going to
allow ONE modifier, then you get:

Order Number, Product ID, Modifier

In my example, I had:

<no sugar, no cream> the "<>" simply shows this one is selected
in this email!!!
sugar
sugar + cream

So with the above, we simply store the Modifier ID in the Modifier. Of
course, this is not really a relation, but simply a look up value. And,
since we store only the "id" of the modify (along with product id, order
number etc.), then we need a way to display the "description" text from the
modifiers table.

I mentioned, that perhaps a better design would be to allow MORE then one
modifier. This would make the UI for the user simpler, and also make the
system more flexible (however, then to select sugar + cream, it would take
two steps...but likely a better solution (and, you would not have to list
all possible combinations of modifiers for a given detail)). Of course this
better one to many design will takes more work, and more skill on your part.
So, in place of simply storing a simply modiferID, we now are talking about
allow "many" modifiers. So, this would be a one to many relationship. This
would mean we dump the above modiferID, and thus now have to create a
another table. We could call it

"DetailsModiferList"

This table would simply be a "list" of the modifiers the user selected.
Again, we only need to do this if you are going got allow MORE then one
modifier for each details. Thus, our above list now becomes:

sugar
cream
whipping cream

In the above, if we don't select anything, the coffee is black. If you want
sugar, you select sugar. And cream, you select cream. This design would thus
allow MORE then one modifier (and, it is now clear this is what you want)..

<sugar>
<cream>
whipping cream

So, we select the above two modifiers, and when we close the form, we would
NOT stuff the mod id back into the continues form (with order number, and
product id). What we would do is add two records to our table called
OrdersModifedList. (or, we have a design such that you have to add/enter the
modifiers in this pop up continues form. So, really, either you have some
listbox that lets the user select some modifiers, and then write these
modifiers into our OrderModifedList table (by using some code), or have a
form that actually edits the OrdersModifedList table directly (this would
requite less code, as the form would be adding the records..but some code is
going to be needed in either case).

Anyway, my point about using sql to join stuff in was simply to use sql to
display the "text" of the modifier in place of the id. Often, we will and do
use a combo box to do this. However, often we also can use a query to
accomplish this. Much of how this works will be based on how you want the
final UI to work. If the modifier pop up form is a continues form based on a
comb box, then VERY little code would be needed. I would consider building
this form first to get a prototype working. As time progress, I would
probably make this a list box so the user can simply click on each extra
modifier they want (and clicking again on a modifier would un-select it).
Also, there is question of do we use some type of popup form that appears
WHEN you want to change modifiers, or simply a side by side type arrange
(like many of my grid examples have). My bets are a side by side type system
where as you scroll up and down through the details list, on the right side
the "modifies" list shows ..and could be changed at that point (or, you have
to popup a form..and then select the modifiers -- this is extra step but
again, this kind of UI stuff is up to you, and one approach is going to be
preferred over the other depending on how the uses will work with this
stuff).