Anders Melander

Doesn't TGIFImage (the non-visual part) work with FireMonkey?

Makes sense then. The learning curve is ...um... spectacular 🙂

So what do you use for grids, pivots, toolbars, etc?

🤔

Yes. Unless you have a reason to specify an explicit owner, you should actually specify nil to make it clear (when reading the code) that there is no owner. No. You can specify that a "child form" should be centered on the owner form (Position=poOwnerFormCenter), but it's still safe to specify nil as the owner. You're mistaken. There must have been something else going on. It's the same for all classes derived from TComponent; When a component is free'd it will free all the components it owns. TComponent is a base class of TForm.

This should get you started: https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi/tree/master/Demos/VirtualFileStream

IMO that's a bug since the two interfaces are distinct. I don't have time to investigate if the problem exists in newer versions right now.

Yes, exactly. I just wanted to be sure that you were aware of this. Many people misunderstand what interface inheritance is. I still can't follow your example but from your description it does sound like there's a bug. Since you're not doing any hard type casts the compiler should see the problem (whatever it is) and not produce code that leads to an AV.

I can't really follow your example but I noticed that you haven't assigned IFooBroker a GUID. Is that by design? Also, are you aware that inheriting one interface from another is just a convenience that copies the declaration from the base interface into the derived interface. There's no "interface polymorphism".

You do know that you don't speak for everyone, right?

IMO you're bound to get into trouble with that design - it's very fragile. Firstly you're mixing object and interface references. If you stuck with interfaces, dropped [weak] and used some other mechanism to flag that the object was no longer valid (e.g. a lock protected flag on the object), then it would be fine. Secondly since you're using [weak] there are limits on what you can safely do with the interface reference. For example supports/queryinterface can't be used on it.

How would the pre-commit hook distinguish my manual changes from the automatic changes made by the IDE?

If you create the graph in code instead of placing it on the form then the IDE will not try to add those units to the uses list.

It would be stellar if we had a switch that could disable this behavior completely. I'm sick and tired of cleaning up the uses clause before commit, every time I have had a form open in the IDE during debug. Particularly since DevExpress keeps adding stupid dependencies between their units which causes the uses list to grow and grow for no good reason.

That's not how you use coInitialize/coUninitialize. First of all check the return value of coInitialize and don't call coUnititialize unless the return status indicated that it succeeded. Read the documentation. And don't call coUninitialize until you are sure that everything using the thread apartment is done with it. Since you're doing this in the main thread and you don't know what else is using it you are best of doing it just before the final end. Normally this is something that would be done in the initialization and finalization sections of a unit. Finally, use coInitializeEx instead.

If the logic that does the HTTP request, extract the HTML and scrapes the HTML are all nicely separated then I don't see why you'd need a mock (personally I try to avoid them as they just become one more piece of code to maintain). For example if your scraper reads from a stream, then just have the unit test pass it a TFileStream and Bob's your uncle/aunt/non-binary auncle.

Or if earlier versions are to be supported: $IFDEF CONDITIONALEXPRESSIONS} {$IF CompilerVersion >= 14.0} Variants, {$IFEND} {$ENDIF} If not, then Variants might just as well be moved outside the conditional.

It's in the documentation... So probably not 🙂

There's DynArrayUnique but it's undocumented and not really fit for direct use: procedure DynArrayUnique(var A: Pointer; typeInfo: Pointer); begin if (A <> nil) and (PDynArrayRec(PByte(A) - SizeOf(TDynArrayRec))^.RefCnt > 1) then DynArrayCopy(A, A, typeInfo); end;

A simple "yes" would have been enough 🙂

Read what I wrote again.

I still don't get it. Just start with the assignment and use B:= Copy(B) when you need it to be unique.... Ah, I think I get it now. You don't want to keep track of the arrays reference count. So it's like UniqueString for dynamic arrays? Does nothing if the reference count is already 1, otherwise makes a unique copy. Right?

B := A makes them the same array. SetLength just makes B unique (and contains an implicit copy). I don't get what advantage assignment followed by SetLength gives you over a simple Copy. With Copy the intent is explicit.

I like this quote from Graig (in the comments): Wise words.

Because the implementation wasn't designed to handle it. IMO there are better solutions. Docking for example (just not the VCL's docking - it's broken beyond repair).