Anders Melander

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.

...or one could just use TCanvas.TextWidth (VCL) TCanvas.TextWidth (FMX)

Here's a good explainer on the problem you are facing: https://stackoverflow.com/questions/27331819/whats-the-difference-between-a-character-a-code-point-a-glyph-and-a-grapheme

That doesn't help with aligning text in a text file.

I can't see how it can be done. Even if you roll your own, which you would have to, and even with a monospaced font, the width will depend on how the particular font composes Unicode code points into graphemes (individual graphical units) and then glyphs (the visual representation the font produces).

You really shouldn't prevent the user from moving the focus; It's one of the most annoying ways to do validation. Instead do your validation in the OK handler. If you use TActionList you can also do the validation in the OnUpdate event handler and only enable the OK button when all validations pass. If you want to be really nice to your users do the validation while they are entering data but instead of blocking them just indicate errors with color or a symbol.

Nope. It's there so that a process which Knows that its access and allocation patterns will have caused the working set to grow. Knows that it will no longer need that working set for the foreseeable future. Has virtual memory backing store (i.e. page file). can trim the working set in order to lessen the memory pressure on the rest of the system. But you don't have virtual memory so this don't apply to you. By trimming your working set the only thing you have accomplished is to move pages to the working set cache. Since you don't have virtual memory, nobody else can use those pages anyway because their content can't be saved anywhere. So the only thing that can happen to them is that they will be paged back into your working set at some point when your process needs them. End result: Nothing but overhead.

You still haven't understood how this works. The memory in your working set isn't "owned" by the process; It's owned by Windows and the process only has it on loan. If Windows needs the memory for something else (e.g. another process) it will take it back without any action needed (or possible) from your process. The working set pages that you are trimming are unused by the process but was assigned to it at some point because it needed them. The reason that the OS hasn't removed them from your working set by itself is that there has been no need for it; Nobody else has made a memory request that couldn't be satisfied elsewhere. The whole idea behind the working set model is to allow the system to grow and shrink the working sets based on demand. Why not spend 30 minutes to read up on how it works. Just Google windows working set. Or simply search for EmptyWorkSet and see if you can find a single person who thinks it's a good solution.

You are. The working set are the pages of a process' virtual memory that resides in physical memory. They are there because the process has a need for them to be there (e.g. it has referenced an address in virtual memory causing a working set page to be mapped to that address). If something else in the system has a need for physical memory, and it's all in use (which, by design, is normally is - because why not) then the least recently used pages will be paged out and eventually written to the page file, so the physical page can be mapped to the other process' working set. The above is just a simplification of the virtual memory management but the point is that, unless what you are doing is really extreme, then you don't have to think about it; It just magically works. I know everybody has to go through the phase of thinking that they can outsmart the OS virtual memory management by messing with the working set but you really should leave it alone. The OS virtual memory system was designed 50 years ago by people who actually knew what they were doing. You might very well be having memory issues but look to the memory manager instead. The working set isn't the problem.

It would be so sweet if people voicing opinions about how [insert topic here] should work actually understood the topic.

That's up to you. I just need the three parts separate: layout, structure, content. Layout is provided by some kind of customizable templates. Structure data is provided by the source code parser. The user provide the content via some nice editors. I don't care if the content format is XML as I can easily migrate any existing data to another format. Here's a small example of some documentation built with DI: https://github.com/andersmelander/DWScriptStudio/tree/master/Documentation And another: https://developer.sigmaestimates.com/api-reference/ Both of these were built by generating pascal source code from DWScript meta data and then let DI have a go at that source. Since the source is generated, the help content has to be external to the source. However, the big problem with the output generated by DI is that it is impossible to integrate it properly into an existing website since it must be embedded in an iframe. For example I have another site where the main content of the site is conceptual help. I would like to have the API documentation integrated in this but because of the iframe it is impossible to link from the conceptual help directly into the API help and vice versa.

Yes.

The integration isn't really the important part although it's nice to be able to navigate the source while the help editor/navigator follows along. Extracting comments from the source can already be done by the compiler so that isn't that interesting for me personally. Also, I find that, although it appears to make sense to document the API in the source, it ends up completely obfuscating the source. I prefer to have the help text separate from the source. DI has an option to either maintain in-source comments or store the data in external files. Like this: <?xml version="1.0"?> <doc> <members> <member name="AnsiCompareText(string,string)"> <summary>Compares strings based on the current locale without case sensitivity.<br></br> <br></br> AnsiCompareText compares str1 to str2, without case sensitivity. The comparison operation is controlled by the current locale.<br></br> </summary> <param name="str1">The first string to be compared.</param> <param name="str2">The second string to be compared.</param> <returns> <list type="table"> <listheader> <term>Condition</term> <description>Return value</description> </listheader> <item> <term>str1 = str2</term> <description>Zero.</description> </item> <item> <term>str1 &gt; str2</term> <description>Positive value.</description> </item> <item> <term>str1 &lt; str2</term> <description>Negative value.</description> </item> </list> </returns> <seealso cref="CompareText"></seealso> <seealso cref="AnsiCompareStr"></seealso> <seealso cref="CompareStr"></seealso> </member> ... If your project/document architecture allows for separating layout (the way it looks), structure (classes, members, functions, types, etc) and content (help text per structure item), then "all you need" is a parser and some UI to manage the parts. Easy-peasy, when can I have it 🙂