Rollo62

@vfbb Great, getting better with every build Could you please clarify some basic internals, since I haven't looked into this too much ? FMX has the drawback that it repaints the whole screen, even when only a small fraction of the screen has changed. How is the screen painting handled in Skia controls ? Is the control handled by Skia external library, or does it still behave like the original FMX ? Maybe Skia completely replaced the FMX rendering engine, and is optimized after that for the whole FMX controls, or the Skia rendering engine is used for their controls only, which leads to optimized drawing performance only for these controls, or Skia can not optimize the general FMX behaviour, but it can optimize within FMX's limits.

Have you tried this player, using VLC ? Worked fine for me in an older project, have not checked that with current IDE's. https://prog.olsztyn.pl/paslibvlc/

Bittesehr, you're welcome

Ok, in that case maybe this can be helpful, but its not a complete Delphi solution yet, you have to look into the sources.

Why ? If you want to igore a key you could abort operation, and also do other oprtation. Do you want to determine where the key is sended from, to do differentiate operations depending on sended from hardware or virtual keyboard ?

I have no external keyboard, how does it behave differently ? Isn't it catched by the normal TEdits OnKeyDown, OnKeyUp or OnChangeTracking in same way as should with the virtual keyboard ?

Yes development should be possible, but you should be aware that more modern iPhones might have Notch, no Button anymore and different display sizes with certain "no-go areas" when showing portrait or landscape. Not sure how SE compares against the never, but its looks definitvely like the older ones, where it was much easier ( good old days .... ).

Right, the demos from lottiefiles.com are great, but I need to tweak them a little. One hope is maybe InkScape https://inkscape.org/de/~mattia.basaglia/★tgslottie-importexport https://lottiefiles.com/animation/inkscape But that seems very gamma/beta still, but I will try to get this running.

Yes, but it seems that Adobe After Effects is the only tool which is able to create serious animations, while no other competitors or free tool exists so far, that could reach that quality. That is a little strange I think, since Lottie is not that complex and widely used, I would have expected many other tools in the market. I personally dislike Adobe tools, thats why I look for an alternative.

@vfbb Great library, thanks for that. Especially the Lottie support I find very interesting. Yesterday I was checking some Lottie tools, and I must find out that there is no real simple Lottie editor, beside Adobe After Effects. Do you have the same experience, or could you recommend some simple animation tools ?

----

Hi there, sorry for the exiting question above, but this article leads me to this question, what is grumbling deep in my guts for quite some time now. There are some fractions of people, also in other languages, that think properties are superfluous. Not that I am thinking like that, but I really would like to point out the special usefulness, and to ask the language experts what the advantages of properties really are. Properties: Advantages - prettiness, looks nice and clean in the caller (not so much in the called ) - Shorter names - Can be assigned to - Can be used in boolean operations, without the brackets () - Can be used on fields directly, without getter/setter ( this is their biggest advantage, IMHO ) - Encapsules internal implementation, by a well defined interface ( this is no advantage, it is true for every method too ) Properties: Disadvantages - More overhead to maintain the property - Changing names, needs changing in 3 places - Separates getter/setter (private) and property (public) into different sections of the class interface position, must jump there to edit - Cannot be used in nested calls, for setting all, like FMyOne.DoOne( FMyTwo.DoTwo( FMyThree.DoThree( True ) ) ); ( OK, this also not works with separated setter/getter, but I could do that ) While properties cannot FMyOne.One := FMyTwo.Two := FMyThree.Three := True; ( which could be the only real advantage of properties, IMHO ) - Encapsulates internal implementation, by a well defined interface ( same true, as above ) - When used in Interfaces, I also must define setter/getter, so no advantage over functions, by saving setter/getter - When used in Interfaces, I cannot use them with pure fields, but I'm forced to define setter/getter ( this could be a second advantage of properties, IMHO, if that could be possible ) Is there something I overlook here ? To me it seems there is no real technical argument that speaks pro properties at all, beside their "prettiness", am I right ? I hope you can show me situations where I really need them, or where they have huge performance advantages.

I'm not beeing lazy, I use them heavily, even I rarely use them with public fields alone, but initially gave them getter/setter ( so I'm overdoing more often than I should ). The question was: Are they worth the efford, how exactly do they make code better ? From above arguments I'm already convinced, and my gut feeling gets more towards seeing their advantages. Agree to all your points, beside that. What I really dislike is when mixing both concepts, that is ugly to me, not beatiful. FThing.Enable := True; FThing.Execute( 1 ); //vs FThing.Enable( True ); FThing.Execute( 1 ); I would say the latter is better readable, but we could argue the whole night about that But your discussions brought two real advantages to my mind: - Performance by using direct field access vs. function calls - When published, can be used in Designers, which would be nit possible by get/set that elegant Good point too ... I think I have to update my list Properties: Advantages - prettiness, looks nice and clean in the caller (not so much in the called ) - Shorter names - Can be assigned to - Can be used in boolean operations, without the brackets () - Can be used on fields directly, without getter/setter ( this is their biggest advantage, IMHO ) - Can have better performance with private field access - Can be used as published properties, in designers - Supports indexes - Supports array-style access - Have good RTTI support - Supports decorations/attributes - Encapsules internal implementation, by a well defined interface ( this is no advantage, it is true for every method too ) Properties: Disadvantages - More overhead to maintain the property - Changing names, needs changing in 3 places - Separates getter/setter (private) and property (public) into different sections of the class interface position, must jump there to edit - Cannot be used in nested calls, for setting all, like FMyOne.DoOne( FMyTwo.DoTwo( FMyThree.DoThree( True ) ) ); ( OK, this also not works with separated setter/getter, but I could do that ) While properties cannot FMyOne.One := FMyTwo.Two := FMyThree.Three := True; ( which could be the only real advantage of properties, IMHO ) - Encapsulates internal implementation, by a well defined interface ( same true, as above ) - When used in Interfaces, I also must define setter/getter, so no advantage over functions, by saving setter/getter - When used in Interfaces, I cannot use them with pure fields, but I'm forced to define setter/getter ( this could be a second advantage of properties, IMHO, if that could be possible ) Well that are enough good arguments on the PRO side for me, thanks for pointing that out. Its worth the efford to use them, my daily workflow doesn't need to be corrected.

Related to your title "A better way to share global data structures than as global variables?", Not sure if always "better", but for sure an "other" way: I like to "share" global data by TMessage sometimes, which could completely decouple separate units. You only have to initialize a "global" module, sunscribing to its message, and then you can request global (or non-global) data by messaging from everywhere you want. You can implement thread-safetyness, imutability as you like.

Thanks for clarification, I hadn't recognized from your article that this feature is D5 compatible, sounded D11 related to me, and it looked a little alien to me anyway and ringing my alarm bells Much better that this pattern has such a long history, I was not using D5, but BCB5 at those days, so I'm still learning new features every day.

Very interesting article, I love C++ Delphi Especially the use case samples are great, where I think this could make it possible to be used in a nested way, what I consider for some time. Something like that: var Builder := THtmlStringBuilder.Create; Builder .Html .Header.Enter .Header.Text( 'In header' ) .Header.Leave .Div.Enter .Div.Id( 'main' ) .Div.Color( clYellow ) .Div.Text( 'In div' ) .Div.Leave .Footer.Enter .Footer.Text( 'In footer' ) .Footer.Leave ; WriteLn(Builder.Data); I think that should be possible and should make sense too, I have to check that. What I'm a little unsure is, how stable and reliable this "self reference trick" is tested under different Delphi versions. Can-I-Use it without any unexpected quirks, or do I better wait and see if this is still running in the next version(s) ?

Sorry for giving you totally wrong and off-topic hints. I thought you wanted to work with huge amount of REST queries, maybe with lots of unneccessary data to download as well, where GraphQL as server interface could help to optimize requests paths and download sizes.

Consider GraphQL, which is more effective than REST.

You mean libraries like this ? There you can add custom libraries, bei right click the Android32/64 Node and add them to the list.

Tl;Dr; Like that ?

Interesting, need more consideration where/how to use that ... 🤔

Hi there, I have a general question regarding this topic. There is a lot information out there, even in the DocWiki. https://blogs.embarcadero.com/what-are-the-mistakes-we-made-in-creating-delphi-objects/ https://sergworks.wordpress.com/2015/01/21/think-twice-before-raising-exception-in-constructor/ https://stackoverflow.com/questions/39110021/delphi-raise-exception-in-constructor To summarize: It is perfectly fine to raise an exception in a class constructor ( and in some cases its even not avoidable, I assume ). My question is: Shall and raise an exception on purpose, and if so, what strategy is best ? In a normal situation, this is completely OK. LA := TRaiseOnMinus.Create( -2 ); //<== Raise try //some code finally LA.Free; //<== Never called end; But like that it causes issues: try LA := TRaiseOnMinus.Create( -2 ); //<== Raise //some code finally LA.Free; //<== Will be called on an unconstructed object end; But there is the pattern of encapsuling multiple try - finally's How shall I handle that ? LA := nil; LB := nil; try LA := TRaiseOnMinus.Create( AInputA ); //<== PossibleRaise try LB := TRaiseOnMinus.Create( AInputB ); //<== Possible Raise finally LB.Free; end; finally LA.Free; end; Either I can guarantee that NO Exception can be raised ( can I guarantee that really ) ? Or maybe guarding the Free might help, but I doubt that. LA := nil; LB := nil; try LA := TRaiseOnMinus.Create( AInputA ); //<== PossibleRaise try LB := TRaiseOnMinus.Create( AInputB ); //<== Possible Raise finally if Assigned( LB ) then LB.Free; end; finally if Assigned( LA ) then LA.Free; end; Are there any recommendations or best practices, about using Exceptions in class constructors ( Shall I use them, or not ) ? I see the problem that the caller never knows if Create might be able to throw an exeption, so he must be analysing the internals of the TRaisedOnMinus class first. Beside that, there could be the possibility to prevent any damage from inside the class, by guarding internals, to ensure that double-calling Free doesn't do any damage. Only I'm afraid that this guarding inside Destroy is bad practice too ( but I like double-safetly measures anyway ). constructor TRaiseOnMinus.Create( AParam : Integer ); begin inherited; FMyList := nil; if AParam < 0 then raise Exception.Create( 'Bum' ); FMyList := TStringList.Create; end; destructor TRaiseOnMinus.Destroy; begin if Assigned( FMyList ) then FMyList.Free; inherited; end; How do you design classes with exceptions ?

... and there we are again with Uwe's Initialize and my Conf_Setup_ scheme ... I like that approach too, because of the clear separation, but its hard to say where I should use that or better constructor parameters. Maybe the experienced developer has always the right answer, but not me, I usually try and rework my classes many many times, until I find a stable, acceptable final design. Would be great to have some rules in what situations such separation makes sense, you gave already a good hint to that. I like to use the Conf_Setup scheme in combination with the fluent interface, which makes class creation, or class builder, more nice and well readable. begin LMyObj := TMyObj.Create {} .Conf_Setup_Begin {} .Conf_Setup_Color( clBlue ) {} .Conf_Setup_Events( EvOnChange ) ... {} .Conf_Setup_End {} ; end; Most of the time I use class functions in those "Builders", which encapsulates class creation within the class itself. Another step of separation creation and initialization within the "Builder".

That external parameter is not in the domain of the class, so I have to take care outside, to keep everything clean. Or do you mean issues with some kind of delayed access, in anonymous procs, events or threads ? When the object might be released, while the event proc might still try to touch it. I think this could has to be guarded by other means, its not related to the constructor exceptions. I would not need Guards on every internal operation, to ensure all parameters are OK. I would hardly see any strange sideeffects later on, when an invalid parameter causes issues only under rare conditions, the creation fails gracefully immediately before that happens.

Right, I'm also wondering how such a "simple" question touches so many basic language concepts. But to clarify the original question again: It was not about if raising exception in Create is possible and how to do that and catch it, the question was: "Shall I raise exceptions on purpose, or better not". Yes, this is exactly what I am looking for, especially here I should raise exceptions if something is wrong with these parameters. Thanks to all, who brought so many different aspects into this discussion. I came already to the conclusion: Raising on purpose in Create() is fine, especially to guard against missing or faulty injected parameters. Everything else is just an intermediate state to the final, perfect design, but there is no real reason to keep such intermediates. ( only I'm not so sure if I am ready to "finalize" all my classes in time )