PeaShooter_OMO

Strange how that triggers a an OCD response in me when I see it.

Possibly but for an issue on a major feature of Delphi that has come for decades already one would expect hard steps to be taken. If it was easy fix it would have been already and seeing that it is hard to fix it would require extraordinary steps. If the steps that were taken already does not work then one would expect another approach.

Spending multiple days at a customer experiencing the issues will give Embarcadero a better understanding than sitting and waiting for someone to present a reproducible example. They can take their dev tools along and capture all the logs their hearts desire.

Embarcadero asking for reproducible examples and not going out to customers with the same issues wil make sure we will have this nonsense for years to come.

I assume Delphi itself is a large project and surely Embarcadero must be seeing the same LSP issues we are seeing while using Delphi. Are they? I just wonder sometimes.

You talk about an issue creating a new project but then talk about a StringGrid being on Form3. Strange. I have no definitive idea about what the issue is but I would try to clear the whole "Projects" folder under "c:\Users\<your_user_name>\Documents\Embarcadero\Studio" and then restart Delphi.

Why? Would you mind elaborating on this?

What type of communication/interface have you and/or are you currently trying? How are you connected to it? It seems that it has SPI and I2C capabilities. Do you have documentaion on how to interact with the MCU?

Clicking outside the modal form will not register a mouse down, even through TApplicationEvents.OnMessage. I suspect you might have to use Windows System Hooks with WH_MOUSE. I have not done this before though and as such cannot confirm if this would be the most appropriate way to do it.

Whether you pass a specific exception to the client or a specific failure code to the client comes down to the same thing. I do not see the need for the client to be handling an exception which happened on the server. The client literally only needs a proper response from the sever with enough information for the client to know exactly what happened. A specific exception (eOverflow, eConvertError, eInOutError, eListError...) does not have more information than a well coded failure code with additional accompanying data (if required). This all comes down to proper coding practices and a well thought out application layer protocol. I also think this might be moot because sending an exception to another application is as far as I know impossible. What might look like its is being done in other frameworks might just be the framework getting information via TCP from the other side and then just reraising the relevant exception on this side.

Double-click happens higher up in the inheritance chain of controls which means it does not consider the intended control's properties or functionalities because those don't exists where Double-Click originally is handled. This means you cannot prevent a Double-Click from happening just as is via any event. You have to intervene in another way Fortunately DrawGird has public properties and methoss that can make it easier for you to decide whether you want to do something in OnDblClick for only certain columns, rows or cells. So you will check where the double-click took place and then only act when it fits the criteria. One would think to look at DrawGrid.Row and DrawGrid.Col. They are set before Double-click and you can read them to get the cell where the click took place. The problem with them is when you click outside the cell range, a blank space in the grid for instance, then the last cell that was set will be given to you instead of the expected (-1,-1) coordinates. So you can look at DrawGrid.MouseToCell which will translate the mouse cursor position into the cell underneath the mouse cursor. Keep in mind MouseToCell takes Grid-relative cursor position as input. Thus you will have the cell that was underneath the cursor and now you can decide whether you wanna act or not.

Exceptions are application bound and as far as I know they cannot be passed between applications (would be interested to know if they could be). I believe you may be approaching this incorrectly. What happens on the server is not an extension of what happens on the client. The TCP connection is merely a channel to exchange data and each side has its own municipality and exceptions should stay in their own municipalities. For instance; Let's say the client is currently executing from inside a procedure and it sends a request or some other data to the server. The server then does something with it and maybe an exception happens. It means the exception happened on the server side, not the client side. The server code is supposed to handle that in an acceptable Delphi standard way and then inform the client that there was an issue and as such appropriate action should take place, like resending the request, etc. It does not mean that an exception happened inside that client procedure thus the client does not need an exception, it only needs a headsup that an issue occured which could be remedied. Also, if the exception happened because of a Non-TCP-related issue then there should be no reason for the TCP communications to be affected. But I think the most important for you would be to handle all your exceptions as a default way of coding and then decide what to do when an exception happens. Exceptions should not halt an application if you coded in a preventative manner. After you coded exception-handling for all possible exceptions you could think of then you design a TCP protocol around what you want to achieve. For instance the client sends a request to the server for data then the server will try to get the data from its source and send it back to the client. If the server fails to get the data then the server will inform the client it failed just by saying "Hey I could not get that data for you" and not "Here's an exception for you". The client can decide what it must do next. There should be no halts, no freezing, no sudden stoppages. A side note; Many exceptions can be avoided by looking at state beforehand and acting upon that instead of waiting for an exception to happen. If you don't want a situation of StrToInt('hello') to cause an exception then don't allow 'hello' to reach that point. In a way it can be proactive instead of reactive.

Adding to Lars's advice above. A side note in respect to Indy... I mostly use Indy's TidTCPServer and in it each connection (context) has its own thread where your code is run, the OnExecute event. If you have not caught an exception in those threads through your code then it will be caught by TidTCPServer in anyway and it will affect that specific connection. It should not affect other connections that were made to TidTCPServer. This is in relation to Indy itself. It is of course another ball game if you are talking about exceptions inside your server application but outside Indy's influence where your code determines how it affects the continious working of the server application in regards to the other clients. Extra care should be given as Lars said. Exceptions related to Indy TCP socket operations are important to TidTCPServer itself and if you catch an exception when doing socket operations so you can act on them then it is always a good idea to also let that exception flow upwards so that TidTCPServer can also get it in order for it to take appropriate action like closing a socket. Prevention is better than cure and anywhere in code where you might get an exception is a good place to handle each of them and respond appropriately.

It sure would be funny if your boss was to ever post a Delphi question on some forum and you replied with the answer. Considering his stance on AI it would probably be "Why does this AI code not work like I asked it to".

Agreed, it does have value. Not so much in Delphi for me but when I need a good chuckle I ask it to tell me a story of about 1000 words in some sort of modern setting. It was instructed by its lords that it needs to bring forth good feelings so the story usually runs along the lines of an innocent intro, a unexpected but nice chance happening and then a heartfelt happy ending. I then instruct it take the exact same story and reverse/opposite everything in it, so what was positive ends up negative or the totally opposite. Makes a funny story.