Rollo62

@Minh Hoang The error 96/05/2022 10:20:30 is clearly not a valid date. But this format also might lead to the consideration if you are using the appropriate TFormatSettings for the conversion itself. Since "/ :" separators are used in US mainly, other countries might use different formats, for example in Germany the usual format is "dd.mm.yyyy hh:nn:ss". I think in asian countries you also might have the ". :" separators , which may lead to similar errors when not taking care about them. Suddenly a program running well in your country might crash in another country.

Why not upload via PAServer ? Have you tried to delete all apps with same name, or BundleId before ? It seems that you have an existing app, maybe due to Apple Configurator, thats why it cannot be re-loaded by PAServer ( a rough guess ).

Good point, but IMHO Skia is just in the early phase of rocketing launch into many projects. I would assume this may stay quite some time very active, the more people get aware of this nice library. Edit: References References References

Yes, thats true, but also my biggest concern. Google is lightyears ahead, and Embarcadero needs to follow Google, Apple, Microsoft, and whatsnot. This is clearly an unfair game 🙂 Thanks, I was not aware of that fact. That make is much more easy to just move to Skia, without too much rewrite of existing code. This makes is more easy to join and to use and improve it, you should make this fact more clear since this could ease the decisions. If it only would concern sourcecode, I would be relaxed, but since Skia also involved external libraries as a binary base, there is a lot more risk of using it. Easily it might break iOS, Macos, Android and even Windows, when running out of sync in new IDE, XCode, SDK versions or OS versions. Again, very good to know about the simple Skia on/off switch behaviour, so that I still can check FMX and Skia behaviour in parallel. You could not advertise this fact big enough

Thanks for the insights, this is what I expected too. There was a TScene "demo" from Eugene which pointed maybe in the same direction, this library I checked out some years ago, but never implemented into my current apps yet because the advantage was not so big for me. Maybe that could be more relevant with Skia now, or is this already obsolete technology ? If Skia is able to perform so well and stable, I will give it a try soon, probably beyond just testing. My biggest concern is if such system is resilient and production stable now, or rather might break in the next OS or IDE updates. I see you'r updating very eager, and it seems well supported, so thats a very good sign. FMX is not really stable for me, and tend to behave different in every version. If Skia is an approach to make FMX more stable, I'm jumping on that train very likely, but if Skia is adding another dimension of new failure modes, I will probably will make more tests.

@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 ?