Anders Melander

In case anyone else wonder what to specify for the Development Environment, we have to type in "Delphi", "C++ Builder" or "RAD Studio" (RStudio is something else).

Regardless of how it affects the instance ownership, if the Form has Position=poOwnerFormCenter then the Owner should be specified Otherwise it will fall back to poMainFormCenter.

You probably read it here: https://wiert.me/2017/08/02/delphi-call-stack-from-exception/

Potato, Phothatho

Download source: 1 minute. Browse through source: 3 minutes Write wise-ass response here: 15 seconds. As far as I can tell there are no 3rd party dependencies, it's VCL and Delphi Pro should be sufficient. The project files (dpr, dproj) seems to be missing though so good luck building it...

Did you read this pinned topic:

No. As Stefan pointed out, if AMin is smaller than AValue... IsInRangeEx(0, 1, 2); ...you will get an Integer Overflow.

... can cause overflows. Consider the extremes.

TForm.SetFocus maybe. Otherwise I would think TForm.Show would activate the form - regardless of it being already visible.

Are you talking about the character set used to display the text or do you mean that English text should be magically translated to Russian while the user is typing?

Voted. I've been using the following work around in the dpr file for ages: if (CheckWin32Version(6, 0)) then // Application.DefaultFont is the font used when TForm.ParentFont=True. // It is Tahoma by default but should be Segoe UI on Vista and later (according to MS UI guide lines). // See InitDefFontData() in graphics.pas Application.DefaultFont.Assign(Screen.MessageFont); And I have ParentFont=True on all forms.

As I briefly mentioned yesterday I've released v1.2.7797 of Better Translation Manager: Changes since previous release v1.1.7465: Import translations from CSV and other delimited text formats. Small reduction in resource module size (1.2 Kb). Added check for out of date DRC files. Machine translation using Microsoft Terminology Service now works again. A bunch of minor bug fixes. Get it while it's hot: Installer: http://melander.dk/download/amTranslationManagerInstall-1.2.7797.22083.exe Source: https://bitbucket.org/anders_melander/better-translation-manager The CSV import:

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?