Leaderboard

Quite possibly. Keep in mind that TCP is resilient to temporary network outages, so as long as the WiFi maintains the same IP when it comes back on, previous TCP connections may be recoverable by the OS if it hasn't invalidated them yet. On the other hand, if your code is not reading/writing data with the connection during the time that the WiFi is turned off, then it makes sense that you won't see a disconnect. It can take time for a lost connection to be detected. If the OS's internal timeout is not to your liking, you might consider enabling TCP keep-alives on the connection.

No. The connection has to be disconnected and reconnected, it can't be moved from one network to another. Android is doing the right thing. https://android.stackexchange.com/questions/83830/how-can-android-keep-a-tcp-connection-alive-when-changing-network-provider I would question why Windows is not doing the same thing, as it should be. Maybe your code is just not doing anything that triggers a disconnect during a network change? On both platforms, you might consider having your app register with the OS to receive network change notifications.

Yes, TSelectionEditor is the way to go. When a unit is saved or compiled, the IDE first invokes any registered TSelectionEditor classes relevant to that unit, calling their RequiredUnits() methods to update the 'uses' clause. Indy registers several TSelectionEditor classes for a few specific cases. But, I want to point out 1 editor in particular: TIdBaseComponentSelectionEditor. It is registered for TIdBaseComponent, which all Indy components are derived from. TIdBaseComponentSelectionEditor iterates all Indy components on a Form, using RTTI to look for any event handlers that are assigned to those components, and then to determine the types of any parameters and return values of those event handlers, and the unit names that those types belong to. It then reports those units to the IDE to add to the 'uses' clause. Now, one would think this is something that the IDE itself should handle automatically for all components, but it doesn't, or at least not completely. Which is why TIdBaseComponentSelectionEditor was created, instead of having to define a separate TSelectionEditor for each individual component that needs it. I mention this because Indy has a LOT of components, so it makes sense to handle something like this in a central place. So, if you don't want to write a bunch of smaller editors for multiple components in your library, you might consider a similar approach (although handling RTTI differences across multiple IDE versions can be a bit of a task).

To do what you need I would use computer vision, in particular the "pattern matching" technique. You can try to use the OpenCV environment which is developed in C++ but on the net there are several wrappers for Delphi (here is one: https://github.com/gidesa/ocvWrapper46). I can't help you with OpenCV though, I used it the last time more than twenty years ago. Now I use Halcon (www.mvtec.com) and doing this is not very complex. The problem is that Halcon is very expensive for the developer and there is a royalty for each distribution depending on the features used (up to 2k Euro). One of the last project, I used it to recognize up to sixty LEGO pieces in a selection line (total time near to 200 ms.). P.S.: Halcon doesn't support Delphi, but I can give you (should still be in some post in this forum) a Delphi wrapper around C Halcon DLL.