Rollo62

30 what, days I've got 8 days now, never took so long before. And this time they want even changes

I like to speak a word for System.Messaging, which I extended to some kind of thread safety too. This seems a good base for me, and works very stable in main UI and threads also, if you took the right measures to secure it. To use System.Messaging as a base makes sense to me, because its a System unit and also the FMX messaging system is build on top of this, thats why I assume is has to be well tested and maintained. Nonetheless I like to see new libraries, which can do it much better too.

To add another solution, I have used this here., from Zacherl in the German DP, and separated this into separate 32- and 64-Bit units, and reworked a little. So far I have not yet worked with 64-Bit, so I cannot say its working there, or not. But I remember I put this into some unit tests, and was OK, I'm not sure ....

The links are already some years old, while background and permissions is a moving target on mobile. Maybe you should check out the latest Kastri repo, from Dave Nottage, which is IMHO most up-to-date.

@Felix Berto Castillo G. Thanks for the link. How got you rid of this warning, by increasing the API level to 29 ? What if I don't want to increase that, have you tried the 2nd option ? Where do I get a " ReTrace mapping file" for an FMX app ? Is there maybe a minimal or empty file that I could include in the deployment to get rid of that warning ? Some more links: http://buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } https://blog.mindorks.com/applying-proguard-in-an-android-application https://medium.com/@sagar.s.rao/d-obfuscating-google-play-store-crashes-logs-android-5b0a3c50da95 https://stackoverrun.com/de/q/10664775 https://www.codegrepper.com/code-examples/delphi/How+to+create+a+proguard+file+in+android+studio+flutter https://forum.unity.com/threads/need-help-with-2-warnings-on-the-google-play-console.923267/

Hug the trees

Well, than I have to look into OrangeUI soon

Great, that looks awesome. I think you draw your scene by yourself at low level, or you use a kind of game engine. From my tests unfortunately I got crashes right away, had no time to discover deeper yet. I'm afraid this is because I use FMX controls, also with some kind of animations active, but nothing very sspecial. My guess is, that there were some differences in handling those animations. Again I think I have to rebuild a test app from ground up, to check that behaviour.

procedure Tform.OnGeocodeReverseEvent(const Address: TCivicAddress); begin end; You should consider that this event is triggered by separate hardware, and it may or may not occur in the mai UI thread. I would decouple the results, and use TThread.ForceQueue to ensure that main UI is vaild.

Whats the purpose of copying bitmap to a (linear) stream ? This sounds as its for saving to disk.

Hi there, I'm wondering if there are any general tests available, which were testing all kind of Delphis basic behaviour, from very basic (like basic data types size, behaviour, etc. ), to more complex classes tests (like JSON, DateTime, etc.) to some specific failue tests (like RSP12345, ...). The goal is to fastly find differences between different Delphi versions, different behaviours of the basic classes, behaviour of workarounds and fixes in different versions. I'm afraid that many people have written their very special tests, for special cases, but wouldn't it be interesting to have many general, Delphi-related tests too ? Maybe something like that is already there, at Github or elsewhere, something like the curated list for Unit-Tests, or even better: already a complete Delphi-Test.

@Anders Melander I recently saw this post from you, as a maintainer of the wonderful Graphics32 libary. https://en.delphipraxis.net/topic/4140-smooth-scaling-of-bitmaps/?do=findComment&comment=36266 So I hope that you and/or others might have more insights about the future of the Graphics32 project. I used it in the past very successfully, and would also nowadays bet on it, but the activity of this project is quite slow. Why is that, I cannot really understand ? I have seen attempts from ZhaoyiPeng, to bring Gr32 to FMX, but also this moves quite slow, or is stalled. I see effords from Angus Johnson, to push a new Image32 project. Is the Image32 based partly on Graphics32 technologie ( I'm afraid its not), or how does it fit all together ? I had no time to look into all that more deeply, but the Gr32 for FMX seems to be only a proof of concept, and many features still missing. My original though was that Gr32 is able to use different backends, so it might be possible to port this to FMX too. Since FMX makes use of GPU, I'm not really sure if Gr32 can beat this, but I think Gr32, on the other hand, has features that were not available in FMX right now, and still would make sense. Anyhow, beside FMX, for VCL this seems to be still the great choice for bitmap operations. So what is the status and the roadmap of this project ? Would be good to know. Is this lack of maintainers or lack of interested users ?

@Fr0sT.Brutal My second name is hope

Hi there, this is another chapter of my daily issues with Apple: Suddenly the update of IPA to AppStore of an formerly running app failed, when using the Transporter. I usually keep my Transporter open for days and weeks, maybe that causes sometimes an issue. From my research for this error I found a few possible reasons and solutions in the web, where I've tried to re-boot my VM first. Solution: 1. Just relaunch Transporter app, or quit and re-enter it again. (not tested, but sound reasonable). 2. Try completely shutting down your device and then turning it back on and trying. (I've tried this one). 3. Check the matching case of the SKU for new apps: E.g. "com.company.appName" wasn't accepted. If changed to "com.Company.AppName", matching the AppStore entry, it works. Sometimes solutions can be so easy, but I hardly see the easy one's very often 😥

Solution 2 worked for me, have you checked all the options 1-3, that I found in my research ? You can additionally try to clean the project and restart the Rx10.2 IDE. Since then the issue was gone.

Thanks, thats a fair goal, but wouldn't it have been better to start with a cleaned up GR32 branch then ? Maybe sometthing like Gr32 V2.0 (or 3.0) is still possible. So you would recommend Image32 over Graphics32 for new projects ? But at the moment I think its Angus project alone, and not sharing some parts with the community. That can be good to have a tough leader, avoid smearing out the core philosophies, but its also some kind of risk.

Have you considered a educational license ?

Dear David, I think you are right for the sorting issue. Since I like to use the "Tag" or "Object" property for having an simple integer ID to each entry, beside the display function, I'm curious how you would handle this. Do you also use an external storage, if you just need the "Tag" for identification of the entry, but not the sorting ? When would you use a "Tag" locally, and when would you use it externally ? I think if the "Tag" only would exists in the ListView then it should be better hold externally, to have the data separated, but most of the time it comes already from external sources, which were not so convenient to access or need more processing.

function PrepareLineForExport2(const aDataIn: TData): string; begin Result := aDataIn.ID1.ToString + cSeparator + aDataIn.S1 + cSeparator + BoolToStr(aDataIn.B1) + cSeparator + aDataIn.S2 + cSeparator + aDataIn.C1 + cSeparator + aDataIn.S3 ; end; Sometimes I like to use a "prefix" pattern like this. To make things visually more readble, and to easily include/exclude parts for testing ( by puttin // in frontt).

I know, but it uses the syntax of "by value", and this should give the compiler enough clues. Anyway, I would think that OUT will be touched first time only INSIDE of a function, at the very first line, like the "var" section, but not already outside by the caller. In practice I nearly all the time use VAR, instead of OUT, and have no (philosophical) issues with that. A VAR is IMHO usable as an out parameter, as I can use it to bring pre-settings with it. My typical pattern could be like this function TryProcessValue( var AValue : String; ANew : String; ACanIProceed : Boolean ) : Boolean; begin if ACanIProceed then begin AValue := ANew + ' I can happily proceed, and setup my OUT variable here'; Result := True; // This may additionally notify that AValue is valid end else begin AValue := ''; //<== Initialize AValue ( to ensure the OUT variable is well defined ) Result := False; // This notify that AValue is invalid end; end: So I don't need to test AValue itself, since I can use the function result itself, while still AValue could be checked too and has a defined value.

I would disagree to that, because a compiler should understand that by ref and by value of the same value is requested, and should process the by value first, because the initialization of OUT should be considered "inside" the function, not from the caller. http://docwiki.embarcadero.com/RADStudio/Sydney/en/Parameters_(Delphi)#Out_Parameters So the compiler could process all parameters before he touches any OUT parameter. An OUT variable should be IMHO considered undefined, until "inside" the function some value is assigned to. At least this is what I would expect here, and it should be easy for a compiler to detect such situation.

Can you explain how that behaviour can be intended ? Is there any argument why this is correct ?

Test(t,t); Interesting, thats a nasty bug. Again I'm happy that I prefer to use VAR over OUT, despite the fact that this is maybe philosophically a little sloppy Since tthe DefaultValue is copied by value, I would not expect that behaviour. I would call this a compiler bug, is there an RSP already ?

I personally have not much problems with the const string, but maybe it would be a more clean design always to use immutable strings instead (or together with) const ? This would enforce an (unnecessary) string-copy usually, while the simple const may get away without any copy, in the best case. I'm not afraid of additional copy too much, but I think also why should we do that, if there were only little const issues. On the other hand, I assume there is no really immutable string possible in Delphi, so lets stay with const (or I have to write my own complete string class maybe, with a lot of extra protection).

Use grouping in TLayouts, and alignment via Align.Top Left Client etc., Create gaps via Margins . ..