1) a module with the declare
"Public mForm As frmMain"

2) a class module with
Public WithEvents eButton As CommandButton

Private Sub Class_Initialize()

     Set mForm = New frmMain
     Load mForm
        mForm.Show

     Set eButton = mForm.btnNotification

End Sub

Private Sub eBtnNotification_Click()
        Call Beep(500, 100)
        RaiseEvent Notification
End Sub

3) A form "frmMain" with a command button.

When I click on the button on the mForm, an event is raised in both the
ActiveX-Exe and the Client.
However if I set a timer to call "me.btnNofication.Value=True", the
event is raised ONLY in the ActiveX-exe.

Can anybody help?

Any problem you may be having isn't caused by the code below, even though I
had to double-check to believe you were able to expose a VB command button
to "the world". That doesn't seem right to me, for some reason.

All of those Publics scare the heck out of me. Do they need to be Public?
You do know that, since your form's declared Public in a module, all
instances of the class will be sharing the same global and stomping on each
others values, right?... that means, if the class init method creates an
instance of the form and your app creates more than one instance of the
class, only the last instance created will be holding a reference to the
object variable that'll be raising events. Any other loaded forms will be
firing events into "thin air"

You say the client app's not getting the events when using a timer... place
some debug.prints in there and add a temporary property you can set to let
you know who VB "thinks" the client is.... basically, there's not enough
info in the post to give any "here, do this" type answers... no "client
side" code at all.

OP,

Besides the items Ken mentioned also consider that an ActiveX Exe is running
on a different thread. When you 'connect' to an ActiveX Exe through
automation that 'sub' becomes part of your client's 'space' via COM, but it
is not complete access to the Exec. ie, the Exec could very well be doing
processing that doesn't have a thing to do with any clients that might be
connected.

Without more information it is not possible to provide any hints.

-ralph

Not sure what I mean?
Okay, let's assume your house is burning. You call 911, and the fire
brigade comes.
Now let's assume your house is NOT burning, but you call 911 and say
your house is burning. The fire brigade comes anyway.

The problem with my ActiveX-exe was that the fire brigade did NOT come
because my house was not really burning (I did not click on the button,
but said "Me.CommandButton1.Value = True" instead.
That is what I mean by calling 911.

Sounds absolutely strange (well, my story may, too, but I meant the code
part), but it's true. Unfortunately I don't have any more time to check
the reason for that.
Keith.

It doesn't have to be all the code, perhaps a pseudo-code view of the
over-all architecture. Generally what you are up to. The client is doing
this. The Exec is doing this. ... .... Something at least that we could use
to duplicate the problem.

There are other people around here that are experts (you can exclude me)
that can solve the problem - but they need something more substantial to
chew on.

-ralph

In one bit of code, you set eButton to mForm.btnNotification, but later on
your event handler is for something called eBtnNotification (i.e. with "e"
prefix). If the control isn't called that then this handler will never be
called and so never raise the Notification event

    Tony Proctor

I 'assumed' that was merely an an artifact of the OP posting 'Air Code'.
Quite funny if that was the problem all along. (Not that I haven't done that
myself on more occasions than I would ever admit. <g>)

-ralph