PeaShooter_OMO

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.

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