Anders Melander

Shouldn't that be "that can be consumed and used in a tool instantly"...? or do you know of something other than ANTLR that consumes the ANTLR grammar?

Exactly - and you don't need to be an expert to come to that conclusion.

No. It's regular BNF. You can tell by the use of <> brackets and :== Here's a comparison: https://en.wikipedia.org/wiki/Syntax_diagram#Example

Me too . Bought at 6, sold half at 12 and then got out as it passed 8 on the way down. It never recovered after that. Although I did make a bit of money on it that was soured by the fact that they burned the company and its reputation to the ground.

Okay. "var pps: pointer" matches the documented API (so it's correct) but if you want to use an out parameter instead then the correct declaration would be: function SHGetPropertyStoreForWindow(hwnd: HWND; const riid: TGUID; out ppv): HResult; stdcall; because ppv is documented as: which means that it can return another interface if you request that. Note the untyped out parameter, like QueryInterface. Because the parameter is untyped it is your responsibility to pass a var declared as the interface you're requesting. The compiler will not stop you passing in something that doesn't make sense: var Nonsense: IMomsSpaghetti; begin SHGetPropertyStoreForWindow(Handle, IPropertyStore, Nonsense); Nonsense.Vomit; // Boom! end; What is the actual problem you're experiencing, by the way?

I'm not sure I fully understand your explanation. Anyway, now that I think of it you should get rid of both the _AddRef and _Release. The interface being returned by SHGetPropertyStoreForWindow will have a ref count of 1. Your pointer() hard cast ensures that it stays at 1 even though you are storing the reference in a Delphi interface var. When this reference goes out of scope the reference count should become 0. I'm not sure what change you're referencing here. I don't know what the Pascal declaration of SHGetPropertyStoreForWindow looks like but in this case it doesn't really make a difference if ppv is declared as a pointer pointer, an interface or pointer var or out parameter. The semantics are different but the result is the same. I believe the semantics of out best describe what's actually going on here (return of a value with disregard for the current value of the passed var). Look at the declaration (and implementation) of QueryInterface in classes.pas for another way to declare an out parameter returning an arbitrary interface.

Didn't you read the wikipedia link on Backus-Naur format? There are a few online tools that generates railroad diagrams from EBNF (https://www.bottlecaps.de/rr/ui is probably the best known) but I know of none that operate on BNF. I actually don't think the original BNF is much used outside old textbooks.

Get rid of the _Release. It's already called implicitly when the interface reference goes out of scope.

Because TThread is a lot older than TTask. TThread is just a semi-thin low level wrapper around a windows thread. TTask has a much higher abstraction level and uses TThread internally (via the thread pool). You have the source code for both so go ahead and have a peek.

The first question you need to ask yourself when trying manipulate thread scheduling is: Am I smarter than the people that designed the OS thread scheduler? If you can answer yes to that then go ahead and use SetThreadAffinityMask on your threads but I doubt you'll get the improvement you think. The two threads will still have to compete with all the other threads running on the system (and there's thousands of them) but now the scheduler can't move them to another core if their designated core is occupied. All you've achieved is to give your threads a handicap.

How can you tell? I'm impressed if you managed to make any sense of it 🙂

Yes, okay. Consider it emphasized - again.

Yes. What's your point?

Every Delphi application that contains a form (or frame or datamodule) does it. That's how components and controls gets created when the form is streamed in from the DFM resource. See TReader.GetFieldClass and TReader.ReadComponent

I've just skimmed through that and it seems to me that your suggestion to use THandleStream is incorrect; I don't believe FileRead can be used on a resource handle. Apart from that I would advise against on-the-fly runtime change of resource module. There are simply too many things that doesn't work with it and the users doesn't really care about it either.

Well, the answer to his question is "yes" but since we don't really know what problem he's trying to solve it's hard to tell... 🙂

You don't need a plugin to receive items dragged from outlook. You just need to handle the correct clipboard format and any decent drag/drop library can do that for you. https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi

Pfft! Maybe you should hire an HR or Public Relations person instead.

No, I think that's about it.

Can you explain why you need to know when a drag is initiated? It's a rather unusual requirement.

You can probably use the D11 package source files from the latest revision and the other source files from the graphics32-1-9-1-fixes-r2148 revision. Make a copy of the D11 package source files (and GR32_Compiler.inc) and then revert to the revision that worked with XE2. Then copy the package source files back and rebuild the design and run time packages.

I don't think that will make a difference. The package source files just contains the references to the GR32 source files and those are the same between the different packages.

I meant the Windows search path. Look for the run-time package: GR32_RD110.bpl I think someone that knows C++ Builder will have to help you with this. It seems there's a problem with passing a string literal as a parameter but I have no clue about what to do about it.

How?

Hmmm. Could it be that you have two different versions of the Graphics32 run-time package in your path? Using the debugger, are you able to step into the call to Image321->Bitmap->LoadFromFile ?