PeaShooter_OMO

@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.

@Der schöne Günther Do you call the Connected function anywhere? Indy can be used from multiple threads but how you use it will drive that decision. I created a TCP framework using Indy and my Client component has a ListenerThread. So the ListenerThread obviously will be polling for incoming data. Sending will be from other threads, obviously the threads that calls the SendXXX commands. The issue was that inside the sending threads (inside the SendXXX commands) I used to ask via Connected if the connection was still there and that caused anomalies. The problem is that Connected actually reads from the socket and thus you will have multiple threads reading from the socket. Not a good thing to do. So in my framework's functionality one thread read/receives all data and hands it off to an event where whoever implements the event can sync or do whatever it pleases with the data but on the sending side I make sure I don't read the socket. If in your case a thread follows the traditional way of Sending-Reading-Sending-Reading-[repeat] all in itself then make sure you lock that so that only one thread does that at a time but also take note of Connected's consequence.

This topic is not because of an issue but just me messing around in order to learn. On Delphi XE3 and Windows 10 I am interested in the overhead of calling a routine. In the code below I call the same function directly and indirectly to determine the overhead involved with calling a routine in Delphi. I use a 100 million iteration loop to be able to note the difference. Obviously a few nanoseconds per call is not much to write home about but I might be making some wrong assumptions here. Apart from calling directly what would I have to keep in mind to achieve good performance when calling in an Indirectly way when a more complex function is being used with more complex code and more complex parameters? function DirectlyAddOne(const AValue : Integer) : Integer; begin Result := AValue + 1; end; function Indirectly(const AValue : Integer) : Integer; begin Result := DirectlyAddOne(AValue); end; procedure DoLoop(ACallDirectly : Boolean); var I : Integer; LTickCount : Cardinal; LValue : Integer; begin LValue := 100; LTickCount := GetTickCount; // 100 million iteration For I := 0 to 99999999 do If ACallDirectly then LValue := DirectlyAddOne(LValue) else LValue := Indirectly(LValue); LTickCount := GetTickCount - LTickCount; ShowMessage('Directly? ' + BoolToStr(ACallDirectly,True) + #13#10#13#10 + InttoStr(LValue) + #13#10#13#10 + InttoStr(LTickCount) + ' ms'); end; procedure TForm1.ButtonDirectlyClick(Sender: TObject); begin DoLoop(True); end; procedure TForm1.ButtonIndirectlyClick(Sender: TObject); begin DoLoop(False); end; RoutineOverhead.zip

@GabrielMoraru The GitHub link at the end does not work

Its a pity you won't be able to lets us know how many of all those requirements your final candidate actually has, when you find him of course. It would be quite interesting to see.

@Kas Ob. Deriving another class for the Borderless form did the trick. It is an interesting one, indeed. Thank you for your input.

In Delphi 11, Windows 10... I have a small project where I create a form (the same Form object) with two different states; a Normal form and a Borderless Shadowed form (created via CreateParams and CS_DROPSHADOW). After starting the program, if I create the Borderless form first then the shadow will be there. If I create the Normal form first and then the Borderless form then the shadow of the Borderless form will not be there. Attached you will find a .zip file with the project. Project.zip Steps to produce the strange behaviour... Start the program Create the Normal form first Close the Normal form via the "Close" button. Create the Borderless Shadowed Popup form. Notice the shadow does not appear. You can close and create all you like. The shadow never appears beneath the Borderless form. Steps to produce a shadow at all times... Start the program Create the Borderless Shadowed Popup form first. Notice the shadow is correctly appearing. Close the Borderless form. Create the Normal form. Close the Normal form. Create the Borderless Shadowed Popup form again. Notice the shadow is correctly appearing. You can flip-clop between the two as much as you like, the shadow will always be there. Obviously I would expect the Borderless form to always have its shadow. Am I doing something wrong? type TFormMain = class(TForm) ButtonCreateNormal: TButton; ButtonCreateBorderless: TButton; procedure ButtonCreateNormalClick(Sender: TObject); procedure ButtonCreateBorderlessClick(Sender: TObject); private public end; var FormMain: TFormMain; implementation {$R *.dfm} uses UnitPopup; procedure TFormMain.ButtonCreateBorderlessClick(Sender: TObject); begin FormPopup := TFormPopup.Create(True); FormPopup.Show; end; procedure TFormMain.ButtonCreateNormalClick(Sender: TObject); begin FormPopup := TFormPopup.Create(False); FormPopup.Show; end; type TFormPopup = class(TForm) Panel1: TPanel; ButtonClose: TButton; procedure ButtonCloseClick(Sender: TObject); private FIsBorderlessPopup : Boolean; protected procedure CreateParams(var Params: TCreateParams); override; public constructor Create(AIsBorderlessPopup : Boolean); reintroduce; end; var FormPopup: TFormPopup; implementation {$R *.dfm} procedure TFormPopup.ButtonCloseClick(Sender: TObject); begin FreeAndNil(FormPopup); end; constructor TFormPopup.Create(AIsBorderlessPopup : Boolean); begin FIsBorderlessPopup := AIsBorderlessPopup; inherited Create(nil); If FIsBorderlessPopup then begin Panel1.BorderStyle := bsSingle; Panel1.Caption := 'Borderless Shadowed'; end else begin Panel1.BorderStyle := bsNone; Panel1.Caption := 'Normal Form'; end; end; procedure TFormPopup.CreateParams(var Params: TCreateParams); begin inherited CreateParams(Params); If FIsBorderlessPopup then begin Params.Style := WS_POPUP; Params.WindowClass.style := Params.WindowClass.style or CS_DROPSHADOW; Params.ExStyle := WS_EX_TOPMOST; end; end;

@Berocoder Does your SQL Servers update automatically through Windows Updates or some other mechanism? Was there any other Windows Updates that took place? What does the Performance monitoring on those machines/VMs (client and server) tell you about the current state of the machine when this issue appears or when you run those slow queries?

I am always amazed at the ideas people come up with. Well done.

Yes, from FMXLinux's website it seems to be the case even if you buy it separately.

I am unsure about that class. In what unit is it declared? I can't find it in Delphi 11.