Vandrovnik

If you use "normal" databases liky MySQL, Firebird etc., network administrators should be familier with them and can backup them, restore, move to another server etc. - form the point of view of a network administrator, this is much better than having to work with something unknown.

Shall I translate it for myself as "Give us your money for new versions (you can pay for 1, 2 or even 3 years), but we will not tell you what you get for your money."?

Hmm, in my environment, all prior versions had more problems than 11.2. (Well, not all - Delphi 6 was fine 🙂 ). I do not know if it could matter, but I always put DCU directory for my projects to RAM disk, so each day after power on (I do not use hibernation), IDE starts without any old .dcus. I have noticed, that often, when I make change in "interface" section of a unit (for example, add "Test: integer;" to public section of a class) and try to compile project, IDE complains with "[dcc32 Fatal Error] oKos.pas(43): F2084 Internal Error: AV11CD26DE(11C60000)-R000004F8-0" in another unit (that unit depends on unit where I made the change). May be the same internal error occurs in LSP and causes the trouble... Build works fine.

Killing LSP should be enough: https://www.delphipraxis.net/1512626-post2.html

OK, did not check 🙂 Just wondering, why previous record, too?

Which error? May be it cannot work together with filtering... But you should be able to do filtering using SQL query and than use Unidirectional.

For Firebird, I use IBX component, which have "Unidirectional" property. When set to True, only current record is kept in memory. Maybe your database components have similar functionality?

This is in Winapi.Windows.pas: type PMemoryBasicInformation = ^TMemoryBasicInformation; _MEMORY_BASIC_INFORMATION = record BaseAddress : Pointer; AllocationBase : Pointer; AllocationProtect : DWORD; RegionSize : SIZE_T; State : DWORD; Protect : DWORD; Type_9 : DWORD; end; {$EXTERNALSYM _MEMORY_BASIC_INFORMATION} TMemoryBasicInformation = _MEMORY_BASIC_INFORMATION; MEMORY_BASIC_INFORMATION = _MEMORY_BASIC_INFORMATION; MemInfo is just a local variable in System.SysUtils, function GetExceptionObject.

Has someone created it on QP, so that we can vote? Probably with link to https://en.wikipedia.org/wiki/Binary_search_algorithm#Procedure_for_finding_the_leftmost_element Everyone usually needs better version immediatelly, while waiting for the fix can take... ehm... few years?

It is a black square: https://www.fileformat.info/info/unicode/char/2bc0/index.htm 11200 decimal, not 11200 hex.

If you use type "currency" instead of "double", it would work too and you can avoid most of the conversions between numerical and string types. Currency can keep 4 decimal places (even the 0.1 🙂 ).

Hello, This is not error, this is how floating point numbers work... In binary, you cannot represent exactly 0.1.

I always cross my fingers before using refactoring (renaming)... And it sometimes works 🙂 Sometimes it even does rename the identifier at all places and does not forget some of them...

Do you also have this? {$IFDEF DEBUG} System.ReportMemoryLeaksOnShutdown:=true; {$ENDIF}

... and it tooks quite a lot of time to initialize. "Search for usages" also does just partial job when you doubleclick found item - it display the file, it selects found item, but cursor is off-screen, sou you have to press for exampe an arrow to see that place.

Could you manually delete the target file and try again? Or try to suspend antivirus software?

And what happens when you close the Local Variables window?

Hello, I have noticed that in PDF exported using SynPdf, colors in PDF do not match original colors. I have created a test application, which displays colors on screen and allows to export them to PDF using SynPdf and using FastReport. Colors should be the same, but are not (RGB of the left bottom square should be 191, 0, 255, but is 223, 0, 255 using SynPdf). Is there something wrong in my export procedure, or is it a bug in SynPdf? Kind regards, Karel PdfColors-source.zip TestSynPdf.pdf TestFastReport.pdf

I believe PDF from SynPDF is PDFA-1A, too. In source, I have: lPdf.PDFA1 := true; And Reader says: In the .pdf file, there IS a color profile included, and it seems that this profile is the source of the problem. When I made SynPdf to include another color profile (sRGB Color Space Profile.icm), colors are OK.

It seems Fastreport is using this color profile: C:\Windows\System32\spool\drivers\color\sRGB Color Space Profile.icm

There is an ICC profile included in the PDF. I extracted ICC from Fastreport's PDF, put it in SynPdf, created new export - and colors are OK (or at least "almost OK" - expected value 255, displayed value 254).

I have created and atteched another output using SynPdf - now I enforced JPG compression of the bitmap, so that it also uses filter DCTDecode. Problem remains, colors do not match. TestSynPdf-jpg.pdf

Hmm, I forget to put pf24bit back and left pf32bit in the app, but the result is the same with pf24bit and pf32bit.

I do compare both - SynPdf x original bitmap and SynPdf x Fastreport. Later I tried to open the PDF in another tools (online PDF viewers, MS Edge, Libre Office) and there are colors from TestSynPdf.pdf OK. So may be it is just a bug in Adobe Acrobat Reader?

This will not work with connection string for embedded Firebird.