Detecting selection change in datasheet form in Access - ms-access

Is there event in Access that detects change of column selection on the same row in datasheet view?

Not in pure datasheet view, but you can create a form and apply datasheet view. And then, all controls bounded to the table got the property TextBox.OnLostFocus. Read more about it:
TextBox.OnLostFocus Property
(Access)
There, you can play and design code to detect when user changes column.

Related

How to handle Access DataSheetView selection change event..?

I have a Form with Default View Split Form enabled, so it will appear like picture below every time it loaded.
I also enable the page header to appear at the top which has a label to store some value (It will store Diff Amount value). What I want to do is, everytime user click on the datasheet view (and make record selection change or cell change) below the form header, I want to update the value of my label on the form header.
It's easy to change the value, but how to handle the datasheet view record selection, or datasheet view cell selection change.
In Excel, this is very easy to do, we can handled it from Worksheet.SelectionChange event, but how to do this in Access...?
Thanks in advance.
Simply use the form OnCurrent event, which fires whenever a new record becomes Current

Using form to edit a selection on subform

I am trying to create a main form with a subform as a datasheet to be used as an asset viewer. I have three buttons that I want to implement in this main form, add/edit/delete entry. The add and edit button will open a new form to add or edit entries in the datasheet. I have the add button working well, however how can I make the edit button edit the row that is selected in the subform (data table)? As it is currently, the edit button will only open with the first entry of that data table. Thanks and hopefully someone out there could help me out.
If you want to open a particular row, you need a button on that row. The way to get that to work is not to use a datasheet but use Format and Default View to create a Continuous Form. Add the required fields and your button to open a new form. Generally, you make that form as short as possible.
When you view the parent form with this subform, it will repeat the rows with data and the button in the row can then be used to open that specific row.

What is the name of the control MS-Access creates when generating a form with 1-M?

If you create a form on a table that has 1-M relationship with another table, MS-Access creates the form containing the fields of the "1" side as text boxe, etc. and for the M-Side, a tabular structure is created.
What is the name of the control representing the tabular structure? (it is some kind of a list but it is not like the list you select from the tool box!). This control does not have a click event. Why? It only has ON ENTER and ON LEAVE events, so how to capture the current row?
It is a form within the main form AKA sub-form. Although it appears to be a grid-view (Access call it datasheet view), it isn't. Therefore it does not have row based events. However, the sub-form has all the events like a normal form would.
There are few limitations in this "dataSheetView", no other controls are visible except text boxes. If you need a button, you must have a textbox with click events. Ideally place the textbox as first/last column so you have your action buttons.
Access also has a "ContinuousFormView" which can be decorated like a gridview with all custom controls. Again, they are forms and do not have row based events. Only control based or form based.
The object next to the question mark is a Subform/Subreport Container Control. As its name implies, it is a container that holds other objects which can be a table, query, form, or report. This control is also available for selection from the 'toolbox'.
Best to give the container control a name different from the object it holds, like ctrDocuments.
What do you mean by 'capture' the current row? A row is not referenced, fields and controls are referenced. Several ways to approach referencing fields and controls (if a form or report) of the dependent object. How depends on where you want to run the code. In a query? In the main form events? In the subform events? For example code in Click event of a button on the main form could be like:
strDoc = Me.ctrDocuments.DocPK

Rearranging the tab order of fields in a sub form in data sheet view

This is an ongoing problem, and I'm hoping there is just a property that I'm missing.
Scenario: I have a form that contains subforms. The Default View property for the subforms is set to Datasheet. (The main form is set to Single Form). Due to changes in what I'm tracking, I want to include another field that wasn't part of the original record source. So, I changed the record source (a query) and added the field to the subform. The new field is added to the end of the Datasheet view by default.
Here is the problem - when I drag the column to a new location on the subform (in Form view or Layout view), it does not stay put. I have made the change using Form view and Layout view, and I've changed the Tab Index property for the field to the proper number.  The new position never stays on the first, or second, sometimes third and fourth try. I have tried saving in Form view, Layout view and Design view, but I always have to drag the column back to the new position and try to save again . This goes on until Access actually saves the change. drag, save, didn't take; drag, save, didn't take; drag...
What I'd like to know is this - how do I rearrange columns on a form that is set to "Datasheet" for the Default View property, and make it stick the first time?
Thanks for any suggestions - I must be missing something....
This is a known "limitation" of datasheets. Some want the columns fit or preset, other sticky, some either as selected by the user.
To control the order of the columns, adjust the ColumnOrder property of the displayed controls.

using ColumnHidden properties within Datasheet objects

I have a MS Access form with a Datasheet subform.
Using code, I change the ColumnHidden property of various of its columns.
But, when I close the form, I'm asked whether to save the table layout of the Datasheet's table.
How can I stop the form from asking the user to same the table layout continually?
Do I have no choice but to change the Datasheet to a regular subform?
If you are always hiding the same columns - create a query that only has the columns you want displayed and use that as the source of your subform.
If you still need some hidden fields (child keys, etc.) you will have to create a regular form. It's not too bad:
just base it on your table,
drag your columns onto the form (formatting, and placement doesn't matter)
set it to datasheet view
edit labels (these become column headings)
change the tab order (this controls the order the columns are displayed)
view the datasheet and hide the columns you want
save the form
add this form as a subform to the main form
I'm not sure there's an easy way to do this because Access saves a lot of properties with forms. If you were not using Datasheet view, you could hide the CLOSE button on the form and replace it with a command button to close the form with this code:
DoCmd.Close acForm, Me.Name, acSaveNo
But since it's a datasheet, you can't do that.
You might try embedding your datasheet as a subform in an unbound parent form, but I don't know if using the code above behind a command button on the parent form will or will not save the column widths to the embedded subform.
One solution would be to re-initialize the column widths in the OnLoad event of your datasheet. You could then open the form with acHidden, and in the OnLoad event, set the column widths to their correct values (you'll want to multiply inches times 1440 to get the twips value to assign to the column width properties), and at the end of the OnLoad, set Me.Hidden to False.
But that is, indeed, something of a pain in the butt.
I'm afraid it's one of the downsides of using datasheets, since there's no way to define a close command button that won't save end-user UI data.