Brian Evans

Windows phones were for real and some were really good. I still miss them as the Windows 8 tile UI I disliked on the desktop worked great on mobile especially the live tile screen and the application list screen. Didn't save the platform when Microsoft's attention shifted to other things. The YouTube unboxing video linked earlier in the thread is actually for the Intel version of the Surface Pro 11 and is described after some limited testing as the best Surface Pro they have ever used. Not exactly a ringing endorsement of the ARM based ones. Windows 11 on ARM has potential but I think it still needs to show some sustained support and take up before its worth the effort. Bit of a chicken and egg but Delphi has been burned before adding platform support early - Kylix and Delphi.net being two examples that just drained away developer resources and then were abandoned.

Microsoft has done several attempts at Windows on ARM for over a decade and they have all been total failures. Anybody who targeted it ended up wasting a lot of time and money. The most recent effort does have two things previous attempts didn't: full win32 API support and the ability to run x86 binaries. That alleviates the need for application developers to produce ARM binaries until Windows on ARM gains some traction as a platform. Adding support before the platform gains some traction is unwise. We are in fool me once, fool me twice, fool me three times territory for Windows on ARM.

Don't forget the difference between a user trying to get work done in an application vs a developer playing/scrolling around. I find a modern styled application can be easier for a user to read and follow as they work on the content shown in the application. Some appreciate being able to adjust things to their taste - especially older workers desiring larger fonts and more contrast. Users rarely dynamically resize forms these days - either it is full screen or snapped to half a screen or some other region. I have gotten distracted working on things that seemed important - speed while users really wanted predictability. For example a form frozen for 4 seconds feels worse to a user than an active form showing progress that takes 15 seconds. When developing I might scroll through 1000's of records while a user is more likely to search and display 10-100 records and examine them when actually doing work.

Look at the crash details to get hints as to what is going on. Note you didn't post any and "crash" is very little to go on. Guessing it is the CALL that crashes due to the object reference being no longer valid. Perhaps owned objects are getting freed automatically or earlier than before. Not sure which code is yours (if any) so hard to tell.

Can check what API calls are being made and if some are failing shortly before the application gives up the ghost. One tool for that is API Monitor by Rohitab Batra http://www.rohitab.com/apimonitor

Note you can access the VCL from another thread in a thread-safe manner using Synchronize (https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.Synchronize) Code inside the Synchronize is run using the main thread.

In the full IDE more than just the compiler parses the code and some of the other parsers have been slow, flaky and unreliable for a long time. I don't think allowing and including code like this is helping any.

This seems like adding requirements covering corner cases or minutiae that are unlikely to be meaningful to actual users. Most just dislike doubt and uncertainty - is it still doing anything? did it freeze? How much longer will it take? - provide some indication that answers those questions and most users will be happy. Trying for a precise UI treatment while also not fixing threading in the main application seems like a way to waste a lot of time on a secondary issue - just get the information displayed.

One option: Create another application that shows a loading GIF and occasionally send it messages from your main thread to update/exit/etc. Has drawbacks but disturbs the exiting application the least code and UI wise.

Two of the big ones - Microsoft SQL Server and Oracle - still provide and support 32-bit clients. The databases with per server and/or per client license fees have more resources and incentives to keep that support going.

An elapsed time clock is another option. If the time taken has some predictability users tend to like this option - over time they get a feel for how long some tasks take and if they can grab a quick coffee etc. In the Delphi 7 days I used a component from the Developer Express Forum Library for this but they stopped maintaining it a long time ago.

There is a 32 bit ODBC driver, currently it is: Connector/ODBC 8.0.40. (select version 8.0.x in the list here: https://dev.mysql.com/downloads/connector/odbc/ ) It does mean using the FireDac ODBC driver to then use the MySQL ODBC driver vs going more directly.

Note "IDE Insight", a search box on the right of the title IDE Window's title bar can be used to search for settings. Once you remember it exists finding settings is usually much faster than manually going through the settings dialogs.

Could be some piece of software or the display driver. Hard to say without more details of the system. The contents of the Display tab of dxdiag might help. Also check for any tray icons or software running in the background with % GPU (CTRL-SHIFT-ESC, Processes, right click column headers and turn on GPU engine column).

How about fully logging/signing out then back in (so it resets the Window session)? Very odd such basic functionality is failing.