Rollo62

Don't worry, emptiness is full of everything, thats what physicist's know today

Maybe you talk about TEmptiness<T> ? 🙂

I think thats a good startingpoint too. http://fire-monkey.ru/

Easy to understand: Apple want to punish their loyal developers with maximal pain as reward 🙂 If you want to be in their exclusive club, you have to enter using their back entry veeeery deeply.

TListItemText has all properties for alignment; Align, VertAlogn; PlaceOffset You better check FindDrawable before access, call me paranoid, but I never trust any FindXxx method var Dwb : TlistItemDrawable; ... Dwb := AItem.View.FindDrawable('Text1'); if Assigned( Dwb ) and ( Dwb is TlistItemText ) then begin Text := Dwb as TlistItemText; ... end;

https://www.youtube.com/watch?v=yVwYZ05N7Sg https://blogs.embarcadero.com/introducing-the-listview-item-designer-in-rad-studio-10-1-berlin/ https://www.youtube.com/watch?v=nRPDH5dHMCA https://www.youtube.com/watch?v=il55nvYbDsg

@Jim McKeeth Sorry Jim, I do not have much time right now. What I can say in general, I think the problem with the demos is that they were not set up in a proper folder representation. Like /Packages/Rx1033 /Packages/Rx1041 /Packages/Rx1032 /Src So that all different versions are nicely separated, and no IDE .dproj conversion is needed when opening with the wrong version. I think that is usually most of the time the provblem, that opening an older .dproj file with the newer IDE, but the IDE is not 100% able to convert and all parameters correctly (its simply too complex). A better library-structure would help to keep the samples up-to-date, and also to see whats already upgraded, and whats not. I came back to this topic triggered from the nice article here. Maybe the demos has to be seen as part of the library too ( so do I ) ?

Probably by loading on demand, see here in the german DP.

I think VM on Mac is perfectly fine with their license. Anyway I payed so much for their stuff that I hardly care, I feel that I bought Apple already

Maybe its worth to share the answer in your cross-post on SO. What brings me to the question if MacInCloud is a useful tool or not ? I considered to use MacInCloud in the transistion times, when OS version changes, to fastly and safely make early tests. Now I set up my own VM, installing stuff, etc., which is no big deal, but also takes some time. What I wanted to test if just starting MacInCloud, pre-configurated, can maybe reduce these test- and configuration time a lot. I would try with real devices, so not the simulator, as the SO answer also points to. Will such setup with MacInCloud is working flawlessly and make sense, or will I stay better with my VM setup ? I'm wondering who has good or bad experiences with MacInCloud.

I'm just a little curious: Who really relies of a memory string >= 2GB, in danger of killing the whole OS ? Even if my machine would have enough memory, I always would try to chunkify that, or to use memory mapped files instead. Is this 2GB limit a rather theoretical limitation, or is that widely used in real world applications ? Of course there were maybe some special cases on dedicated machines, like math, search engines, physics simulations or the like, that would require such high needs, but I just think the normal app, even with high database or 3D load, would never reach that limit. Maybe you can proof me wrong by some examples, since I don't see any use case at the moment.

Hi there, @jeroenpJeron's blog notes points me to an old issue, thank you for keeping track on that very detailled. I wonder, from the two practical workaround solutions, which one is best: I would vote for the 1., as a golden rule: DON't USE CONST ON INTERFACE PARAM's My argument would be, that is easy to spot at first sight in the interface and implementation, and its easy possible to find by aoutomated tools. What arguments are for the 2nd solution, are there any better ?

Not really, I was thinking in the direction that in 95% of cases have NO performance issue at all, so I could judge for "safety" over "performance". Like 1. Never use const interface parameters (in most cases where a little performance loss is acceptable) 2. Always use local inside 3. Keep as-is, educate on the issue 4. Never use inplace-creation 5. Always use .New creation approach That would make 1.) intrinsically safe under all circumstances, which was my goal, on cost of only a little performance loss. Well, that makes 4.) and 5.) still very valuable and preferrable, and working perfectly together with 1.) too. All in all reducing together the whole risk of "pitfalling" somewhere unexpected.

My criteria would be an easy to spot solution, that jumps in the eye when not following the "golden rule". Of course this might be strongly philosophical, and maybe has personal preferences. Thats why I think its good to list all possible options, with their arguments, in a short list like this. So that everybody may decide for himself howto deal with it. So far I count 1. Never use const interface parameters 2. Always use local inside 3. Keep as-is, educate on the issue 4. Never use inplace-creation 5. Always use .New creation approach I think there were many good solutions on the table already, I'm curious if there were more outside. Maybe really 4.) is really better than 1.), have to think about the pro's and con's. In fact I rarely use inplace creation anyway, so it wouldn't be a big deal in my case anyway. What I use is 2.) quite often, 4.) mostly, 5.) more and more often ...

Ok, I agree on that too. So you mean "Never use inplace creation, no matter if its object or instance is used" ? Yes, the basic issue is maybe that inplace constructions are easily overseen, as it not obvious if they are used as object or interface. You always need to dive into it, to find out. But this is not 100% efficient either, I'm afraid. To use always an additional variable at caller side is good rule too, but could also lead to clumsy looking code. Maybe to get the best of both is to use special named functions, as shortcut, like Add_Obj, Add_Inst, but thats not nice looking either. The .New approach I like also a lot, and use it in many places. Yes, maybe thats solving issues, but also maybe has not 100% performance. The issue with all that I see is, it doesn't prevent or protect against accidentally using inplace creation, which the 1st solution would be able to solve.

Thats a situation where you could use fully qualified names, like UnitFormats1.FormatSettings. DateSeparator UnitFormats2.FormatSettings. DateSeparator And yes, the last Uses entry wins, but if you use it may show usually some "ambiguous" name warning, when accessing methods or fields.

No payed, no OLE, ... Puh its getting hard. I would have suggested to look into (payed) HtmlOffice components as well, but not sure if they can do that you want. Anyway, then maybe UNO + LibreOffice is the last free resort ?

Hi there, I had some time to check out the great OpenSsl library from Grijjy / @Allen@Grijjy, and I found that its working even without binding any libraries to it. The original FMX sample showed some issues, so I just created a brand new Rx10.4.1 project and moved the main unit to it. Beside the Grijjy Foundation, I've put no static linked files yet in the deployment, to check this library out step-by step. Of coarse for Win32 I need the enclosed DLL's in the EXE folder, that's no surprise. It puzzled me that for Android and iOS, as well as for Macos, I don't need to add any library at all to the library tree/deployment Even in Allens post, there is the note, I've misinterpreted that it should be added directly to the projects library tree, or by deployment manager or some other hacky means: Also Embarcadero has notes about OpenSsl, Which leads to the conclusion at least iOS would need some external download of static libraries. In the libraries const section, I can spot the different static/dynamic names, but where and do they bind to ? const {$IF Defined(WIN32)} LIB_CRYPTO = 'libcrypto-1_1.dll'; LIB_SSL = 'libssl-1_1.dll'; _PU = ''; {$ELSEIF Defined(WIN64)} LIB_CRYPTO = 'libcrypto-1_1-x64.dll'; LIB_SSL = 'libssl-1_1-x64.dll'; _PU = ''; {$ELSEIF Defined(ANDROID64)} LIB_CRYPTO = 'libcrypto-android64.a'; LIB_SSL = 'libssl-android64.a'; _PU = ''; {$ELSEIF Defined(ANDROID32)} LIB_CRYPTO = 'libcrypto-android32.a'; LIB_SSL = 'libssl-android32.a'; _PU = ''; {$ELSEIF Defined(IOS)} LIB_CRYPTO = 'libcrypto-ios.a'; LIB_SSL = 'libssl-ios.a'; _PU = ''; {$ELSEIF Defined(MACOS32)} LIB_CRYPTO = 'libssl-merged-osx32.dylib'; { We unify LibSsl and LibCrypto into a common shared library on macOS } LIB_SSL = 'libssl-merged-osx32.dylib'; _PU = '_'; {$ELSEIF Defined(MACOS64)} LIB_CRYPTO = 'libcrypto-osx64.a'; LIB_SSL = 'libssl-osx64.a'; _PU = ''; {$ELSEIF Defined(LINUX)} LIB_CRYPTO = 'libcrypto.so'; LIB_SSL = 'libssl.so'; _PU = ''; {$ELSE} {$MESSAGE Error 'Unsupported platform'} {$ENDIF} I've put my test code as a wrapper around the original code, basically just adding the new project files. It seems the magic happens, because the libraries were sitting all side-by-side to the calling unit. The OpenSSL_Api unit find these local files in the same folder, and is able to bind them correctly. I didn't know that this is possible, I thought they have to be in the same project folder, and at least cross-platform make another hazzle to bind depending on the OS. Good to know that its enough to provide library+unit together, that gives much more room to cleanup libraries. I've put my wrapper code enclosed for testing, while the originally library files from Grijjy should be placed in the Src folder. The missing files you can get from here. I hope Allen don't mind. T381_GrijjySsl.zip

@Allen@Grijjy Thanks for the info. It seems that a "dependency" keyword has not hit me yet, or I overlooked it many times, but I cannot really guess what its good for and how its working. Since I can't find really useful information on this, only from your other blog post: //A way to add the dependency automatically is // by adding the dependency keyword to one of the API imports in the source code. For example: procedure foo; cdecl external LIB_FOO name PREFIX + 'foo' {$IFDEF MACOS64}dependency 'c++'{$ENDIF}; Maybe you have some hints and could point me to a link, where I'm able to find more information regarding this mysterious keyword ? Is this only available for Macos64 then ?

Hi there, I like the modernizing of the old Dev-C++ IDE very much 👍 Well done. This is very important, I think, to follow with a good and stable base towards new OS and market paradigms. It looks fresh and modern, while still keeping the good old qualities, without overdoing things. All in all very well able to keep current users and likely to catch some new friends in the future too. We have the saying: "The eye eats with you", and I think that is pretty much true.

What about 'Routing ?

@Serge_Gthanks anyway, so I don't have to look into it too. Yes, that saves a lot of redundant work .... Sorry that you will be grabbed now by Emb-Police, farewell.

Yes, in Macos/iOS/Android I use both events, the OnDeviceLE to show an early response, and the EndDiscovery to proceed further. So an additional timer would mimick the Android/iOS behavior well. Still I don't use BLE on Windows, which is another construction site, but its on my roadmap.

How do you detect end-of-discovery, do you run a timer in parallel ?

You got my point.