David Heffernan

What happens to an exception raised in OnCreate? EDIT: I was curious. This is what happens: procedure TCustomForm.DoCreate; begin if Assigned(FOnCreate) then try FOnCreate(Self); except if not HandleCreateException then raise; end; if fsVisible in FFormState then Visible := True; end; function TCustomForm.HandleCreateException: Boolean; begin Application.HandleException(Self); Result := True; end; So exceptions are handled by a top level handler, and then excecution continues. This feels like quite a strange design choice to me. Swallowing exceptions feels odd. You can change this behaviour by overriding the dynamic method HandleCreateException to return False. Like @dummzeuch I never use OnCreate or OnDestroy.

MainFormOnTaskbar doesn't do anything very funny, and it doesn't make your window be a tool window.

Yes, that is fair. I'm tempted to get a third monitor to run at 96dpi for that purpose!

An aside, but what would be the reasons for running the IDE dpi unaware?

You did

Indexing is fast

You mean Visual Studio? I think VS is a lot more robust and stable than RAD Studio which crashes a lot.

OK, there seem to be two questions asked by @Henry Olive The first one doesn't have any mention of a database, but has code that does not compile. The second question has database but we don't know what the values are. @Henry Olive you can't get a definitive answer unless we have precise details of what the data is. One thing we can say is that floating point multiplication is correct in Delphi.

This is fair. I looked at the first couple which are UTF-8, and then assumed they all were. But a couple of them aren't. Not implausible that the Delphi code in the OP is wrong though.

Where in the question is a database mentioned?

What language is this? It's not Delphi. Also, your expectation is incorrect. This is what Python says the right answer is: >>> 66.3333 * 1.5 99.49994999999998 I expect that if you showed your actual code, it would be clear what is going on.

This entire thread blows my mind. The number of people who think it's normal to read UTF8 as though it were ANSI.

I'd just read them using the UTF8 encoding in the first place and so never ever see these characters. I'm sure you would too.

It's UTF8. We don't need to check any more. And you don't need any more information than is in the original post.

Nobody says anything about uploading it to your customers system. You can store it as a resource linked to your executable to make it easier to develop and work with. There are good libraries for this in other languages, e.g. .net. Are there really no good Delphi libraries for this? Seems kinda wild that your customer is happy for you to splat an entire Python distro with third party modules (python-docx) onto their system, but OMG you can't save a text file with a script in. But yeah, go ahead and execute any code found in your executable, just don't save it to my disk. Doesn't sound very rational.

Yeah. Don't write code like this. Put the code in a text file and link it as a resource. And then debug the code in Python. Once you've debugged it, run it from Delphi.

The text is clearly UTF8 encoded. That much we already know.

No. We know the text is UTF8 encoded so just load it specifying that encoding. No point adding a extra step.

It's when you read the output into Delphi that there's a problem. You tool is emitting UTF-8 encoded text, but you are interpreting it as ANSI. The tool is fine. Your code is not.

That doesn't sound quite right. I wonder if there is another Python somewhere in the system. The only thing in that line of code that looks like a syntax error is the f-string, but they are supported in 3.6. In fact they are new in 3.6 iirc.

Isn't the real problem that you have interpreted UTF-8 encoded data as though it were ANSI? I mean, it's clearly not ASCII because none of the characters in your code are in the ASCII set. You can actually delete all of these StringReplace calls by simply using the correct encoding for your extracted data.

What version of python? You'd get this error with Python 2.

FWIW the Delphi code doesn't compile. Always paste code that is known to work, rather than copy it out manually.

There's an awful lot of anecdote doing a lot of heavy lifting in this thread. I'm seldom persuaded by anecdote. Some thoughts occur to me though. If companies want developers to code in Delphi, but want some body else to train them, then this isn't sustainable. People retire. And then what? Also, I just don't buy the idea that smart talented developers can't learn new technology quickly. We took on a uni placement student this year, who had done two years at uni and no Delphi. They were productive in weeks. And most of the learning was of our code base. I honestly think that if you aren't prepared to take on talented developers and teach them a new language and libraries, then you have far bigger problems as an organisation.

That's not my experience. But when I hire people I'm looking long term.