Anders Melander

This has been resolved in the build (v1.2.7797.22083) I've just uploaded. http://melander.dk/download/amTranslationManagerInstall-1.2.7797.22083.exe I chose to implement the full solution. I.e. import of any CSV format, not just the format BTM produces.

Thanks. Ballpark numbers are fine. Much appreciated. I just wanted to get an impression of what impact using this might have. 2-10 times slower for DD is much better than what I expected. That said, I can see that multiplication is one if the slower operations. That surprises me but I guess it must be because native multiplication is highly optimized in hardware.

Some benchmarks comparing the performance of the DD and QD types to the native Single and Double types would be appreciated, if you have them. I've searched for performance numbers on the QD C++ library but couldn't find any relevant ones. The pdf contains some numbers but they are very old (Pentium II) and quite meaningless since the only comparison made is to the MPFUN Fortran library. Also the QD page you link to state that the C++ library isn't thread safe. Is the same true for your implementation?

Just as random, almost as cool, and has a slightly smaller risk of invoking a visit from Homeland Security: https://www.orau.org/ptp/collection/consumer products/dudice.htm A dice made of depleted uranium 🙂 Anyway, it is possible to get USB-sized true randomness, just without the coolness factor. For example: https://www.amazon.com/TrueRNG-V3-Hardware-Random-Generator/dp/B01KR2JHTA/ref=pd_sbs_1

Since we're now in full bike-shed mode here's my contribution: https://hackaday.io/project/4628-nuclear-random-number-generator A random number generator based on radioactive decay.

Yes, there is that. Definitely. When it's bad I usually have to convert the inline vars back to traditional local vars while debugging a difficult problem and then back again when I'm done. Not ideal to say the least but it's not enough to have me give up the convenience and improved readability of inline vars. I never use the formatter and I don't believe any of my colleagues use it either. I can't see why we would. We very seldom use the rename refactoring (mostly because it's unreliable). You apparently have a different workflow. Nothing wrong with that. The feature is there so of course it should work.

Sounds like that code formatter is really important to you.

Yes it is, but if you can't define what "better quality" is then your request is meaningless. In any case, like David said, a web search should give you plenty of candidates. Did you try that first?

If I may provide some constructive critique I think you should update your toolbar & dialog icons to match the UI style of the rest of application. Those 3D glyphs look really out of place and it's clear that they come from different icons sets: Flat, 2D/3D, shadow/no shadow. Also: Cancel button goes on the right on Windows

A guess :

Yes, I understood that but if you're concerned about not wasting resources, as you state, then there's no reason to refresh more often than what the monitor can handle.

Okay, that makes better sense. Instead of updating at a fixed 120 Hz I think you'll want to sync your refresh to the monitors vertical retrace. I don't know how to do that but I found this: http://masm32.com/board/index.php?topic=4410.0

If a regular WM_PAINT handler will not update fast enough I can't see how a timer controlled paint will. What am I missing?

You want to update the screen 120 times per second? Why on earth would you want to do that?

Or the one-liner: TRegEx.IsMatch(FUrl, sUrlRegEx, [roIgnoreCase, roIgnorePatternSpace])