Rollo62

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.

Of course its not relevant, but nice to have, and good to see what a little "modernizing" can do. Also good to have a Delphi-based IDE, from where its maybe possible to start some support for special embedded hardware one day. Yes, we can use VisualStudioCode for all that too, but should we ?

@Roger Cigol I think Dev-C++ was originally intended as learning IDE platform, and probably only to make some small test projects. Maybe its better to compare Dev-C++ to RadStudio like VS Code is comparing to VisualStudio.

For issues like that I have a Clean_EXE.cmd batch file, removing all created files and folders externally. An internal clean is not good enough in most cases. I usually run clean and build all before any important change or release. In case of issues I step through the different shades of clean step-by-step, as not always a brutal full clean is needed. But I didn't need to re-install the target platform yet, anyhow maybe the days will come Good to know there is another shade of clean in the portfolio.

M1: Maybe you need at least 3 characters minimum

Adress data can be much chaotic data in general, including typo's, exchanged fields, etc. Thats why a hash value is maybe problematic too, if you want to work with the data. Have you considered to reverse GeoCode the data in a single batch run, and add lon/lat to your database ? Maybe that could make more sense for you, but could allow several "same" addresses of coarse.

Hi there, I have found this interesting post from Developpeur-pascal.fr, about howto check the M1 processor from an Macos app. (here the original link). Since I have no Apple M1 device in hand, I'm very curious about how it runs, or what needs to be prepared or avoided to do so. I assume that only normal, compiled apps may be working, by the Rosetta2 emulator, but not the PAServer debugger itself. ( or can PAServer be emulated and debugging too, and M1 could operate quite normally ? I would bet 10 bucks against that ). Would be great if you would share the pitfalls we can find there.

Ok, my fault, maybe a copy-paste-error here in DP: I had clearly seen the .a ending when I answered (thats why I copy-and-blue-red it, to make it more visible). So I thought this was maybe wrongly interpreted as fibrary file. I still think "lib\.... " should be the right place.

library\lib\arm64-v8a lib\arm64-v8a a So what you think the issue is, the missing library, or the added .a ? I think the library\lib should be right to be pointing to lib only, or do you expect the folder library ? The added .a should be not OK, maybe there is just a "\" or "/" missing or too many in the options setting, be aware that also the options settings exist for ALL, DEBUG, RELEASE, x32/x64, which could differ. I've added a kind of debug mode in my apps, where I can list and check all the available the local filles and folders, maybe that helps to get clear when comparing where are the differences after installation on the different phones. Does the libraries have same name for x32 and x64 ? Maybe that causes the bundle or the OS to ignore it ? But it should work with same name under different folder, I would assume too.

Do you have a simple test app, to be able to verify that it doesn't deploy ? Did you add the deployment manually in the deploymment manager (I remember there is also an automatic addition somewhere for default libraries, but SSL shouldn't be in there) ?

The RestDebugger should be in source code, under \Embarcadero\Studio\20.0\source\data\rest\restdebugger\ Maybe you can spot a difference between Rio and Sydney sources, but I doublt that there were any changes ? Have no Rio on hand, so I cant check. But also possible that the underlying REST components have changed.

Have you copied the missing files from Rio to Sydney, or did you add them manually ? What is the difference, did you made a diff of the files ? When using RestDebugger, you can also paste to pure TEXT editor, which should give all the components in textual format, would be interesting to see the difference in export from Rio and Sydney as Textfile.

Great, I will check that

I like the mustache notation {{}} a lot, is it possible to make this compatible (at least a bit), to Mustache ? (Naive approach: Maybe its just replacimg "<%" "%>" by "{{" "}}" ) ?