no async

[sehe]

Here's my edit on top of g9c3476 to show the interface as sketched in the synopsis on #9

I did NOT adapt the AHK/AutoIt scripts as I don't know enough about those script languages. However, you can probably trivially adapt, like I did in https://github.com/Danp2/WebSocketAsio/pull/11/files#diff-0279b7052b5595cd1c9558eb9a7f57a92f4b7d22dc75a53a3536ae6ec9879863R53

Note how making the end-user interface largely synchronous does not imply using synchronous implementation. In fact, as long as you want asynchronous closing/read operation you cannot because sync and async don't mix

Since you seemed to have hinted that AutoIt simply cannot afford async callbacks without undefined behavior, I'd consider moving to a fully sync approach. But I cannot judge whether (a) this suits your needs (b) what you would like the interface to look like.

[sehe]

Here's a live demo

In text form:

<WsDll-x64> Verbose output enabled

======================= First ==============

	Thread: 0 ::websocket_isconnected(h)	 -> 0
<WsDll-x64> Connecting to the server: ws://localhost:8080/something
<WsDll-x64> Run host_: localhost, port: 8080, path_: /something
<WsDll-x64> Issue async_read after connect
	Thread: 0 ::websocket_connect(url, unsafe_cb(on_fail), unsafe_cb(on_disconnect), unsafe_cb(on_data))	 -> 1
	Thread: 0 ::websocket_isconnected(h)	 -> 1
<WsDll-x64> Writing message: First message

	Thread: 0 ::websocket_send(h, L"First message\n", 14)	 -> 1
<WsDll-x64> Disconnecting
<	Thread:WsDll-x64> In on_read0 ON_DISCONNECT handle
#1
	Thread: 0 ::websocket_disconnect(h)	 -> 1
<WsDll-x64> 	Threread: Opaeradt:ion cancele d
0 ::websocket_isconnected(h)	 -> 0

======================= Second ==============

	Thread: 0 ::websocket_isconnected(h)	 -> 0
<WsDll-x64> Connecting to the server: ws://localhost:8080/something
<WsDll-x64> Run host_: localhost, port: 8080, path_: /something
<WsDll-x64> Issue async_read after connect
	Thread: 0 ::websocket_connect(url, unsafe_cb(on_fail), unsafe_cb(on_disconnect), unsafe_cb(on_data))	 -> 2
	Thread: 0 ::websocket_isconnected(h)	 -> 1
<WsDll-x64> In on_read
<WsDll-x64> Received[17] "Server Message 1
"
	Thread: 1 ON_DATA handle#2: "Server Message 1
"
<WsDll-x64> Issue new async_read in on_read
<WsDll-x64> Writing message: Second message

	Thread: 0 ::websocket_send(h, L"Second message\n", 15)	 -> 1
<WsDll-x64> In on_read
<WsDll-x64> Received[17] "Server Message 2
"
	Thread: 2 ON_DATA handle#2: "Server Message 2
"
<WsDll-x64> Issue new async_read in on_read
<WsDll-x64> In on_read
<WsDll-x64> Received[15] "Server Goodbye
"
	Thread: 3 ON_DATA handle#2: "Server Goodbye
"
<WsDll-x64> Issue new async_read in on_read
<WsDll-x64> In on_read
	Thread: 4 ON_FAIL handle#2: "read: The WebSocket stream was gracefully closed at both endpoints"
<WsDll-x64> read: The WebSocket stream was gracefully closed at both endpoints
	Thread: 4 ON_DISCONNECT handle#2
<WsDll-x64> Session not active. Can't disconnect.
	Thread: 0 ::websocket_disconnect(h)	 -> 0
	Thread: 0 ::websocket_isconnected(h)	 -> 0

[Danp2]

Thanks! It will take me a bit to better understand the proposed changes.

How difficult would it be to add support for using PostMessage as an alternative to callbacks to avoid the AutoIt quirks? I'm thinking that at minimum I'd need to store an additional hWnd and an Msg ID for each connection.

[sehe]

How difficult would it be to add support for using PostMessage

That seems like the wrong question. The question is "is hacking using windows messages a suitable workaround".

My take on this is a firm "don't go there". Instead, lobby AutoIt to add support for async events/callbacks. Or make your own interface usable in non-async fashion.

[Danp2]

The question is "is hacking using windows messages a suitable workaround".

Understood, but Windows messaging appears to be a workable alternative given the limitations I've encountered.

lobby AutoIt

Already done. However, the issue has been around for over 8 years, so I'm not holding my breath. 🙄

make your own interface usable in non-async fashion.

Would I still be able to receive messages event-driven?

[sehe]

Would I still be able to receive messages event-driven?

Not on the script side. You're free to implement the websocket part in whatever way (like now disconnect and send_message are secretly async as well). So, if you would be content to collect the messages async and poll them sync, that would be pretty easy.