David Heffernan

1. More complicated. Depends on the type of code and the libraries. 2. Fair. 3. Not sure about that. 4. Definitely not universally true. Perhaps for Windows GUI components, but probably nothing else. 5. Don't agree at all. Don't you see that different tools are better in different settings? Surely everyone understands that.

Click on the word no

Kind of funny that this site returns a page with a link to the emba site which in turn is a 404. Well, actually it's a 503 but whatever. So even if delphi isn't dead, isdelphidead.com is dead. A meta death if you will.

It's broadly accurate I'd say. What you should ask is the reverse, what advantages delphi has compared to python. For what it is worth I use both delphi and python. For some tasks one is better, for some the other is better. And I use a number of other languages too. Use the the tool that matches the job. In fact my product has a python api and can also host embedded python.

@pyscripter do you know if it's reasonable to implement the python mapping protocol on the Delphi side so that from python it looks like a Python mapping?

Consider a large dictionary with, for sake of argument, 1 million items in it. Suppose in Python you wanted to write value = foo[name] Now if foo was actually in your Delphi code, and backed by a Delphi dictionary, do you really want to populate a new Python dict with 1 million items, then perform the lookup in Python, and then throw away that dictionary. Wouldn't it be better to just ask Delphi to perform the lookup. This is what I mean what I talk about the mapping protocol. But it's entirely possible that I have misunderstood what you actually want to do!

Do you want to create a new instance of Python dict every time the property is called? Or aren't you looking to implement the Python mapping protocol so that Python has something that behaves like a dict, but actually just reflects the underlying Delphi object?

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.