Try declaring a global object variable in a module, to represent any of your 20
date labels as needed:
Global WhichOne as Object

Then, in Date1_Click(), add
Set WhichOne = frmBrkDown.LabelDate1
before loading your calendar  form. You must
make a similar change for each of your other Date_Click subs.

Change your calendar form  code to
WhichOne.Caption = cal.value
Unload Me

Thank you so much, that worked perfectly!

One way to do it is to pass a reference  to the field to an Initialise subroutine
in the form  that holds the calendar. So, the click  events in your other form
would be something like:

Private Sub FromDateCalendar_Click()
Call CalendarPopUp.Initialise(FromDate)
End Sub

Private Sub ToDateCalendar_Click()
Call CalendarPopUp.Initialise(ToDate)
End Sub

Then the CalendarPopUp form would have an Initialise subroutine like:

Public Sub Initialise(ByRef Field As Control)
Set mField = Field
With Field
If Is(.Value) Then
Calendar.Value = .Value
Else
Calendar.Value = Date
End If
End With
Show
End Sub

Where it first plugs the date  (if any) from the field into the calendar  control
- or presets the calendar control to "today". Then it shows the form.

I always put a "today" button on my pop-up calendar form. Its event is

Private Sub TodayButton_Click()
Hide
mField.Value = Format(Date, gDF)
End Sub

and the calendar control click is

Private Sub Calendar_Click()
Hide
mField.Value = Format(Calendar.Value, gDF)
End Sub


Notes:

FromDate and ToDate are the text fields for the dates. FromDateCalendar and
ToDateCalendar are buttons associated with them, and it's these buttons that I
click to bring up the calendar popup.

mField is a global private Control variable in the calendar popup form.

gDF is a global date format string - in my case "dd-mmm-yyyy".

There are other ways to get the information back. For instance, in a form that
contains a comment entry text box and returns a string that is not necessarily
going to be put into a form field, I return the information via a ByRef
parameter in the Initialise call:

Public Sub Initialise(ByRef Comment As String)
mComment = Comment
With CommentBox
.Value = mComment
.SetFocus
End With
Show
Comment = mComment
End Sub

In this case, the initialise subroutine holds on the Show call. The OK button
sets the global variable and hides the form, while cancel just hides the for.:

Private Sub OKButton_Click()
mComment = Trim(CommentBox.Value)
Hide
End Sub

Private Sub CancelButton_Click()
Hide
End Sub

If you want to be really flexible, you could make the parameter in the
Initialise subroutine into a ByRef Variant, ask it whether it is pointing at a
field or a cell or a VBA variable and act accordingly.

I tried this solution as it quicker to implement and it worked.
I am a little confused by these references (ByRef), and the mention
of "global private control" variables as I am fairly new to VBA.
I will play with them on the weekend as it will hopefully clarify my
understanding of VBA variables. I always default my calendars (on
initialize) to today or the value (if prev. entered), however I
never thought to include a "today" button on the form. Thanks, that
makes perfect sense. I mentioned it to my test users  and they love
it, and they also want a Yesterday button :)

ByRef is the default anyway. The opposite is ByVal. If you want the subroutine
to change things back in the caller's area, you need ByRef because ByVal takes a
private copy for the subroutine.

Showing ByRef explicitly - even though it is the default - is good programming
practice.

A global private control (yes I agree - very clumsy wording, sorry) was meant to
say, put a

Private mField As Control

at the top of your module, before any subroutines or functions, but after your

Option Explicit

It declares a Control variable of this name that is private to the module, but
available (global) to all the code  inside the module. The lower-case "m" at the
start of the name is a historical way of prefixing such module-wide variables
(it started with object-oriented programming, but is a useful convention).

Hutch's solution is along the same lines as mine - having the Object or Control
variable and getting the OK click  to put the value back there. What I've done
is to encapsulate all of this inside the module, so that you only need a single
line to call  it from wherever you need it.

I discourage the use of global variables, and particularly of having the code
"force feed" information into service modules. I much prefer to supply the
information to the service module inside its own calling sequence, and then let
it do what it needs to do, privately.