Anders Melander

FUD much?

That's not necessary; The attach dialog doesn't allow you to attach an instance to itself:

They probably thought it was a good idea at the time (wasn't this before they fired everybody?) but unsurprisingly that didn't work out for them and now it appears to be in "maintenance mode". So, a good example of why it isn't a good idea. So because they have done something in the past, and it has mostly turned out to be a bad idea, it would make sense for them to continue to do it? Interesting viewpoint. Sure, it would be nice if the feature was built-in but I don't really think acquiring a 3rd party product (and that product in particular) is the best way for them to cover that. I think it would be better if they simply provided the framework to make it possible instead. This could be the miraculous exception to the rule, but acquiring something to plug a hole (or whatever the reason) doesn't just end once the rights has been transferred. There's also integration, branding, documentation, infrastructure, education, support, etc. And then there's the cost of maintaining it once you have made it a core part of the product. Entering straw-man territory. We don't know how the debugger does stack tracing and we don't know if or why they might have made a choice or what choice they made.

There's really no point in using a third-party logger if you are going to resolve the stack trace manually like that. It would just add overhead and complexity.

You are not really addressing the point I made; How is the fact that something is useful to the user relevant to Embarcadero if they are not going to make money acquiring it? It's not as if it's a strategic feature. Besides that, I don't see the benefit from the users standpoint. Embarcadero does not have the resources to properly maintain something like this and they would just hurt the other existing exception handlers (madExcept, EurekaLog, etc.) which in turn would hurt the users.

Button captions and such are defined by resourcestrings. For example, see Vcl.Consts.pas: resourcestring [...lots of strings...] SOKButton = 'OK'; SCancelButton = 'Cancel'; SYesButton = '&Yes'; SNoButton = '&No'; SHelpButton = '&Help'; SCloseButton = '&Close'; SIgnoreButton = '&Ignore'; SRetryButton = '&Retry'; SAbortButton = 'Abort'; SAllButton = '&All'; You can use any of of the many different localization solutions to have them translated. E.g. this one: https://bitbucket.org/anders_melander/better-translation-manager

Install madExcept and use that to detect and report when the application freezes (provided the freeze is caused by the application not pumping the message queue).

They are in business to make money; Not to be practical. I can't imagine that they would sell a single license more because they had a cross-platform stack tracer.

I can't see why they would do that.

Life-time license. Sounds good but in reality it means the developer has no incitement to maintain the product - at least not a commercial one.

This sounds like contract work; You should probably clarify. A screenshot of the existing forms would also be nice.

https://www.google.com/search?q=delphi+"rrequires" As far as I can tell the only identified cause seems to be line endings. Of course that doesn't rule out that there might be other causes but until we get an answer from OP all we can do is guess.

No; Something else has changed. Anyway, it's still unclear what exactly you are doing and it's hard to overcome the language barrier when you aren't answering the questions. If English is a problem then use Google translate. a) Please explain, step-by-step, what you are doing. b) Did you check the line endings?

I for one can't understand what you are saying.

The Drag and Drop Component Suite disables the IDE as a drop target during debug. It does this to prevent the deadlock that would occur if you dragged something over the IDE while you were debugging. You can disable this behavior by commenting these lines in DropSource.pas: initialization // Disable Delphi as a drop target so we won't deadlock if we accidentally // drag over the IDE while debugging. if (DebugHook <> 0) then DisableDelphiDropTargets; Did you check the line endings?

I can't really see what these two issues has to do with each other and you are not helping anyone by raising both in the same post. 1. Looks like a cr/lf problem; Check that the file only uses cr/lf line termination and not just lf. 2. What do you mean by "does not work in IDE"? What exactly are you doing? There's another thing common to both problems...

Wow... 2 bit color depth. This looks like a really bad attempt at supersampling. Or someone got the order of gamma correction mixed up so instead of sRGB->Linear->sRGB they are doing Linear->sRGB->Linear. But that wouldn't explain the 2 bits.

Delphi generates a .res file with the same name as your .exe file. This .res file contains the version resource and the application icon. If you post the .res file here we can take a look at what it contains.

So how would you handle the case where the specified font can't map a character causing a fallback font to be used?

I think the result in the first post shows that you do have to worry about the font used. The clusters a shaper, such as the one in Uniscribe, produces are part of a run of characters with a single script and a single specific font. If a string of text contains different scripts, or characters which can not be represented by the font, then the layer above the shaper will have to split it up into multiple runs and process each run individually. The reason is that different scripts have different shaping rules and the font (assuming it's an OpenType font) dictates many of the rules. It may very well be that Uniscribe hide most of these things but in the end the result will still be that multiple fonts are used and that the glyphs shown, and their size/position, depend on the fonts.

You might want to search for info on that. You know, in case you aren't the first with that problem...

It's a common problem for Delphi developers who either refuse or don't know how to configure their Git client properly.

TProgressBar is just wrapper around the standard Windows progress bar control so its features and behavior is dictated by that control. It's extremely easy to make a custom progress bar that does what you need with a TPaintBox; It's just two FillRect and two DrawText.

Nowadays you could just use one of the many LLMs. It's one of the few things they are actually good at. https://medium.com/@kapoorchinmay231/large-language-models-llms-for-code-conversion-new-age-of-ai-72ebd2c8918d

You are talking about shaping which is not relevant to the problem here. Shaping translates a stream of Unicode code points into glyph IDs and the result 100% depends on the font used to do the shaping. That is the whole point of shaping. FWIW, I've written a shaper so I know a bit about these things... Anyway I just realized that I forgot to explain why it is that... three characters occupy five columns ...even though the font is monospaced. The reason is that the font doesn't contain a mapping for the three Unicode codepoints (U+7F16, U+7801, U+FF1A). So what Windows (or whatever) does, instead of just giving up and display � or □, it searches its fallback font list for a font that 1) supports the Unicode script of the characters (Han in this case) and 2) contains a mapping for the characters (i.e. can map codepoint to glyph id) and then it uses that font to display the glyphs. Since the fallback font isn't monospaced, or at least isn't monospaced with the same character width, you get a different glyph width.