To call a function or sub inside a form from somewhere else, you need to use:

Form_PBarF.MyPBar()

Since MyPBar belongs to a form's module, you need to reference the form's module when you call it.  The form's module's name is Form, underscore, form name.  In the VBA editor, the left side shows all the form modules' names, which all begin with "Form_".

To simply call MyPBar on its own, put it in a public module.  In the VBA editor, the left side under Modules is where you create public modules.

Thank you Kevin, I have tried still it doesn't work

Wouldn't they also need to be Public?

Hi Vicent, the sub MyPBar refers to "PBFront" (an item on the form).  But PBFront is known only to the form PBarF.  Other forms don't know it.  To have other forms call this sub, you need to refer to PBFront in a fully qualified manner: Forms!PBarF!PBFront.  And the PBarF form needs to be opened for that to work.  The code will be more cumbersome, of course.  And this is not really an ideal way to "share" a sub among forms.  What is usually done is write a public sub in a stand-alone module (in the VBA editor, under Modules on the left), and have all forms call it.

Hi Alex, the sub doesn't need to be public, since a form's module is technically a class module.  And private subs inside a class module are still accessible everywhere because the class itself is public.  A form doesn't even have to be opened for you to able to call its private subs by using Form_FormName.PrivateSubName.  That's because the "class" of the form is always present and public even if the form itself isn't opened.

But as I said in the other post, this isn't a great way to call a sub for practical purposes such as in this case.  (But it's an inherent feature for class modules and works great for them.)

PBarF is referenced in the code With Forms!PBarF

Vincent, What actually happens when you run the code? Do you get an Error Message?
I ran an example with your code and the 'Progress Bar' filled as expected.

Kevin -
If you are going to run it from different places wouldn't it be better to move the whole thing out to a GlobalMod?

You could put MyPBar in a Global Module and send the name of the form as a parameter.

Public Sub MyPBar(FormName As String, PercentComplete As Integer)

    With Forms(FormName)
        !PBFront.Visible = True
        !PBFront.Width = !PBBack.Width * (PercentComplete / 100)
        !PBFront = PercentComplete & "%"
    End With
    
End Sub

Then add the name of the form in the call.

MyPBar "PBarF", X
MyPBar "PBarF", 100

Vicent, I concur with Kevin and Scott's idea of using a global module, even though your method should work too.  Maybe in your Command0_Click sub, don't open the form PBarF.  Have it already opened earlier but make it invisible.  Then set it to visible in Command0_Click.  That way you are sure the form is there.  Sometimes when a form is just opened, Access may not know it's there.  That may be the reason your sub isn't run.

Surprised no-one has noticed my deliberate mistake in my post above.

Thank you all, through your contributions i finally made it. Thank you very much.

Kevin Yip: I'm curious why you say "the sub doesn't need to be public." In order for one form to run code on another form, it must be public. It doesn't have to be open, but it cannot be a private sub. Private, by definition, means that only other procedures in that form's module can access it.

Kevin Robertson: You mean declaring PercentComplete as an Integer?

I think we need more Kevins. :)

Nope. No need to send the form name as it's always going to be 'PBarF'. 😁

Hi Richard, if you call a form's procedure as below, the procedure doesn't need to be public:

Form_MyFormName.MyProcName

That's because "Form_MyFormName" is the class module of the form MyFormName. The "class" itself is public, so its procedures can be private and still can be called anywhere.  

If you call the procedure by referencing the form itself, as below, then yes, the procedure needs to be public:

Forms!MyFormName.MyProcName

P.S. The OP seems to have solved his problem, so the info above may be moot.

P.P.S. I suggested the OP to keep the form opened and set its visibility instead. If that was the solution that worked for him, this was the third time this solution has worked for someone in your forum. I tend to avoid having to open and close forms (it's my own evil Access thing) because you often don't know if Access "knows" a form is opened or not, right after you opened it. Having a form opened permanently (if you can help it) solves that.

Kevin, I tried all all suggestions but didn't solve problem, the problem was solved by setting focus on the abort button, the code itself is correct.