Rollo62

See also here https://www.thedelphigeek.com/2021/02/readers-writ-47358-48721-45511-46172.html

Yees, thats a nasty bug. Thats why I had choosen long time ago, to always add a proper scope around even the simplest lines. if FWorkOrderManager.GetWorkOrderDataByIndex(WorkOrdersSelectedRow - 1, Data) then begin // evaluates file index FileIndex := ARow - 1; end; IMHO that increases readability and avoid a lot of such hard to see errors. You're lucky here, that the compiler throwed a warning 🙂

I was trying to find some more insights, since my debugging at XCode 15.4 is currently broken. Here is what I have found so far, perhaps there are more tips to workaround somehow. Due to the fact that it worked for a while at least release & run from the IDE, but now suddenly seems to be broken for no reason, I had to look into this again. My setup: Macbook Intel Macos Sonoma 14.4.1 (23E224) XCode 15.4 (15F31d) - Multiple installations XCode 14.3.1, but the XCode 15.4 is the active selected, by xcode-select - All tools running Delphi RAD Studio 12.1 Patch 1 PAServer 14.1.14.0 Situation: Compile & Linking OK Run & Debug on device: Not OK ( Please do not propose using simulators, I'm looking for a workaround on device level ) XCode 15.4 - Seems to have only Python3.9 shipped within its PackageContent "/Applications/Xcode_1540.app/Contents/Developer/usr/bin" Python3.10 - Has to be installed manually, will land into User folders: /usr/local/bin/python@3.10 and /usr/local/opt/python@3.10/bin - Can be linked by SymLinks to PAServer PAServer - Seems to use Python3.10 internally - Seems to use llvm, lldb internally LLVM ( seems to be required by PAServer - iosinstall) - When installed by bew, it seems to depend on Python3.12, installs Python3.12 too. - Can be linked by SymLinks to be globally available Python3.12 ( seems to be required by llvm ) - Can be linked by SymLinks to be globally available ( but this is maybe the issue in PAServer, linking to Py3.10 and Py3.12 at the same time ) Problem: Signing: Seems OK via PAServer so far Launching: Seems not possible to launch the app via Delphi - Launch by: ""/Applications/PAServer-23.0.app/Contents/MacOS/iosinstall" -W -i bba94cfcbb26d9ff31774ac97d06e929f954993d0 -L -z "/usr/local/bin/lldb" -q -b "/Users/currentuser/PAServer/scratch-dir/currentuser-MB02_Rx1200_Athens/MyApp.app" Deployment - The app can be deleted, this commands seems to deploy and try to run it. - The app runs shortly, then crashes - When running the same, uploaded app manually, by double-click: The add starts and runs fine, only the iosinstall crashes Log and Eventlog - The command above returns like this - The Eventlog looks like this So the root cause seems to be the "iosinstall" command, IMHO. Maybe more specifically the usage of Python3.10 and Python3.12 within the same PAServer package, calling iosinstall and lldb and others. I have tried a few tests and still I'm not really clear why this not simply runs, no matter what Python library involved. Why does XCode 154. only include Python3.12? Why does llvm depends on Python3.12 (there seems no easy way to downfrade this, ate least not with brew and pip3) Is there any known workaround at the time now, what needs to be done? Apple development again causes my days or fumbling, instead of easy click-and-run. Why seems Python stuff so sensitive on versioning, are these known issues? Mybe some Python experts may lead to some easy tools or ideas to solve it.

Just to add some some thoughts on an alternative way, with certain pros and cons. I like to use a simple TDateTime helper in such uncritical situations, instead of GetTickCount, to determine timeouts: function TDateTime_Helper.Timeout_MSec_IsElapsed( const AValue : Integer ) : Boolean; begin if Self.IsNull then Result := False // is stopped => trigger never else Result := Now.MillisecondsBetween( Self ) >= AValue; // is elapsed => trigger conditional end; Cons: - Yes, it has much lower performance, since this has to run through many conversions and calculations. Roughly speaking this is in the microseconds range, while the GetTickCounter may lay in the nanoseconds range ( approx. factor 1000 ). In these cases, where I just need to test this in quite large periods, like > 10 sec., I think this is not a too big deal to loose some microseconds. Pros:< - It adresses timing questions directly, by easier readable millisecond notation and avoids any tick count mis-calculation or logical errors by default. - It avoids possible overflows, which may happen at 32-Bit in about 49.7 days (using GetTickCount64 practically may solve this, by overflow in about after million years). (A consideration to use QueryPerformanceCounter also might solve this overflow, but in 99.99% of the use-case any high precision is not needed.) - It avoids possible counter blocks or counter resets, by always using the real timestamp (of course a user might change the system time, but this is not very likely to be done without a clear user invention). - It avoids issues by non-incremental counting, which is noted in the GetLastInputInfo description already - It elegantly avoids the need to build any additional safety measure around the overflow or incremental issue from above, just to ensure a proper incremental timeline. - It should immediately work in the same way under all platform, because a timeline is a universal feature. (GetTickCount is originally a Windows function, other platforms may handle this completely different) .

Yes, you name it. Thats why I use portable, non-service tools wherever I can, looks like Awake plays in that category too, have not tested yet. I cannot understand this permanent services and processes bloat also, which only brings performance and reliability to the ground level.

Thanks, that "Awake" is a good tip. Usually I use my machines more or less clean and unchanged, like their were intended from their Maker. Mainly because finetuning, optimizing GroupPolicies or the like is a pain in the a** and some permanent gameplay for IT nerds or admins. I usually try to avoid that on all cost, because that is an evergrowing overhead with little benefit, IMHO.

Local, I mean within the app itself. There its quite easy to detect missing keystrokes or mouse moves by slow running timer. So the app could manage an Idle state, similar like banking apps in the browser (log out after 5 min.). Global, I mean, when your app is running, but in background. While another, long running task is in foreground, for example you wat 1h Youtube video in the browser. This means Global is "active" (even if the user is idle), while your local App is Idle. What do you expect to happen in such situation?

Its unclear to me, if you are looking after an application-wide or global detection of user-idle? For the local app, I think its easy, but for the global that can be tricky. How will external, long-running tasks in threads be handled? For example, if you do a longer running FTP-synchronisation, running updates or something like that: Does that mean the user is idle after some time, or not? What often disturbs me is, if the system is heavily running, like updating, giving a powerpoint presentation, but the OS switches unexpectedly to "idle", only because the user is waiting for finishing such a process. This forces me to hit the mouse from time to time, to keep the whole system awake. Maybe to improve to detect such situations above, it would be possible by checking the CPU load additionally and block "idle" mode 🙂

CrossPost

Do you mean something like this, for reverse GeoCoding? https://nominatim.openstreetmap.org/search?q="Köln, Heumarkt"&format=json

Beside other tools, I like Uwe Raabes Mmx CodeExplorer and here is another nice tool from Alexander Sviridenkov coping with that. Generally, like said before, you could consider to move critical references from the "interface uses" to the "implementation uses", wherever necessary, and to split up classes into interfaces and implementations in separate units.

Not sure if you are talking about this item with SnapDragon? https://www.microsoft.com/de-de/surface/devices/surface-pro-11th-edition?ef_id=_k_Cj0KCQjw0ruyBhDuARIsANSZ3wpQRZ2cSDuit-TypUqepPgIc4AE_aMrLZmReQw0Ai2OuQqK-QZQObwaAuOoEALw_wcB_k_&OCID=AIDcmmkg9d0avi_SEM__k_Cj0KCQjw0ruyBhDuARIsANSZ3wpQRZ2cSDuit-TypUqepPgIc4AE_aMrLZmReQw0Ai2OuQqK-QZQObwaAuOoEALw_wcB_k_&gad_source=1&gclid=Cj0KCQjw0ruyBhDuARIsANSZ3wpQRZ2cSDuit-TypUqepPgIc4AE_aMrLZmReQw0Ai2OuQqK-QZQObwaAuOoEALw_wcB#sup3 Which seems officially listed for pre-order on the Microsoft site, perhaps not shipping yet, but at least quite a bit "official". Not sure if these "preorder" prices have large rebates.

I can conform Daves code too, works well here also 👍. What I've implemented in the former manual approach, was a system that shows a message and listens to the user turning the screen into the right position, handled by anonymous method. My goal was to distract the user as little as possible from his normal workflow, not enforcing him to press and buttons. class procedure TCore_Orientation.SetCurrent( const AOrientNew : TScreenOrientation; const AOrientPossible : TScreenOrientations; const ANotifyWhenReady : TProc ); begin // Use an anonymous method, to notify the change to the caller FNotifyWhenReady := ANotifyWhenReady; // Do whatever is necessary, either direct or after users message. // Register my ApplicationEvent handler, that listens to the change has occured, if that is necessary end; ... // How to use it in the caller TCore_Orientation.SetCurrent( TScreenOrientation.Portrait, // Desired orientation [ TScreenOrientation.Portrait, // Possible orientations allowed TScreenOrientation.InvertedPortrait ], procedure // Wait until User turned it as desired, or after it was set by hardware. Never reach this when cancelled. begin // Do whatever you wanted to do, after desired orientation is finally set up (triggered by ApplicationEvent or direct) end ); ... end;

I would suggest not to use those second layer functions at all, but to use TEncoding for this task: Result := TEncoding.Default.GetBytes(Val); It seems that all relevant of those overloaded functions use the same TEnconding function internally and the rest of the overloaded functions are only for some special cases.

I just have seen an even weirder situation. I already used XCode 15.3 with iOS 17.4 before, have installed the iOS 17.4 SDK in D12.1. Last week I happily compiled and debugged on my iOS 16.7.7 device. This morning, I've got the same message above and the platforms settings looks like this: It seems that XCode had un-installed the iOS 17.4 device support suddenly, over the weekend. Is this something that can happen, without touching the system (not even reboot over the weekend), or do I have any delusions? After pressing the GET iOS device, it also downloads the simulator Whow, a lot of Apple-Magic involved, Apple is so much better than Windows

Im afraid so too ... https://en.delphipraxis.net/topic/11463-ios-xcode-15-madda-make-delphi-debugging-again-after-01may-2024/?tab=comments#comment-90929

Oh yes, of course. I had skimmed the title too quickly, normally terms like TTS, TextToSpeech, SAPI, SpeechToText trigger me in the right direction. Maybe this will be helpful "https://learn.microsoft.com/de-de/windows/apps/develop/speech" and an older article with Rx1.4.2 sources by Brian Long "http://www.blong.com/Conferences/DCon2002/Speech/SAPI51/SAPI51.htm"

You can have a look here, from Grijjy, its quite old, but worked well for me under iOS and Android, so I assume Windows is OK too.

Yes, that is another strategy of Apple to block unwanted, external development systems. My older MacBook Pro 2013 stucks on, I guess Catalina, which makes it completely unusable for development. The same happens now with Sonoma and older versions all the time. This is why I decided not to purchase the most capable, expensive Mac any longer, but looking for the cheapest version instead. Windows machines for the same money can do much more, more reliable and lasting much longer. Unfortunately also Microsoft is on the track of the business model of Apple now, more and more. Don't understand me wrong, cutting old tails from time to time is not a bad thing in general. But doing so in a too frequent manner is just kind of fraud. Still I'm more fond of the Windows ecosystem, the Macos ecosystem is more and more a no-go, for several lock-in syndrom reasons. Sooner or later, I think the Linux ecosystem will be the solution out of both booby traps, but unfortunately still is not ready yet for Delphi devvelopers.

@Dave Nottage Thanks for giving hope and pointing to the right direction, as always As expected. simply starting and debugging an iOS 16.7.5 device with SDK 17.4 fails, with the following message: Starting the Debug Build without debugger ( Ctrl+Shift+F9 ) works well, start and seems OK so far. After a few more steps, I could really debug again on XCode 15.3 + iOS Device 16.7.5 + iOS SDK 17.4. Edit: Worth to mention: Running on MacBook Pro Intel: MacosOS Sonoma 14.4.1; Parallels Desktop 19.3.0 Here is the whole process is documented: I hope that can help another poor guy, who is getting crazy from the mysterious Apple moves.

Immutable objects have their own, non-changeable state and are therefor thread-safe by design https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

Dear Dave, thanks for giving me a little relief on the upcoming forced upgrade. With "manually" hooking the older SDK, I mean the formerly needed manual copy and past from old XCode SDK into new XCode SDK's PackageContent. Is this not necessary too, which means that XCode 15 still offers 16.7.7 SDK without much hazzle? Please note: My main goal was not loosing the debugging ability. This would require from my understanding an XCode iOS 16.7.7 SDK and an iOS 16.x device. When using iOS 17.x SDK, I'm in danger to loose debugging option, right? Nevertheless, I will try to install XCode 15, but want to do that as safely as possible, to avoid destroying my current, well-working workstation setup. Here I've made a little "actipn plan", how to keep old and new XCode safely side-by-side. This is hopefully complete and let me switch safely between old and new. without and negative impact. Here I've tried to separate XCode 1431 and 1520 as much as possible. Maybe thats helpful for other too, I will check that soon and get back if something turns out terrible wrong:

Thanks for clarification, I assumed that XCode 15 won't support or can handle older iOS 16.x SDKs any longer. If XCode 15 is bundled with and hardly enforces SDK 17.4, or not allow to load or use SDK 16.x and longer, then this won't help either. Can you confirm that XCode 15 can still be used for debugging same as XCode 14.3.1, under iOS 16.x, without too much trickery ? The older SDK will have to be hooked into XCode manually, with all possible incompatibilities. If would expect something like this: Ok, I found this, which states that Delphi already supports the newer LLDB debugging system, perhaps since Alexandria, and that should be a good thing. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I will update my table above accordingly. Are there any official notes about whats changed internally and whats currently still possible? I must confess, that I had not followed the WWDC videos, because lack of time, would be great to find some official statements about these changes and roadmaps.

Hi there, I'm still evaluating the D12.1 version currently, it all looks pretty much OK so far. What I have notices is, that the info.plist now containse more entreies: <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>16.4</string> <key>DTPlatformBuild</key> <string>20E238</string> <key>DTXcodeBuild</key> <string>14E300c</string> <key>DTSDKBuild</key> <string>20E238</string> Al this is understandable, to improve the development tools stability. Only the DTPlatformName wonders me, since I have checked "iPhone & iPdad" for the UIDeviceFamily: Which appears like this: <key>UIDeviceFamily</key> <array> <integer>1</integer> <integer>2</integer> </array> The general conclusion is like this: UIDeviceFamily: Defines the device classes on which the app can be executed. The possible values are: 1: The app is intended for iPhone (and iPod touch). 2: The app is intended for iPad. If both values are specified, the app supports both iPhone and iPad. DTPlatformName and other DT keys: These keys are specifically intended to provide information about the development environment and target platform, including the version of Xcode and iOS SDK used to build the app. They are important for the build and review process in the App Store, but they are not directly affected by the UIDeviceFamily setting. Perhaps this means, that the app should be broadly compatible within the iOS ecosystem, which is relevant during development and later distribution via the App Store. This also seems to fix an known error: https://docwiki.embarcadero.com/Support/en/“ERROR_ITMS-90507:_Missing_Info.plist_value._A_value_for_the_key_'DTPlatformName'_is_required”_when_submitting_an_app_to_the_iOS_App_Store Here some info from another source: https://github.com/godotengine/godot/issues/74154 https://forums.developer.apple.com/forums/thread/111697 What the heck is this DTPlatformName good for, is there any offical documentation about it? Maybe there are there other options too ...

Thanks, this is what I found too, see my original post. Nevertheless there seems nothing from the official Apple sources or forums.