Re: Users want Check Boxes for entry
From: Allen Browne (AllenBrowne_at_SeeSig.Invalid)
Date: 01/21/05
- Next message: AbeR: "RE: Control Buttons don't work anymore!"
- Previous message: '69 Camaro: "Re: Flagging if record has been modified"
- In reply to: Melvis: "Re: Users want Check Boxes for entry"
- Next in thread: Sprinks: "RE: Users want Check Boxes for entry"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 21 Jan 2005 09:31:57 +0800
It's easy enough to use the Open event of the form to OpenRecordset into the
Application_rejected_reasons table, and then loop through the checkboxes
setting the Caption of the attached label.
This example assumes checkboxes named "chk1", "chk2", etc. where the number
matches the primary key number of the reason in the table:
Dim rs as DAO.Recordset
Dim strCtrlName As String
Set rs = dbEngine(0)(0).OpenRecordset("Application_rejected_reasons")
Do While Not rs.EOF
strCtrlName = "chk" & rs!ID
Me(strCtrlName).Controls(0).Caption = rs!Reason
rs.MoveNext
Loop
rs.Close
Set rs = Nothing
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Melvis" <Melvis@discussions.microsoft.com> wrote in message news:B1BA6056-59C9-4BC9-ACFC-866381A46CB3@microsoft.com... > The gist of the reason would not necessarily change, but some changes > would > be made to the wording, such as changes in prices for services and such... > > "Allen Browne" wrote: > >> I'm not sure your boss has thought this through. >> >> If an application is rejected for reason 1 (say, Not Skilled), and later >> reason 1 changes, then any existing records will also change to whatever >> the >> new reason is. All existing records will then be wrong. >> >> Given the difficulty in adding new reasons, and the meaninglessness of >> the >> existing data if the reasons are changed, someone needs to rethink this >> requirement. >> >> -- >> Allen Browne - Microsoft MVP. Perth, Western Australia. >> Tips for Access users - http://allenbrowne.com/tips.html >> Reply to group, rather than allenbrowne at mvps dot org. >> >> "Melvis" <Melvis@discussions.microsoft.com> wrote in message >> news:9040A1F2-4258-4C18-AF39-F55B3461967C@microsoft.com... >> > Thanks for the quick reply! >> > >> > I get what you're saying, but I need to make this so they can maybe add >> > a >> > couple reasons without programming, but can definitely CHANGE the >> > reasons >> > at >> > any time. >> > >> > Also, I can't use an option group because there can be more than one >> > reason >> > for an application getting rejected. >> > >> > ~MATT >> > >> > "Allen Browne" wrote: >> > >> >> If you use a numeric primary key for your Application_rejected_reasons >> >> table, then you could interface the foreign key field with an option >> >> group. >> >> The group lists all the reasons, and the field stores the number of >> >> the >> >> seleted box. >> >> >> >> The major drawback of this interface is that when new reasons are >> >> added >> >> later, you have to redesign the form so the option group contains the >> >> extra >> >> boxes. >> >> >> >> >> >> "Melvis" <Melvis@discussions.microsoft.com> wrote in message >> >> news:D884E7E8-E30E-4659-AA86-72672C466354@microsoft.com... >> >> > Hi, >> >> > >> >> > I am in the process of making a database to track application >> >> > rejections >> >> > for >> >> > a colleague. What happens is people apply for tags, and they need a >> >> > way >> >> > to >> >> > track why the rejections were rejected. They do not track the >> >> > applications >> >> > that go through. >> >> > >> >> > The table structure seems easy to me, with an Aapplication table, a >> >> > Reason_for_rejection table, and an Application_rejected_reasons >> >> > table. >> >> > Normally for this type of table schema, I would use a subform for >> >> > them >> >> > to >> >> > choose the reasons. But what the supervisor is asking for is like a >> >> > paper >> >> > form with check boxes for each reason. She thinks this will be >> >> > faster >> >> > and >> >> > more efficient for her employees when they are entering the >> >> > rejections >> >> > into >> >> > the database. >> >> > >> >> > What I am wondering is if there is any way to accomplish waht she >> >> > wants >> >> > without pulling out all my hair. Could I use an array of check >> >> > boxes? >> >> > If >> >> > so, >> >> > how? This way I could at least loop through the check boxes to see >> >> > which >> >> > ones >> >> > are checked rather than writing code for each one. Also, there is >> >> > the >> >> > possibility that the reasons could change in the future, so I would >> >> > need >> >> > the >> >> > ability to populate the labels from the Reasons table. Man, this >> >> > sounds >> >> > freaky! >> >> > >> >> > Any help you could possibly give me on this would be greatly >> >> > appreciated. >> >> > Thanks... >> >> > ~MATT
- Next message: AbeR: "RE: Control Buttons don't work anymore!"
- Previous message: '69 Camaro: "Re: Flagging if record has been modified"
- In reply to: Melvis: "Re: Users want Check Boxes for entry"
- Next in thread: Sprinks: "RE: Users want Check Boxes for entry"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
