PeaShooter_OMO

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.

My sympathy. Does he even know who you are and what you do?

The constant attempts of people pushing the AI narrative is exhausting and it is getting old. How many more irrelevant places in life do we have to inject AI into? It seems similar to the IoT fad. Why do I need to have my fridge tell me what it has in it? I can lift my lazy butt, open the fridge door and check. Maybe then I will get the strong wiff of something going bad in there and replace it. 😄 OK. Done ranting.

All this is grand but at the end I still have to tell the "AI" what to do, then keep correcting it by repeating what I said but with additions and changes and then again go over everything it gave me just to make sure it did it right. That is time I could have spent doing a proper documented design and then coding everything myself. I started coding because I love coding. As such I don't dread spending time to type out code to get stuff done and so I don't need a Artificial Non-Intelligence to do my coding for me. Asking A"N"I for information is like walking a mine field. Numerous times while testing A"N"I it gave me totally incorrect answers based on poor data from the internet or even non-existing functions. There is nothing the A"N"I can tell me that I cannot already learn from people like @PeterBelow, @David Heffernan, @Jim McKeeth, @Darian Miller, @Uwe Raabe, @Anders Melander, @Remy Lebeau, @Dalija Prasnikar, (missed a bunch, I am sure). Most of them have already laid down a rich treasure of knowledge and Delphi wisdom on the internet. Willingness to search and read on my part is required though.

Unit Tests are an aspect of software developement that can lead to just another place of disparite disconnects between source code and intention and/or design and I surely don't want to give a current fad full of mistakes the ownership of that

Which AI does this, let alone reliably? I am not talking about it suggesting improvements based on its data indicating the speed differences between two similar functions, I am talking about how you phrased it above.

What do you get if you do GetLastError? If you look at the example given on Microsoft's document page for NormalizeString you will see: const int maxIterations = 10; LPWSTR strResult = NULL; HANDLE hHeap = GetProcessHeap(); int iSizeEstimated = NormalizeString(form, strInput, -1, NULL, 0); for (int i = 0; i < maxIterations; i++) { if (strResult) HeapFree(hHeap, 0, strResult); strResult = (LPWSTR)HeapAlloc(hHeap, 0, iSizeEstimated * sizeof (WCHAR)); iSizeEstimated = NormalizeString(form, strInput, -1, strResult, iSizeEstimated); if (iSizeEstimated > 0) break; // success if (iSizeEstimated <= 0) { DWORD dwError = GetLastError(); if (dwError != ERROR_INSUFFICIENT_BUFFER) break; // Real error, not buffer error // New guess is negative of the return value. iSizeEstimated = -iSizeEstimated; } } It seems the "buffer length required" returned from the first call to NormalizeString is in character length and not byte length because in the example it seems that the buffer is set to a length of the RequiredLength * SizeOf(WChar) You will also see that the parameters are described as " Length, in characters "