

pcoder
Members-
Content Count
28 -
Joined
-
Last visited
Community Reputation
5 NeutralRecent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
alternative to call parameter?
pcoder posted a topic in Algorithms, Data Structures and Class Design
procedure TObj.run; var r: TRecord; begin ...; processRecord( r); ...; end; ProcessRecord is a method and contains many nested calls (more methods). The issue is that many methods would need an additional parameter (very cumbersome). Therefore an alternative is wanted. Object-field FR (PRecord) is a pointer (rather than record) to reduce memory outside of runs. is there any preference for one of them? procedure TObj.run2; begin new( FR); ...; processRecord; ...; dispose(FR); FR := nil; end; procedure TObj.run3; var r: TRecord; begin FR := @r; ...; processRecord; ...; FR := nil; end; -
Delphi winmd is not available to me (latest CE user), so I don't know, but I recommend to compare it with other winmd Pascal providers.
-
I don't see WinMD in Delphi CE GetIt Manager. Is this a known issue? The Service URL begins with getit12new.
-
Close enough for me, because a larger size would lead to more hassle, and MS is aware of this.
-
Essentially I need to copy/paste MIME formats as defined in urlMon.h and others. I've seen a few clipboard readers which use GlobalSize(handle) as file size. The alternative would be having a correct reader for all possible file types, just for finding the file size. I believe Microsoft is aware of these and other challenges and has corrected globalSize(), but I have no proof.
-
Here is an excerpt from linked oldNewThing: With mistake I mean, globalSize() would be much useless without giving the requested size (clipboard content size). And I just wanted to know if anyone of the forum members got a larger size than requested, because I don't.
-
Thank you, initially I thought the same (as stated in MS docs), but so far I could not confirm that GlobalSize() returns a larger size. Did you also read the given link to oldnewthing which contains "bonus chatter"? And I cannot believe that MS made such a mistake but has not corrected this. In my use case, the clipboard format, used in getClipboardData(format), refers to a MIME type (a file in memory). The clipboard reader needs to save each received stream to a file, which is easy if the file size is known. But interpreting every data format (more than 20 different MIME types) to find the correct file size is very cumbersome. I just hope that globalSize() returns the same as heapSize() If the clipboard is used for a MIME type (file (png, svg, ...)), then the file size is not stored additionally (because this would break the MIME format). therefore I need globalSize() to give the correct filesize.
-
Has anyone seen the case of globalSize() returning more than the requested size? It would be much more useful to get the requested size (<= allocated size) to determine the clipboard data size, but unfortunately I've found contradicting statements about globalSize(). Pro allocated size: learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalsize stackoverflow.com/questions/22075754/how-do-i-determine-clipboard-data-size Pro requested size: devblogs.microsoft.com/oldnewthing/20120316-00/?p=8083 www.labri.fr/perso/betrema/winnt/heapmm.html www.joelonsoftware.com/2001/11/20/a-hard-drill-makes-an-easy-battle/
-
BTW, have you also measured the impact of type? single (CVTTSS2SI) vs double (CVTTSD2SI) No need for numbers, just wondering about the average difference :)
-
Ah yes, the documentation. Someone else found this too:)
-
CVTSS2SI vs. CVTTSS2SI: CVTTSS2SI (truncation (rounding toward 0)) does not use/need MXCSR.
-
COLRv1 was just an info shown in the file properties dialog. The glyph rendering looks vector based and has color gradients, so SVG or COLRv1. Format-selection is for lower-level handling, but I use only RenderTarget.drawTextLayout() with D2D1_DRAW_TEXT_OPTIONS_ENABLE_COLOR_FONT. It would be useful here (also for end-users) if DirectWrite would offer a parameter to specify a preferred format. If possible I try to avoid lower-level handling, even more code according to the preview
-
Most common fonts are acceptable, but even "Noto Color Emoji" (2.038) can be very slow on certain systems. The file description displays COLRv1, but I don't know if DirectWrite actually uses this format.
-
Answering to myself: This is OK for (TDirect2DCanvas.RenderTarget.dpi = 96) only, ie (pixels = DIPs). dpi 96 (regardless of screen dpi and font.dpi) allows clients to pass pixel coordinates to all Direct2D-functions which want DIPs. This is GDI-compatible, so clients must provide final pixel values (dependent on screen (or other) DPI).
-
Yes, in most cases more than sufficient.