I have kind of a two part issue (they may be related, I'm not sure). I've never worked with Microsoft Access 2013 before (or any Access version really), and using a "for dummies" type book I'm trying to build a front end interface to link to a SQL database. To do this I'm using the navigation form, regular forms, and then the tables themselves in subforms within that. The forms that hold the subforms are also where I'm placing my buttons. My intentions with these buttons are to use them to filter the table to specific records. I have one doing that successfully (via the main navigation form) but then I have the problem of all the other buttons not working at all, or calling the same text box that that one calls.
This is the code to the working button:
I added the stop Macros actions in an effort to keep the same box from popping up when I pressed another button that houses the macro with a show all records action. Because of issues I also added a stop macro action before the show all records actions on this button (I would do a picture but I'm only allowed two links per the site rules).
This one I found when I added the stop action to the macro before the show all action it stopped the box from popping up, but it also doesn't work to show me all the records. Without the stop action, it acts exactly like the Search Mill ID Button.
The second part of my issues is that my third button currently does show me all records despite it being me trying to use it as a search feature to have a box pop up and the user enter in all or part of a company name to filter the records.
That code looks like this:
I am pretty sure there are a few things wrong with the code on this button in general, but have been having trouble finding any resources of people who are having the same problems as me (or perhaps the issue is so basic most users just automatically know what to do). I've been relying on youtube videos and an access for dummies book to try to build this stuff, but realize that I'm a little beyond my skills; however, I still have to get it done for my job so I'm persevering through.
I appreciate any tips/suggestions to help!
One approach would be to set the OnClick event of your button to use VBA code (Event Procedure), and get the Mill_Id from an Input Box. Macros are much more limiting than VBA and you cannot reasonably use error handling. You can then set the RecordSource property of the form when the button is clicked. The buttons OnClick event would be something like this:
Private Sub Command0_Click()
s = InputBox("What is the Mill ID?", "Mill ID", "")
Me.RecordSource = "SELECT * FROM MyTableWithMillData WHERE Mill_ID = '" & s & "'"
End Sub
Or if the button is on a parent form, and you're trying to change the subform, use this:
Private Sub Command0_Click()
s = InputBox("What is the Mill ID?", "Mill ID", "")
Me!subformcontrolname.Form.RecordSource = "SELECT * FROM MyTableWithMillData WHERE Mill_ID = '" & s & "'"
End Sub
Related
I have a form whose main purpose is to contain a datasheet subform (the form provides a common visual theme across the pages as well as navigation buttons and sometimes selection criteria for the subform).
One of my subforms has a check box.
The user behavior will be to:
Open this form
Filter the datasheet according to some specification
Do something off-line involving, e.g., the ten visible line items
Check the field (yes/no field) on those ten line items to indicate that it's been done
What I'd like is for the user to be able to check one box that then checks all the visible boxes.
The challenge is that it must only be the visible ones, i.e. dependent on what filters are in place.
I tried to create a checkbox in the main form labeled "Check All" which runs code something like:
me.sfrmReport.Control.reported.value = me.chkCheckAll.value
But unfortunately, this only checked the active row, not all of them. I know I could run a query on the underlying table, but it would need to replicate the user filters.
In fact, what might be even cooler would be a "Check highlighted" box that checks the highlighted rows only.
But I think "Check all" would be better.
I tried to find this, but my searching skills failed me. I'd have thought this was something somewhat common, but perhaps I'm thinking about this incorrectly. I do note that there's a sum function which automatically sums just the filtered/visible rows in a datasheet, so the notion of interacting with just the visible rows is at least somewhat standard.
Well, the check all box certainly should not be on a "row". So one would assume that say beside the combo box, you place a check all box. (can't imagine that the button or code would be place on the row(s)).
So, say beside the combo box in your screen shot, you have a button called check all.
The code behind that button would/could be:
dim rst as dao.RecordSet
set rst = me.MySubForm.Form.RecordSetClone
rst.movefirst
do while rst.EOF = false
rst.edit
rst!ResultReported = true
rst.update
rst.moveNext
loop
me.MySubForm.Form.Refresh
So above will operate directly against the sub forms data source (current filtered recordset).
I "think" from your screen shot, the top part of the form (with combo) is the main form, and the sub form you have displayed is the sub form.
So, of course you will have to replace the name of the controls I used above, and also the field name for the check box.
So the format to get that recordset is:
me.MySubFormControlName.Form.RecordSetClone
and to fire off a refresh of the sub form after the code runs is of course.
me.MySubFormControlName.Form.Refresh
Note that intel-sense should work and help you. if the code does not compile, then don't try and run it until it compiles.
I have a form in Microsoft Access 2013 that uses the following formula in a calculated text box to summarize outcomes:
=DCount("[Log]![Outcome]","[Log]","[Log]![Outcome] ='Good' AND [Log]![User]= [Forms]![User Summary]![UserName]")
In effect, the formula looks in the "Log" Table and gives me the total count where the "Outcome" is "Good" for the User that matches the current user selected in the "User Summary" form.
The formula works great when I access the "User Summary" form directly. However, if I embed the "User Summary" form into a navigation form, the formula returns an error. The error stops and normal behavior resumes if I open the original "User Summary" form in the background.
Any ideas how to make this work in a Navigation form without having to open the User Summary form in the background? I eventually will be handing the interface to multiple people, and I don't want them to have to open various forms in the background just to get the navigation to work.
Try this:
=DCount("[Log]![Outcome]","[Log]","[Log]![Outcome] ='Good' AND [Log]![User]='" & Me.MySubformName!UserName & "'")
A bit simplified:
=DCount("Outcome","Log","Outcome='Good' AND User='" & Me.MySubformName!UserName & "'")
Where MySubformName is not the name of the form but the name of the control in the main form that contains the subform.
Depending on where your control is you may need to do something like Forms.MyMainForm.MySubForm!UserName. Basically when your form is embedded in another form you have to call it by starting from the main form and work downwards.
The inbuilt Navigation form uses a subform to display your forms.
Unfortunately they also unload the form from the subform container when it isn't selected, so that form isn't actually present in the background. Whilst this is a clever technique to improve perceived performance, it isn't without it's issues if you don't know it's doing it.
This is why most developers make their own Navigation forms.
EDIT: For clarification, I'm talking in the below post about tabbed document browsing, not a Tab Control. However, if you're looking for roughly the same problem but regarding a Tab Control, Gord Thompson's answer is correct. Two answers for the price of one!
I've got an Access 2007 database that uses tabbed documents. I need to run some VBA code every time a user selects the form called "Reports", either via opening it or clicking on its tab if it's already open.
I could achieve much the same thing by closing it each time it's used and running the code on an OnLoad event, but ideally I'd like to keep it open so that users can keep the settings of the various drop down boxes, radio boxes etc that they've already set on "Reports".
I was hoping for an event that could run code on tab reselection, but neither of my guesses (OnCurrent and GotFocus) seem to work (OnCurrent works only when the form is opened, like OnLoad would).
Any ideas greatly appreciated - can't find what I'm looking for on Google, though I suspect that's because I don't know exactly what I'm looking for.
The .Value property of a TabControl returns the index (zero-based) of the current page. So, if I have a TabControl named TabCtl14 that contains two pages, FirstPage and SecondPage, then the code...
Private Sub TabCtl14_Click()
If Me.TabCtl14.Value = 1 Then
MsgBox "SecondPage was clicked."
End If
End Sub
...displays the MsgBox whenever I click the "SecondPage" tab in the TabControl.
Have found the answer I was looking for. It's the OnActivate event.
I have a form (FORM-A) that requires the user to select a vehicle.
The user should click on a button on FORM-A that say's select vehicle.
A selection form (FORM-B) should open where the user can select a vehicle.
The selected value should be communicated back to FORM-A.
How would you accomplish this in MS Access 2010?
FORM-B is a continuous form that contains a picture of the vehicle and some other information.
From what I understand from your question, you want formB to open a kind of pop-up. When the pop-up is closed, its result is put somehere in the calling form.
Solution proposal:
a) open FormB using syntax docmd.openform "formB", windowmode:=acDialog.
This will prevent execution of the next lines until formB is closed or hidden.
b) in the OK button of FormB, just hide the form, do not close it.
c) when code resumes in formA, you can now
check if formB is still open. If not, it's been cancelled
read the value in hidden formB (still open), then close formB
Otherwise, you could also have formB to update a control in formA before closing. But I don't like that approach because then formB is not reusable, and it creates an unnecessary dependency between formB and formA.
I am not sure why you would need a separate form for this - just have the first textbox be a listing of all the records of vehicles in the database, where you would select one, and the rest of the vehicle information is auto-populated from the vehicle table, but not copied into your parent table. Of course, I am not sure of your table structure either, so there might be a reason for this method that isn't apparent to me.
The benefits of the method above is that if you add more vehicles, your selection box is automatically updated - and you keep the forms you have to load to a minimum (always a good performance move)
You can reference the forms in this manner forms!formName!controlName.
Once you see how this works you will be able to fool with it to get it working with your existing setup. Let’s use 3 controls a text box on Form-A, an image on Form-B and a text box on Form-B. The text box on Form-A will be named txtVehicle, the image on Form-B will be named imgVehicle and the text box on Form-B will be named txtVehicleName.
You can set the name of a control within properties. When you click on imgVehicle it will put the value from txtVehicleName into txtVehicle.
You will have to do a little coding - it's easy though if you have not done it before. Under properties for the image you will see events. If you click on the "On Click" event you will get a drop down list. One of the choices will be [Event Procedure] - choose that. A little button with 3 dots on it will also show up at the end of the row. Click it and you should be taken to a code window with some code like this in it.
Private Sub imgVehicle_Click()
End Sub
Here is where you put your code. Something like this should work. This is it in its most simplistic form.
Private Sub imgVehicle_Click()
Forms!Form-A!txtVehicle=forms!Form-B!txtVehicleName
End Sub
Now although that will work, there are a few things that we should be doing in this method that we are not. We should reference Form-B directly since we are in it, we should verify that Form-A is in fact open.
Private Sub imgVehicle_Click()
If currentproject.allforms(“Form-A”).isloaded then
Forms!Form-A!txtVehicle=me!txtVehicleName
End if
End Sub
Hope that helps
You can create an instance of formB within formA and control it. Below is the VBA code for formA. When clicking on a button on formA, you create a new instance of formB and give it focus. At the same time, you can set properties for its controls. You can use this approach to set the right picture in your control on form B. Hope this helps.
Example:
Option Compare Database
Dim fB As Form_FormB
Private Sub btnA_Click()
Set fB = New Form_FormB
fB.SetFocus
fB.tbxB.Text = "Some text sent from A to B!"
End Sub
If you want both forms to be visible all the time, I suggest using a subform with the list of all the vehicles or just details for the one that the user selected.
I have a form in MS Access which has an image. The image has an Click event which opens a modal form. The modal form has an OK and Cancel button. When you click the OK button, an event is supposed to fire which tells the main form which button was clicked. (This is to simulate the DialogResult functionality in C#). However, the code in the event handler never runs.
The modal form has the following in the general declarations:
Public Event OnDialogBoxClose(NewRecordID As Long, DialogResult As DialogResults)
and the following code where the OK button is clicked:
RaiseEvent OnDialogBoxClose(NewHardwareBaseItemID, dlgresBtnOKClicked)
The main form has the following in the general declarations:
Dim WithEvents RespondQuickAddClose As Form_qckfrmHardwareBaseItemCreate
and the following event handler:
Private Sub RespondQuickAddClose_OnDialogBoxClose(NewRecordID As Long, DialogResult As DialogResults)
MsgBox "Responding to closing of the dialog box" 'Never happens
Me.Requery
End Sub
Can someone explain why the event handler is never called?
Thanks!
Background:
The purpose of all this is to allow a modal dialog box to add an entry, then return the ID of the entry back to the main form to set the value of controls. For instance, imagine you are filling out an insurance form, and you need to select a brand of car this is not there. You click on an icon which pops up with the modal dialog box to allow you to add the car brand. Then when you click OK, it takes you back to the insurance form and selects the brand of car you just created.
This follows an example I found here:
http://database.itags.org/ms-access-database/80292/
You're making your life way too complicated by applying concepts from a different development environment to Access VBA. While VBA does support WithEvents/RaiseEvent, there's no reason to get that complicated here.
The usual way to work with dialogs in Access is that instead of closing them, you hide them. This allows the code after the form was open to run while leaving the values in the form available for use in that code.
Sample code in the OnOpen event of a report that opens a form for collecting values to filter the report:
Private Sub Report_Open(Cancel As Integer)
DoCmd.OpenForm "dlgDateRange", , , , , acDialog, "ThisYear"
If IsLoaded("dlgDateRange") Then
With Forms!dlgDateRange
If .Tag = "Cancel" Then
Cancel = True
Else
Me.Filter = "[InvoiceDate] Between #" & !txtStart & "# AND #" & !txtEnd & "#"
Me.FilterOn = True
Me!lblDateRange.Caption = StrConv(Trim(("from " + varZLStoNull(Format(!txtStart, "mm/dd/yyyy"))) _
& (" to " + varZLStoNull(Format(!txtEnd, "mm/dd/yyyy")))), vbProperCase)
End If
End With
DoCmd.Close acForm, "dlgDateRange"
End If
End Sub
The dialog form has two command buttons, CONTINUE>> and CANCEL. The CANCEL button sets the form's tag to "Cancel" and sets the form's .Visible property to False. The CONTINUE>> button does nothing but set the form's .Visible property to False. Clicking either of those buttons allows the code to continue on the line after the form is open with the acDialog switch.
My philosophy is to make the dialogs as stupid as possible. The calling code has to know what it's looking for in the forms (i.e., you need to know the names of the controls you're reading data out of), but that could be gotten around by adding customer properties to the form. But then you have to know the property names, so you've just moved the ball.
I have also implemented this kind of thing by wrapping the dailog form in a class module, and then the calling context simply initializes an instance of the class and then pulls the values out of it at the appropriate time. But that's actually more complicated that the approach above.
well I don't agree to
"While VBA does support WithEvents/RaiseEvent, there's no reason to
get that complicated here."
I have worked on various VB6 and VBA project. Recently I coded VBA in excel where I raised an event from winform. Few things to be considered when doing so.
If you are calling non-modal winform in VBA with
withevents/raiseevent. It should work normally as expected. No major
workaround is needed
If you are calling modal winform in VBA. Withevents/raiseevents may
not function as per requirement. A quick workaround is to transfer data using public variables declared in the module file.
You will need to use the workaround and I believe it will work absolutely fine.