Andrea Raimondi

I do not necessarily agree with this. I agree on the fact that a record would work better for several reasons and that a generic list has a number of disadvantages; however, if the function is eventually going to have multiple values, then a typed list (i.e. a generic but with a concrete type) would probably work better. However, if changes are infrequent and/or the values must be easy to identify then a record is absolutely the way to go. I would never use a dynamic array because it's too easy to mis-identify things.

I would be very interested in something like this if there were clear demos and examples on how to use this properly. I would be especially interested in "working demos" such as UI pieces etc. I know you can do this with TMS and JavaScript or a host of other options (such as Smart Pascal or Quartex) but they all revolve around the very insecure NodeJS and I want nothing to do with that. So... something that doesn't use that would be welcome in my mind.

Hi! My opinion on the topic stems not from the use of the APIs but rather from being a regular target, in Europe, of dodgy-behaving companies. To understand the problem trying to be solved here, consider this: Oftentimes, when you visit a site in the EU, you get a popup saying "We care about your privacy!": those are indeed usually the worst offenders. What they will do is to comply where they must (for example offering a "Reject all" button on the screen) but you have to pay attention because if you peek into the legittimate interest you will see everything active. Therefore, by "saving" without looking into the legittimate interests, you will still be tracked just as before and the ads will reflect that (but with caution, because they're not stupid!). Yet there is more: if you then also go into the "Third Party" tab (where available) occasionally you will find some still active despite rejecting everything. This is the landscape Apple is unleashing the Tracking API in. This is why the descriptions are vague: because providers go out of their way to screw you over so they need wiggle room to nuke all of them from orbit. As for the idea that Apple aims at keeping the tracking data to itself: it's possible, but I am not sure that is the real goal. I think recent scandals have shown that robust tracking is detrimental to everyone and Apple buyers are, on the whole, higher worth people who have probably expressed an appetite for tracking-less phones and apps. It's still possible that they will track you and monetize that, but I think it's not necessarily true.

Hi! I don't know that any specific repo can be trusted when it comes to BTC etc. without intense static analysis be it Russian or not. Also keep in mind that GitHub itself has been subject to a mining attack whereby a pretend-NodeJS instance was available and executed which would perform crypto mining leveraging GitHub servers, so... kinda shady the whole thing whoever does it. But this library is developed in C# so static analysis is an option and I think there are several products that can do it. Static Analysis is your first line of defense, especially if you can establish "shady patterns" to look for. I am muchly more worried about situations where, say, the repo is on Russian/Chinese servers and with Internet-related laws that are questionable at least, if not downright awful. Static analysis is your friend, mate, use it!

Hello! Simple class: {$RTTI EXPLICIT METHODS( [vcPrivate,vcProtected, vcPublic,vcPublished] ) PROPERTIES( [vcPrivate,vcProtected, vcPublic,vcPublished] ) FIELDS ( [vcPrivate,vcProtected, vcPublic,vcPublished] )} TTestClass = class private FTestProperty: Integer; procedure DoSomething; function Test: Boolean; procedure SetTestProperty(const Value: Integer); public procedure DoSomethingPublic; property TestProperty : Integer read FTestProperty write SetTestProperty; end; Trying to access private members via this code: RTTIUtils.GetFields( AnObj, Fields ); Which is defined like so:: procedure TClassRTTIUtils.GetFields(AnObject: TObject; var Fields: TArray<TRttiField>); begin Fields := Ctx.GetType( AnObject ).GetFields; end; Ctx is a TRTTIContext (naturally, but worth mentioning). 10.4.2 raises an exception and I am not really sure why. I must be missing something obvious but can't see what. Are there odd project options I have to set? I have browsed through them but can't find anything that will make me go "here it is!". Thanks!

Oil&Gas, but oil more than gas, will be steadily declining in the coming years. I question the job viability in the long term.

Hi, Multithreaded applications - in my view - should be made with appropriate libraries such as OmniThread, because you reap all the benefits of multithreading while keeping (most of) your sanity 😄 The problem remains that if you send async messages in a multi-threaded application you very easily end up not knowing how that message came about in the first place because, you know, thread debugging sucks and not just in Delphi. Given that a message may be coming from a different threading context, things get wild very quickly.

I read that and I still disagree 😄 I like System.Messaging because it's synchronous and you need to plan the message flow. I am not saying that yours is a bad solution, all I am saying is that I like synchronous solutions such as Systerm.Messaging better on philosophical grounds. Async stuff is much harder to debug and will often not return enough on your investment to make up for the added difficulty in debugging and reasoning about things. I want to be able to follow things along so that I know that from Step A we go into Step B and not that Step XYZ gets in the middle without any apparent reason 😄

Why are you sharing this in that way? I don;'t understand the reasoning for it.

The other big advantage of this approach is maintenance: by doing this you only need to search for the message class and you will not miss any code and it's easier to pick up for newcomers to the project. This approach has all kinds of advantages that become clear as soon as you start using it. You can also split the code initiating the message from that which receives it so you can have different people working on the same feature from two different angles and if a message cuts across features everyone can just add a handler and be done with it. What happens to the handlers becomes a problem you don't have to deal with.

Hi, Yes it may be redone, probably, but it would go against the "current" of what that library is trying to accomplish and it would be unnaturally convoluted to do it. And yes, whenever I can, I write message driven apps. I find reasoning about message flows much easier than using events and such. I can also share code much more easily and because one of my rules is that "Messages often are features" that allows other people to reason about the flow and the behaviour in much easier to understand ways. The final advantage is that such architecture fosters statelessness which means you have much broader reach and need to pay attention to what you do 😄 The purpose there is not so much readability (which is part of it) but also consistency. I find lack of begin/end pairs in initialization/finalization very bad because you don't get the lines and you can't easily collapse them (please do give it a try: both work when you use begin/end). Moving things is also a lot easier for you could - for example - create a new InitYaddaYaddaYadda and just cut and paste the whole block. Finally, keep in mind that this is an example and chances are thart in my actual prologue/epilogue there mayt be a lot more stuff.

Hi! Personally, I like System.Messaging because it allows you to do things like this: unit Unit3; interface uses System.Messaging; Type TNofification = class( TMessage ) public class procedure Notify; end; TNotification<T> = class( TMessage<T> ) public class procedure Notify(Value: T); end; var MsgMgr : TMessageManager; implementation { TNofification } class procedure TNofification.Notify; begin MsgMgr.SendMessage( nil, Self.Create ); end; { TNotification<T> } class procedure TNotification<T>.Notify(Value: T); begin MsgMgr.SendMessage( nil, Self.Create( Value ) ); end; initialization begin MsgMgr := TMessageManager.DefaultManager; end; end. Now what you can do here is subclass the right notification and simply use it: unit Unit3; interface uses System.Messaging; Type TNofification = class( TMessage ) public class procedure Notify; end; TNotification<T> = class( TMessage<T> ) public class procedure Notify(Value: T); end; TNotifyLoggedUsers = class( TNotification<integer> ) public class procedure NotifyNumberOfLoggedUsers( Value : Integer ); end; var MsgMgr : TMessageManager; implementation { TNofification } class procedure TNofification.Notify; begin MsgMgr.SendMessage( nil, Self.Create ); end; { TNotification<T> } class procedure TNotification<T>.Notify(Value: T); begin MsgMgr.SendMessage( nil, Self.Create( Value ) ); end; { TNotifyLoggedUsers } class procedure TNotifyLoggedUsers.NotifyNumberOfLoggedUsers(Value: Integer); begin Notify( Value ); end; initialization begin MsgMgr := TMessageManager.DefaultManager; end; end. Now what you can do is to call NotifyLoggedUsers directly in a way such as: begin TNotifyLoggedUsers.NotifyNumberOfLoggedUsers(Users.Count); end; This is *very* interesting, powerful and readable. The other big plus is that being synchronous it allows you to reason easily about message flows and you can build up programming documentation using diagrams that can be used and understood by sales and other parties as well.

Hi! As far as I know, those properties deal with different monitor sizes. Suppose that you're developing on a 1024x768 monitor, then a new colleague comes on board who's on a 1900xyaddayaddayadda. That's where the explicit properties kick in: now they are set because the monitor has a different resolution and if any changes in size are made to adjust for this, then the explicit properties will follow along. It's basically a way to have usable forms and data modules both at design and runtime for both developers and customers. . But that's my understanding and I may be wrong.

Hi! I know the code from Jim to open URLs, for example, but I am more looking for something like ShellExecute on Windows but cross platform. Any ideas? Thanks!

I had a gander and I think the whole thing is very confusing: for example. why does the Pro extend the Enterprise license? It makes no sense to me. It's just all weird.