Brian Evans

Still - where and why? - in a lot of cases you can already know when your code is called. For example OnDrawItem is set per item so you can just assign one procedure for main menu items and another for the rest.

One approach: The Items property has a find() method that searches for a match of a caption passed in. It ignores & to make matching easier. So if you have a reference to the main menu you can do mainmenuref.items.find() passing in the caption of the menu item you wish to test. function isMenuMenuItem(MainMenu : TMainMenu; MenuItem : TMenuItem) : boolean; begin If MainMenu.Items.Find(MenuItem.Caption) <> nil then result := true else result := false; end;

Note that is the wrong inner loop statement. It needs to go a level deeper. FixItem (aMenu.Items[I].items[k]);

Use two loops to start with so you iterate into sub menu items before calling FixItem(). Then FixItem() only gets submenu items and can be simplified. for I := 0 to aMenu.Items.Count - 1 do for k := 0 to aMenu.items[i].Count -1 do FixItem (aMenu.Items[I].items[k]);

Well that is a new hell: the forum screws with the image. Also can't seem to delete the image I attached which ended up showing the same issue - size and bit depth messed with by the forum. Looks like it is display issue - click the image to bring up large view, click the large view to bring up a fuller view - now that shows the original uploaded image which you can right click and save image as .. to get the proper bit depth and resolution that was uploaded. If I load the image in your first post which is a 23kb 500x500x32 PNG into a TImage using the IDE it looks normal. Note the image itself does have gray pixels around the edges and borders of the squares - it is not black and white. The 2kb 912x912x1 PNG in the DFM does display oddly both on the form and in the IDE image property editor. In Windows explorer and other image editors I tried it looks normal. It has only black and white pixels. So the IDE does seem to have an issue with the 1 bit per pixel PNG. Can work around it by using a higher bit depth it seems but Delphi should really be fixed as the IDE exhibits the same issue. Attached is the 912x912x1 image re saved using MS Paint as a 9kb 912x912x32 PNG which works fine as well.

A image showing what "rendered incorrectly" looks like would make it a lot easier to confirm reproduction.

The debugger catches them before they are handled in the application/project not after. When shown by the debugger there is a checkbox to ignore that class of exception going forward.

In Windows Defender you can exclude by process in addition to by file/folder/file type. Process: Adding an exclusion for a process means that any file opened by that process will be excluded from real-time scanning. These files will still be scanned by any on-demand or scheduled scans, unless a file or folder exclusion has also been created that exempts them Tip: It's recommended that you use the full path and file name to exclude a specific process. This makes it less likely that malware could use the same filename as a trusted and excluded process and evade detection. Ref: Virus and Threat Protection in the Windows Security App - Microsoft Support Final note about testing IDE start speed: Windows Defender does cache real-time scanning results so IDE launches after the first will be faster even with no exclusions.

There are network profiles in Windows which can be Private, Public or Domain. Normally your home network would be Private and anytime you go elsewhere it would be Public (discovery disabled) or Domain. You could check what the active connection is. Or just key off the active profile name for what network settings your application should use. Snippet below for PowerShell. Get-WmiObject MSFT_NetConnectionProfile -Namespace root/StandardCimv2 | select Name,@{n='ActiveNetworkProfile';e={ switch ($_.NetworkCategory){ 0 {'Public'} 1 {'Private'} 2 {'Domain'} Default {$_.NetworkCategory} } } }

The annoyance is Microsoft Office gets installed as EITHER 32-bit or 64-bit and this includes the database access infrastructure for it like the Access ODBC driver. You never get both 32-bit and 64-bit at the same time and installing Office will uninstall the one it doesn't need while installing the one if does need. The Unidac drivers from Devart include a direct mode that doesn't use the ODBC drivers but has some limitations like not supporting DDL statements. This gets around needing a matching 32-bit or 64-bit Access ODBC driver.

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