The reason you can't add events to a form in Access is because the events are actually (for the most part) hard-coded in Access, which is a compiled program. The reason your form sees a Current event is because Access goes through the steps of synchronizing a form's controls to the underlying record in the MSACCESS.EXE file's Current event subroutine and, at some time during that software routine, Access CALLS your Form_Current entry point as a second-layer subroutine, probably using a dispatch table. To add an event, you would need to have the Access source code so you could modify it to define a new event that would then - as part of its action - call your new VBA event subroutine and would add a new event slot in the dispatch table.
There might be a few tricks you can play. The idea of building your own C# or C++ variant .DLL would be to create a new class, perhaps, that had some specific events in it. However, there is still the issue of having this handled by Access - which we have already decided doesn't like foreign events.
You have run into the Microsoft non-interference directive - no process may interact with another unwilling parallel process without dire consequences. It's part of an old security standard regarding process isolation for security reasons. The only interactions that can do such a thing would involve WinAPI stuff involving semaphores, and even there you can run into issues. But... there is a possibility.
My advice would be if you wanted to look into WinSocket programming, you could create network sockets and send messages from PC1 to PC2 and PC3 whenever PC1 thinks it should. THEN have forms on PC2 and PC3 that have "listener" sockets established and set yourself up to have those sockets do a blocking i.e. synchronous I/O READ. When PC1 sends out two copies of its message (one each to PC2 and PC3), they can each wake up i.e. satisfy the I/O READ, and dispose of the data in the appropriate manner. That might involve putting the synchronization point in the PC2/PC3 form's Current event after creating a new record to store new data from the previous message. (I'm making assumptions about your process.) When stuff comes in, process it and get it into each of PC2 & PC3 soonest possible. If you trigger the form update operation from the Current routine, you will go through the update-related events normally simply by exiting the Form_Current routine after having triggered the update. If there WAS in fact an update, there will be a following Current event, which then perpetuates the cycle. You can choose any of a dozen ways to end the cycle including PC1 sending a Drop-Dead message or having control buttons on the PC2/PC3 forms. You prevent getting stuck by putting timeouts on the I/O READ and if the status comes back "timeout" you can check the "STOP" buttons or whatever other method you choose to grind this to a screeching halt. If it is NOT time to stop, just jump back and re-issue your I/O READ.
This would work reasonably well as long as you set up the sockets to store & hold messages sequentially, so that if PC1 suddenly sends a burst that is faster than PC2 or PC3 can handle, the network buffers will hold the messages to be delivered sequentially. As long as the messages are not so long and so fast as to blow out the network buffering capacity (which I believe you can control with WinSock connection setup routines), you should not miss anything.
You were concerned about the load involved here. Other than possibly sending a "keepalive" blip every few seconds (30 seconds being typical), there is no load at all on PC2 & PC3 other than the fact that they are in memory. An I/O WAIT state does not execute instructions. The status of PC1 is also at least under you control, in that if you don't have to send anything, don't send it. What else this MQTT server does, I can't address. But if it ain't sending over the socket, all that will be running is the every-30-second keepalive overhead, which usually doesn't amount to much.
This suggestion will work if you can do what is required for the WinSock programming and does not involve ANY new events in Access. Search the forum for issues of using WinSock or other network comm channels. This WOULD be one of those ways where the non-interference directive doesn't come into play, because you would have a mechanism for that interference. It would count as expected interference and thus is OK.
