You don’t need nor want to use global vars to pass around a few values. This is a bad idea in .net, c++, FoxPro or ANY system you use to deal with data.
And how you use global vars in vb.net, and VBA is the SAME.
The first and most important question is that form used to enter those activities. It not clear if you have a normalized database, and they wind up entering 10 rows of data (or 5, or 15), and this form allows entry of such activates.
Access will do all the dirty work for you, because such forms are data bound, and no code to read/write/edit the data is required.
At this point, the user has then entered the 10 activates (but as noted, your design should allow 3, 5 or 50 activates).
Once they entered this data then it not clear as to why they did not enter the rating.
However, I would assume they now launch some form that allows the rating to be entered. It not clear why the original form simple does not have that extra text box bound to the column rating.
So, the user would launch this form when they do have the rating information, and simply find the correct record, and then simple type in the rating or perhaps select it from a nice combo box you built.
So far, we not had to write any code, and we simply created a form bound to the table. However, as noted, since there are going to be 3, or 30 activities, then I assume your design is not hard coded to only 10 activities.
And I would assume like some invoice form, you have information about the “event” in place of an invoice information (customer etc.), and then a sub form that allows you to enter one or many lines of invoice details, or in this case all the possible events and activities for this one event.
So far, based on your explain, then zero code is required here.
There is no need to pass the 10 events to some other form, but simply launch the same form used to enter the event, and the 10 activities, and now simple edit (enter) the result or status of the activities.
Nothing in your explain so are suggests that global vars are required, and in fact so far what you explain can be done with Access forms and no code at all.
What you first need to do is build a correct set of tables to work with this data before you build any forms, or write one line of code. With the correct table design, the rest of your requirements become trivial and as noted so far looks to not require any code if you use the great features of Access to build such forms.