Adapting automatically Access code from 32-bit to 32/64-bit

[The_Doc_Man]

I need a system that, once the socket is opened, receives incoming data via an event

Part of your problem is that out of the box, Access is single threaded. In that basic context, you can't make something that both waits and keeps on executing simultaneously.

We have had inquiries in the forum that talk about using API "Fork" and process-thread calls to somehow set up a child thread to trigger AND WAIT for I/O to complete on your socket channel. The child thread could handle issues in I/O completion asynchronously and then, as its dying (well... exiting) breath, pass information to its partner thread about the I/O completion. I don't recall the result of those experiments in multi-threading, but that is how you would do it.

The original question runs afoul of the fact that Access has no I/O completion event because such an event would be unrelated to forms or reports. It can only do I/O synchronously out of the box so there is no need for an async event in that case.

 

[sonic8]

I don't recall the result of those experiments in multi-threading, but that is how you would do it.

I rather think, you would either use a non-blocking socket or just peek the buffer of the socket and then just the receive the volume of data that is actually in the buffer already. You could do the latter with a timer proc and then raise an event informing about the volume of available data.

Apropos timer, one could maybe also use an OS timer via API to receive that data because the timer's call back proc will run on a different thread (IIRC).

 

[The_Doc_Man]

You could do the latter with a timer proc and then raise an event informing about the volume of available data.

That's true. There IS such a thing as having a class object "With Events" and raise other events because of it.

Using an O/S timer to check for content is commonly called "polling" the device. Last time I used polling was a non-Windows system in the SCADA industry, where multiple I/O events might be pending at the same time off of multiple telemetry channels. It IS viable but the faster you poll, the less time you have for the main app and its "normal" events.

 

[amorosik]

Part of your problem is that out of the box, Access is single threaded. In that basic context, you can't make something that both waits and keeps on executing simultaneously.

We have had inquiries in the forum that talk about using API "Fork" and process-thread calls to somehow set up a child thread to trigger AND WAIT for I/O to complete on your socket channel. The child thread could handle issues in I/O completion asynchronously and then, as its dying (well... exiting) breath, pass information to its partner thread about the I/O completion. I don't recall the result of those experiments in multi-threading, but that is how you would do it.

The original question runs afoul of the fact that Access has no I/O completion event because such an event would be unrelated to forms or reports. It can only do I/O synchronously out of the box so there is no need for an async event in that case.

But how does a communications library like MsWinsck receive messages on the open communications channel?
If you use MsWinsck.ocx, you can use the DataArrival event and, when it's invoked, read the received message
I'd like to achieve this same functionality
I'm not sure how to do it yet, but that's the goal.

 

[amorosik]

I rather think, you would either use a non-blocking socket or just peek the buffer of the socket and then just the receive the volume of data that is actually in the buffer already. You could do the latter with a timer proc and then raise an event informing about the volume of available data.

Apropos timer, one could maybe also use an OS timer via API to receive that data because the timer's call back proc will run on a different thread (IIRC).

No timer
If you set it too fast, it wastes a lot of time unnecessarily
If you set it too loosely, messages risk arriving very late

I'd like to have an event-based system, and therefore probably, as The_Doc_man says, an external thread (what mean exactly??? ) that performs the synchronous work and then communicates with the main VBA code when there's something to communicate
Like the original MsWinsck.ocx

 

[amorosik]

I think the best solution is to reproduce the functionality of MsWinsck with an external library
I think it's one of the ways to make communication asynchronous with respect to events
So, even though it's the most difficult path, and I don't know where to start, I'm going to try to implement something along these direction

 

[arnelgp]

there is a sample in our Code Repository bank, and is uploaded in Github.

Serial COM Ports in Access VBA

Hello all, I've uploaded a new set of VBA functions for anyone still interested in using Serial COM Ports with Access. GitHub - Serialcomms/Serial-Ports-in-VBA-new-for-2022: Using Serial COM Ports in Visual Basic for Ap... Completely free, please let us know if they work for you thanks. J.

www.access-programmers.co.uk