If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Radio Button multiple selections
Hey, I have a form with 20 individual unbound radio buttons (Options).
What I want to do is allow users to select any one or many of the option buttons and produce a query or table that will display data relitive only to the choices they made. The table in question that my current query is tied to has all 20 elements in it and this does not seem to be the way to go (Because everthing shows up and the items they do not select just have blank data). I'm sure there must be some code or a report generator that would carry out this task. -- NGNN Submarines (Mark) |
#2
|
|||
|
|||
Radio Button multiple selections
What you seem to be talking about is a query with a variable number of fields.
I believe this is the idea behind using QueryDef, but I am not very familiar with that procedure, so I will not try to comment further just now, except to say I may have missed something. However, I will say that you probably need to open the query directly rather than the form, as the form will be looking for the Record Source values for bound controls. Either that or you will somehow have to build a form dynamically, using only the fields in the resulting recordset. It may be possible, but I can't begin to describe how. It seems rather a curious thing that the user cannot limit the number of records in the recordset, but rather would be able to restrict the fields in the recordset. Typically the user would be able to limit records to those for a specific [BUYER] (or several buyers, with a multi-select list box), for instance. In any case, I don't see that anything is gained by using an alias for each field. Probably no harm either, but quite a bit of extra typing for the code. If the code is in FRM_Purchace Master Menu, you could use something like: If Me.[option113] = True Again, saves a lot of typing, and is probably more efficient. Also, you will be doing yourself a favor if you name the option groups and other controls with meaningful names (optBuyer, for instance). Sub Guy wrote: What I am trying to do is come up with a way to allow users to utilize a form with 20 radio buttons that allows them to generate a query style result with a multiple chioce selection ability. Maybe this is not the way to go. I am not following your suggestions about changing the query definitions and when they would be changed. It looks like what you have would work, I'm just having trouble applying it. What is it you are trying to do?? Right now, your query says "Show me all of the fields in the table, but inly show the data is the corresponding radio [quoted text clipped - 145 lines] data). I'm sure there must be some code or a report generator that would carry out this task. -- Message posted via http://www.accessmonster.com |
#3
|
|||
|
|||
Radio Button multiple selections
IT WORKED................
I thank you very much (Steve) for the code that made this work. -- NGNN Submarines (Mark) "BruceM via AccessMonster.com" wrote: What you seem to be talking about is a query with a variable number of fields. I believe this is the idea behind using QueryDef, but I am not very familiar with that procedure, so I will not try to comment further just now, except to say I may have missed something. However, I will say that you probably need to open the query directly rather than the form, as the form will be looking for the Record Source values for bound controls. Either that or you will somehow have to build a form dynamically, using only the fields in the resulting recordset. It may be possible, but I can't begin to describe how. It seems rather a curious thing that the user cannot limit the number of records in the recordset, but rather would be able to restrict the fields in the recordset. Typically the user would be able to limit records to those for a specific [BUYER] (or several buyers, with a multi-select list box), for instance. In any case, I don't see that anything is gained by using an alias for each field. Probably no harm either, but quite a bit of extra typing for the code. If the code is in FRM_Purchace Master Menu, you could use something like: If Me.[option113] = True Again, saves a lot of typing, and is probably more efficient. Also, you will be doing yourself a favor if you name the option groups and other controls with meaningful names (optBuyer, for instance). Sub Guy wrote: What I am trying to do is come up with a way to allow users to utilize a form with 20 radio buttons that allows them to generate a query style result with a multiple chioce selection ability. Maybe this is not the way to go. I am not following your suggestions about changing the query definitions and when they would be changed. It looks like what you have would work, I'm just having trouble applying it. What is it you are trying to do?? Right now, your query says "Show me all of the fields in the table, but inly show the data is the corresponding radio [quoted text clipped - 145 lines] data). I'm sure there must be some code or a report generator that would carry out this task. -- Message posted via http://www.accessmonster.com . |
Thread Tools | |
Display Modes | |
|
|