David Heffernan

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.

Given your definition of a developer, writing requirements etc, what even is a Delphi developer. Aren't there just developers?

It doesn't much matter what anybody expects the design to be. Too late for that now. Given that it takes the string as an argument, and it's a static class method, I think it's safe to conclude that you don't call it as an instance method. Wouldn't it just be better if the language forced you to call it on a class?

What is the subject of the method then? What argument are you going to pass, and what purpose does myString serve?

Surely it's If string.IsNullOrWhiteSpace(someStr) then like in .net

I'm so confused.

Start exists for a reason. It doesn't exist to create a thread and start it immediately. I still don't know the point of this code. What is the high level overview of what you are trying to do here?

UI code must run on the main thread. Although I have no clue what the point of this code us, I can see that it breaks that rule. Sad to see a thread be created suspended only to be immediately started.

Yes, but I'd not read your post and was making a general comment to the overall topic.

Why just wish for relaxing the 255 limit? Why not aim for multi line literals and more?

Not the 64 bit windows compiler

I'm not sure that @programmerdelphi2k is correct here. Consider RTTI. The compiler / linker can strip any code that it knows cannot be called. But with RTTI code can be referenced in ways that are only known at runtime. Therefore any code that can be reached by RTTI cannot be stripped.. Even if the linked knows, through static analysis, that it cannot be called directly