Excel 2002, SP3
Windows XP Pro, SP3


I'm getting mixed results. When a form is created within VBA, what type of
form is that exactly? I have been under the impressing that it's a
UserForm.

I have the following code in one of my main form's code module:


------START OF CODE------


Private Sub pcdRecordJobIssue(ByVal l_StatusCode As g_enmWorkOrderStatus)
Dim l_bolCheck As Boolean, l_strMessage As String, l_frmIssue As
MSForms.UserForm
If m_objCurrentWorkOrder Is Nothing Then
Exit Sub
Else
Select Case m_objCurrentWorkOrder.prp_ro_enmStatus
Case g_enmWorkOrderStatus.lngWorkOrderSetupEnum,
g_enmWorkOrderStatus.lngWorkOrderSetupIdleEnum,
g_enmWorkOrderStatus.lngWorkOrderSetupProblemEnum
Select Case l_StatusCode
Case g_enmWorkOrderStatus.lngWorkOrderSetupIdleEnum,
g_enmWorkOrderStatus.lngWorkOrderRunIdleEnum
l_StatusCode =
g_enmWorkOrderStatus.lngWorkOrderSetupIdleEnum
Case g_enmWorkOrderStatus.lngWorkOrderSetupProblemEnum,
g_enmWorkOrderStatus.lngWorkOrderRunProblemEnum
l_StatusCode =
g_enmWorkOrderStatus.lngWorkOrderSetupProblemEnum
End Select
Case g_enmWorkOrderStatus.lngWorkOrderRunEnum,
g_enmWorkOrderStatus.lngWorkOrderRunIdleEnum,
g_enmWorkOrderStatus.lngWorkOrderRunProblemEnum
Select Case l_StatusCode
Case g_enmWorkOrderStatus.lngWorkOrderSetupIdleEnum,
g_enmWorkOrderStatus.lngWorkOrderRunIdleEnum
l_StatusCode =
g_enmWorkOrderStatus.lngWorkOrderRunIdleEnum
Case g_enmWorkOrderStatus.lngWorkOrderSetupProblemEnum,
g_enmWorkOrderStatus.lngWorkOrderRunProblemEnum
l_StatusCode =
g_enmWorkOrderStatus.lngWorkOrderRunProblemEnum
End Select
Case Else
MsgBox "Must put the work order either into ""Setup"" or
""Run"".", 48, "Mode Change Error"
Exit Sub
End Select
End If
Select Case l_StatusCode
Case g_enmWorkOrderStatus.lngWorkOrderSetupIdleEnum,
g_enmWorkOrderStatus.lngWorkOrderRunIdleEnum
l_strMessage = "In order to put the job into idle, must provide
a reason for it. Did you want to put the job into idle?"
Set l_frmIssue = frmIdleOptions
Case g_enmWorkOrderStatus.lngWorkOrderSetupProblemEnum,
g_enmWorkOrderStatus.lngWorkOrderRunProblemEnum
l_strMessage = "In order to put the job into problem, must
provide a reason for it. Did you want to put the job into problem?"
Set l_frmIssue = frmProblemOptions
End Select
g_strCurrentReasonCode = ""
l_bolCheck = True
Do Until l_bolCheck = False Or g_strCurrentReasonCode < ""
l_frmIssue.Show vbModeless
Do Until l_frmIssue.Visible = False
DoEvents
Loop
If g_strCurrentReasonCode = "" Then
If MsgBox(l_strMessage, vbCritical + vbYesNo, "Reporting Error")
= vbNo Then
l_bolCheck = False
End If
Else
m_objCurrentWorkOrder.fncRecordStatusReason l_StatusCode,
g_strCurrentReasonCode
pcdUpdateForm
End If
Loop
End Sub


------END OF CODE------


The problem I'm running into, the object variable of "frmProblemOptions" has
the "Show" method, but the variable of "l_frmIssue" does not have the "Show"
method.


Within the declaration statement, I have attempted to have either one of the
2 portions in it

l_frmIssue As MSForms.UserForm

l_frmIssue As UserForm


As a matter of preference and to help avoid ambiguities, I normally like to
prequalify my variables like in the first line of the 2 lines above. Large
part is cause I have been burned on ambiguity issues in the past across
different code sections. That's also why you may notice how I name my
variables so as once again to avoid such issues while also allowing the code
to be readable, more or less self documenting. The above is only part of a
full declaration line as there are other variables within that same
declaration line with a declaration keyword at the front of it (In this
case, Dim given it's within a method and variables within methods are only
of local scope not visible to any other part of the code outside of the
method).

The above code is used to modulate the coding so as if something needs to be
adjusted, it only need to be adjusted in one place rather than in multiple
places. This not only help for debugging purposes, but also for other
purposes such as less memory taken to record as not having to copy and paste
the same code to multiple different places.

The only thing I can possible think of is if there is some sort of a version
issue with MSForms class or VBA codes.


--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000