PeaShooter_OMO

I do not think so. I would rather have them post to a Forum Category of their own. Maybe another one under Third-Party. As long as they stick to the Delphi/C++Builder ecosystem it should be allowed on that Forum. It can be a good place for companies/individuals to post their DelphiC++Builder related products. Who knows, each post might turn into a solid discussion. I do not see @Serge Pilko post much after each "advertisement" and maybe if he has a place to advertise then he might engage more with those who ask questions. Who knows. I use the "Unread Content" links to see any new post an all forums and I already filter out what I am not interested in by skimming the subjects of each. Having an "advertisement" on that Forum Category pop up amongst new Unread Content will not bug me at all. But again; the moderators will know better than me what the intricacies of this community is.

Open sourcing one of your products can be a viable option if your company is making hundreds of millions or even billions of dollars from other products and services already but not so easily done if it is one of your main income streams. I agree. I am obviously not clued up about what goes on behind closed doors at Embarcadero when it comes to their finances but the pricing of Delphi has always been at the center of discussion. Embarcadero is probably just trying to pull off a balancing act to make the most of what they have. This point has been discussed probably hundreds of times before. I also don't think open sourcing can fix the Delphi issues we have. The best we can hope for is for Embarcadero to pull off a turnaround and somehow change their business model and approach without going down in flames or perhaps for somebody with very deep pockets to buy them out, someone with a passion for the product. (One can wish, right? )

I myself would not consider it to be denial by some in the Delphi comnnunity. I honestly believe most of the great Delphi coders are positive and definitely hopeful for a brighter Delphi future. Yes, Embarcadero make mistakes and some of those might affect the community negatively but I believe there are so much going for it. I might be wrong but it looks to me that there is growth in some non-English speaking countries in Delphi users. I think they look at what works for them instead of following fads like so many others are doing. Time will tell.

Finally.... I used AI !!!!! I am so happy now.

I you are truly increasing your productivity and income through using Claude then I am willing to concede in your case.

Thats rough. I cannot imagine it being worth so much money just for coding. So where do you plug your coffee machine into so that Claude can make coffee as well and perhaps wash the car? I need clothes ironed.

I might be missing what you mean but previously I told the "ai" which library I use which has extensive documentation and the ai would make up library functions out of thin air.

@Kas Ob. It is like having a conversation with an old pal who you know is an "embellisher" or "exaggerator". You never trust what he says and always suspect a lie being told. That is counter-productive. I would rather do the work myself. I use AI as a glorified search engine and still I doubt the answers it gives. And I absolutely hate the assumptions being provided as facts. Many times I see the AIs do that.

It is always a good idea to not hard code any widths related to the visual apsects of controls. They might change when the OS changes version. You have to get the width of the non-client area of a ComboBox so that you can add it your calculated MaxTextWidth to get a proper control width. But... ComboBox does not play nicely and getting its ClientWidth is not possible with functions like GetClientRect thus ComboBox does not have a properly calculated ClientWidth for it so you will have to make another plan to get it. There is a Win32 function called GetComboBoxInfo. It returns a record with details about the combobox like size of the control, the size and position of the button and size of position of the edit control in it. You will use the width of the edit control and deduct that from the width of the ComboBox and there you have the non-client area width. Just add that to the MaxTextWidth and you have the size the ComboBox should be. Remember to do these calculations and setting of the ComboBox size again when the Windows theme or settings change or the font changes.

If you are willing to consider another route then have a look at MadExcept. It can do screenshots and is an extremely useful tool.

@Der schöne Günther The best way I could reasonably reproduce my issue was to send a larger continous stream of bytes with some of my threads. If your issue is realated to my stance of not reading from the socket from multiple threads then it is possible to encounter the issue when you send a longer stream of bytes from the other side. This side it would be read on one thread. Have another thread try to send data at the same time back with a call to Disconnected thrown in. The larger data would give you time to see what happens with multiple access to the socket. A "poke-in-the-dark" suggestion.

I could not reproduce it precisley either when I had my issue. It would just happen whenever the gremlins were bored. I suggest you take a look at either a single thread that handles all comms or perhaps a single sending thread paired with a single receiving thread for all comms like I do and keep all the Indy/ModBus calls in that thread.

This is deliberate, because the device is a simple controller that cannot serve multiple requests. It can only keep one socket connection open. Therefore, the Delphi app is only opening one connection and sharing it throughout the code.  Remy's second suggestion would be a good idea... My framework also has a thread for sending. It is working on a single socket after all .

@DelphiUdIT PlcBot.Connected and PlcBot.IOHandler.Connected is the same. Inside Connected it checks against IOHandler.Connected. Checking against Connected is not wrong but be mindful that you might get issues when doing so at the same time as reading the socket from another thread.

I basically got rid of worrying about the connected state via Connected and just did try...except around the socket access parts and then react based on that. I do keep a state flag internal for myself but that just indicates if there was a successful connection made in this session.