Leaderboard

Forgot to mention, one of the advantages of a protocol like MQTT (there are other solutions with this advantage) is that you do not have to configure firewall on the workstations, only the server (incoming mqtt port), the clients just have an outgoing connection (most of the time allowed by firewalls), We had a solution first where client app's where listining on certain port, but this way we needed multiple ports per client, so also configuring the firewalls etc, that has fallen away now with the mqtt solution.

If stuff blows up with ASLR under 64bit then this is almost certainly because some code is calculating addresses wrong or unintentionally using 32bit data types where 64bit is needed which did not blow up without ASLR because it never had values higher than maxint. Often this can be caused by incorrect Winapi usage such as this

I agree, if you have the enterprise version of Delphi you could use DataSnap to create your own "exchange" server that way you control both sides. We use the DataSnap callback feature to register and unregister clients for by-directional communications via the TJSONValue so we have a dynamic message but still have structure. We validate concurrent usage licensing, request "check-ins", send user messages and can even terminate the clients. There is some DataSnap overhead but with a few clicks and every little code you can add authentication, compress and encryption. (encryption does require the deployment of 2 OpenSSL DLL's) There is nothing wrong with MQTT or other options, they are all good.

The IcsShellExec function moved units in V8.69, it is now in OAuth, but perhaps you have an old HttpRest unit with it still in? Or an old DCU. When installing a new version of ICS, it's always safest to use the Build Group pane to build all four versions of all packages, just wish it installed them as well. Angus

The solution I depicted with TCP socket can as easily applied when using a server dedicated to be a "exchange" server. MQTT is a complex product and Delphi implementation is likely to depend on a number of other product. Whatever solution you select, I advise you to only use products for which you'll get FULL SOURCE code and you'd never use prebuilt libraries or DCU but instead recompile yourself everything. This is the only way to be sure that in the future you'll be able to have your own product survive to the death of the external product you used.

Most probably you've changed the Label1.StyledSettings property. I've tried with the default settings of the TLabel you cannot change the style from the code. In order to work you have to add: L.StyledSettings:=L.StyledSettings-[TStyledSetting.Style];

Dave Nottage - Thanks! that's exactly what you said... Here in Brazil we have an expression of strength and gratitude that says: “Você é o Cara!” But I don't know how it is in English so I won't even translate... Thanks again friend! 👍👍 Perpeto - Thanks for the tip, it was my lack of attention...

I do not know, if this is an individual api key and requires protection, but maybe remove your google api key from your post above.

The problem is: Button1.HitTest := False. This makes it invisible for ObjectAtPoint. See end of 'TControl.ObjectAtPoint' code

Your intent-filter node is missing from the manifest. The activity node should look like this: <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity" android:label="MixPDV" android:exported = "true" android:configChanges="orientation|keyboard|keyboardHidden|screenSize" android:launchMode="singleTask"> <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="MixPDV" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity>

I'm implementing a new feature to the software I've produced that used e-mail as an alert. Now I'm also testing mosquitto as a server and I'm rebuilding a new MQTT client starting from an old repository on github https://github.com/wizinfantry/delphi-mqtt-client (that version is not working with new enviroment and needs some refresh). The current version of mosquitto supports up to the latest version of MQTT (MQTT 5.0 https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.pdf), SSL (up to TLS 1.3), TCP or websockets. Also you can connect to other brokers. And with retains, there's no problem at all losing alerts, especially using mobile devices as clients. In my opinion, since the server (broker) is already ready, implementing MQTT having a good Delphi "component" allows you to easily manage alerts. Bye P.S.: in this Embarcadero article there is more info and link to a client and broker MQTT write in Delphi: https://blogs.embarcadero.com/learn-how-to-use-the-mqtt-protocol-in-delphi-with-this-library/

Note that TCP is usually not a good choice for streaming media, due to delays caused by latency, integrity checks, acks, etc. TCP is good to use when you need to ensure the receiver actually gets everything that is sent. But since real-time streaming media doesn't usually require that, dropped packets here and there are usually tolerable, so UDP is used instead, typically with a streaming media protocol on top of it, like RTP, etc.