I've struggling with this problem on my own, then with some help, then search about it; but I haven't had any luck. So I decided to ask
I have two forms in access 2007.
1. frmNavigation
2. frmOrderList
The form frmOrderList is embedded in the form frmNavigation. The form frmOrderList is built based on the queris which have criterias located on the form frmOrderList.
When the criterias are change the macro (after update) start run and trying to refresh the the frmOrderList.
I tried to serveral codes but it dosen't wortk for me.
Forms![frmNavigation]![NavigationSubform].Form![frmOrderList].Requery
Forms![frmNavigation].Form![frmOrderList].Requery
Forms![frmNavigation]![frmOrderList].Form.Requery
Forms![frmOrderList].Requery ' Works fine for the single form
Still the same error
Microsoft access can't find the field 'frmOredrList' referred to in your expression
It is good cheatsheet in russian - http://www.sql.ru/faq/faq_topic.aspx?fid=156 I'd like to translate some points:
Basic syntax is this:
Forms![Form1].Controls![Field1].Value
Mention, that "." and "!" goes one by one, switches.
It is possible to do like this:
Forms![Form1]![Field1]
But there should not be same named different collections' objects.
Addressing subform
Correct link to the property of subform or subreport needs to address full form identifire, using Form property of control:
Forms![Form1].Controls![Form2].Form.Controls![Field1].Value
In this case:
Forms![Form1].Controls![Form2] is a link to a control, where subform is displayed.
Forms![Form1].Controls![Form2].Form - is a link to subform. Addressing Form property is required for MS Access 97, and optional for next versions.
As described, addressing to 3rd and more level subforms is constructed:
.Controls![Form2].Form (or .Controls("Form2").Form )
For addressing to an object in current context
It is recommended to use following syntax:
Me.Controls![Field1].Value
NB: name of control, that contains form can be different from form's name. It can be checked through studying .Name property of a control.
So using these instructions, your code should be following (see 2nd recommendation):
Forms![Form1].Controls![Form2].Form.Controls![Field1].Value
in this case
Forms![frmNavigation].Controls![NavigationSubform].Form.Controls![frmOrderList].Form.Requery
And this will work, only if only names of your controls are same as Form's names, otherwise you should correct names of control names, that are in squre brackets.
Related
I am trying to filter a subform based off a value selected in a listbox.
My list box is called cboCurrentListName and this is populated using a select query
The subform is called Form_subform_ListContents
For the change event for the list box I have the following code, however no filters are applied when its executed.
Me.Form_subform_ListContents.Form.Filter = "[ListName]=" & Me.cboCurrentListName.Value
Me.Form_subform_ListContents.Form.Filter = True
I have also tried using Master/Child links to execute this using the following steps, but this caused an input box to pop up when the fom loaded:
first I set the 'link child fields' option in the properties of the subform to 'ListName' (this is the field name that populates the list box and is present in the subform
then I set the 'link master fields' option in the properties of the subform to 'cboCurrentListName' (the listbox name)
then in the listbox properties I set the control source to 'cboCurrentListName'
The above steps cased an input box to pop up on opening the form (the value typed in here does filter the subform). However I don't want an input box in order to do this, I want to use the listbox.
I have googled this and fried different methods but have had no luck. I am pretty new to access and of the control source sections aren't a strong point of mine, which is why I tried to use the VBA on the event change instead
Any help would be appricaited, I tried a few things and had no luck.
EDIT: When trying the master/hild option I also get an error 'Can'y build a link between unbound forms' if I click the 3 dots in the poperties. SO for the above steps I had to manually type in the otpions.
I have an unbound textbox to accept the delete older than: number of days. It is in the report header. I set it to 30 days but I want the user to be able to change it. I was banging my head trying to figure out why entering 40 was not being accepted and it reverted back to 30 every time. I finally decided on using the lost_focus event to set .value to .text. That worked.
Further research showed that when the textbox get's focus text and value are both the same, 30 in my case. Changing the number in the text box to 40 shows the values of text at 40 and value at 30. Unless I specifically set Value to the value of text Access changes text to the value of value. This is different behavior than other places in Access such as forms.
Can anyone tell me why this might be? I can't find any setting that might do this. Is it because it's in a report header? what is the difference between this and every other text box I've ever used?
From a "best practices" viewpoint, Access Reports are not intended to be used interactively despite the ability to manipulate some unbound controls. Although workarounds can be implemented that function sufficiently well, such solutions are often incomplete and buggy and function differently depending on the active view: Report View vs. Print Preview. Appropriate design patterns include using Access Forms for specifying report options which then open the Report in a static configuration.
This may not satisfy the question "Why?" if seeking a deeper answer as to why Microsoft implemented inconsistent binding behavior in Access, or why they allowed interactive controls in reports at all if they don't behave the same way as in forms. But Access has plenty of other quirky behaviors that have no known/published explanation.
Regarding the priority of the Value property updating the Text property (and not vice versa): Value is the key field because it contains the actual data for the control (bound or unbound). Although it is natural to have a single control for both display and input (uh, that's how almost all controls work), the processes of displaying data and parsing user input are two distinct functions. The visual representation returned by the Text property can be manipulated using the various formatting properties, and technically could display an incomplete representation of the underlying Value data. If there are any conflicts between the stored Value property and the Text property, it is natural that the existing Value property has precedent.
My guess is that the automatic binding behavior was "relaxed" for reports to allow more flexible custom reporting output. First consider an Access Form in Datasheet view: An unbound Form control shows the same value for all records. Even if the control is edited while on a particular row, the updated value is displayed for all rows. The same control object is essentially repainted for each row and there is no concept of individual instances of the control that can hold different values. Bound controls have built-in code that repaint the control with data from the particular row, but there are still not multiple instances each "holding" the individual values. The visual output differs from an intuitive object-oriented paradigm where our minds what to assign each visual row its own in-memory instance of the controls--it just doesn't work like that in Access.
Unlike the Form behavior just described, the Report's Print Preview (and actual printed output) allows unbound controls to display different data per row using the Detail_Format() event. Within the Detail_Format() event, one can set the Value property of a control at which time the Text property is automatically updated according to various formatting properties. This update Text is then output for the current row. Perhaps (just guessing) that this behavior would not function properly if the Text property updated the value property. I suspect it would cause recursive events during report generation. Because reports are not meant to be interactive, relevant text-input parsing code was "disconnected" so that it doesn't behave like on a form.
All that explanation doesn't make Access any less frustrating nor remove its limitations, but at least learn to adapt and design things in the "Access-esque" way rather than fighting it.
your best bet is to design a form with the unbound combo boxes and have your data displayed in a subreport. I like to design my reports so that when values are updated the query for the recordsource of the report is generated doing this requires 2 queries to exist, one with all data possible and a filtered one as subreport recordsource. This will control the data for printing and also allow users to close or navigate away from the report and return to the data later.
Private Sub ComboBox1_AfterUpdate()
Dim Query1 as Object
Dim Temp_Name as Variant
Temp_Name = SubReport.SourceObject
SubReport.SourceObject = Empty
Set Query1 = Me.Form.Application.DBEngine.Workspaces(0).Databases(0).QueryDefs ("SubReport_Query")
Query1.SQL = "Select * Unfiltered_Query WHERE Field1 <= " ComboBox1 & ";"
SubReport.SourceObject = Temp_Name
End Sub
I have an Access 2010 database, with document information in a primary table.
I have forms that display specific document type information (credit card statements, invoices, etc.) from the table.
I have a main form, with separate subforms, each subform representing a specific document type.
I want to be able to filter from the main form, so that each document type subform displays only the documents that fall within a user-specified dollar amount range.
I'm thinking, that if I can get the sub forms to open after the main form (the reverse of this is the default order), I can set the filter in the open event of each sub form, from the main form, and get my desired results.
What I have found to cause the sub forms to open after the main form, is to remove the SourceObject from the Data tab of the Properties sheet of the sub form; and then assign the sub form name to the SourceObject property in vba in the open event of the main form.
The example I have is Me.MySubForm.Form.SourceObject = "frmSubFormName", where everything on the left is verbatim, and frmSubFormName is the name of my subform.
This isn't getting past the compiler - it's complaining about MySubForm, and unfortunately the post/blog with the example doesn't indicate what "MySubForm" is, in assigning the SourceObject property to my sub form name.
Any thoughts on this approach to the filtering?
Can anyone shed light on the syntax of setting the SourceObject; or perhaps provide another way of having the sub forms load after the main form?
Thanks in advance.
Remove the Form class object reference. Recommend naming the subform container control different from the object it holds, such as ctrSomething
Me.ctrSomething.SourceObject = "frmSubFormName"
I have a database that was create in Access 2010. We recently updated our systems to Access 2013. In Access 2010 I have no errors accessing a form object with
Form_frmName.txtFieldName.Value
However, when using Access 2013 I get a runtime 2424 error stating that "The expression you entered has a field, control, or property name that Microsoft Access can't find. I am accessing from a module.
The module sets these fields visible using
With Form_frmName
.txtFieldName.Visible = True
End With
before attempting to access them.
Has there been any changes in the way form objects are accessed between 2010 and 2013? Is this an issue others have faced?
In Response to #WayneGDunn's questions below
QUOTE:
I need to know exactly what and how you are using this.
1. You have a bound textbox named 'txtFieldName' on a form. As #brad asked, is there a subform, and if so, is this field on the subform?
2. You said the code is in a module, but is the code in the form where the field is defined?
3. Please explain where/what form 'frmQAtab' is (you said your form name was 'frmName', so what is the other, how related?)
4. Is the code in an event? Can you share the entire subroutine?
5. Have you tried creating a dummy query and using the builder to reference the field?
RESPONSE:
1. I have a form (frmMain) with multiple tabbed pages. frmName is one of those tabs, containing the bound field txtFieldName.
2. The module is run from the form the field is in.
3. My apologies frmQAtab is frmName, I just neglected to make that generic in my copy-paste.
4. The event is a button click. The button click runs a sub from a module. That sub makes visible the fields, runs a query based on user input (two date fields), populates the bound fields with the returned record set, then attempts to access them for processing (another query is run to process a complete other set of fields). To post the entire subroutine would be a bit more than I would ask you to chew on. This is legacy code I'm trying to fix, and it's rather large.
5. I have not tried a dummy query. Access is not my field (I'm mainly a C#, scripting, guy.) Is there some suggestions in this area you could give?
One of the following references to your fields should work. I created a form (named 'frmMain'), then created a Tab Control with two tabs. On the first tab, I inserted another form (named 'frm3197'). I also created a text box on the tab control named 'txtFieldName' AND in form 'frm3197'. From a button click on 'frmMain', the following will reference each of those fields.
Private Sub cmdButton1_Click()
Forms![frmMain]![txtFieldName] = Now()
Forms![frmMain]![frm3197].Form![txtFieldName] = Now()
End Sub
Code in Form onLoad:
country_combo.RowSourceType = "Value List"
Code in a reset function:
Dim lListIndex As Long
With Me.country_combo
For lListIndex = .ListCount - 1 To 0 Step -1
.RemoveItem (lListIndex)
Next lListIndex<br/>
End With
Code to populate country combo:
*For n = 1 To numCountries*
*countryCombo.AddItem (countryRS.Fields("countryName"))*
*countryRS.MoveNext*
*Next n*
I'm having a problem that occurs AFTER the code to populate the country combobox runs. The values are there as I can run Debug.Print(countryCombo.Value) and it prints out the name of the selected country, but I can't see the values in the combobox at all. They're invisible, and as far as I know there is no visiblity property for specific items, unless I'm completely mistaken.
comboBoxError.png http://img110.imageshack.us/my.php?image=comboboxerror.png
I think you should probably use Access's GUI tools to do what you're looking for. In design mode, click on the field you are trying to populate, then click the "lookup" tab. You can then specify a table to populate the field with and your forms should automaticly update as well.
I've also seen what you describe here - as far as I can tell, it's a bug within Access (I was using 2007) that only occurs when you programatically mess with the contents of a combo box. It does not happen every time. The issue corrects itself if you highlight the text that is in the combo box.
I am experiencing a similar issue with Access 2003. Based on the selection of one combo box, the row source of a listbox is set to an SQL string Basically a SELECT DISTINCT [MyField_Selected] FROM MyTable. For some fields the values are visible in the list box and others it is not. The values are there however as I can access them via code. To make it more interesting it works fine in Access 2007.
Just found the resolution on another forum. Check the format property of the field(s) in question on the table. In my case, when Access 2007 created the table, it put an # format in there. I removed that and all works great!