The implication of a subform regardless of whether it is in single, continuous, or data sheet view is that the subform has multiple records related to the record visible on the main form and in which your code is running. The point is that when you put a value into a subform control from code in the main form, you must know ABSOLUTELY which record the subform is positioned on otherwise you will update the wrong record. All forms have a CURRENT record. If the subform is in single view, the record you see is the one that is current and so that is the one that would be updated. However, when the subform is in continuous or ds view, the current record may not actually be even visible in the subform since you can scroll without changing the record pointer. If your subform shows the record Selector, you have a visual clue since the RecordSelector will show a right facing triangle on the row that Access considers current. If that record is dirty, the RecordSelector will show a pencil and if that record is locked by a different process, the RecordSelector will be a circle with a line through it.
To summarize, you probably don't want to be running code in the main form to update the current record of the subform. It is just too easy to update the wrong record.
PS. There is no such thing as a cell in a relational database. That is strictly a spreadsheet concept. A cell is the intersection of a row and a column and has a specific address since the spreadsheet is a two dimensional "flat" object. In a database application you would use a query to select the row based on some unique criteria and then refer to the column name. This is the essence of the difference in approach between coding in a spreadsheet and coding in VBA. In VBA, your references are always relative. Ie. I refer to Me.CustomerID in the code but the assumption is that there is only a single row current at any point in time and that is the row I am operating on.