Leaderboard

Hi, my first post here. Sorry if this is not the right place, but i feel this is something that should be stated somewhere for others to find. I am running the small danish company Carsoft. We make a quit successful system, called Carsoft Planner for auto workshops, in Delphi. For years I have had the problem, that the main product was debugging fine, but smaller stuff would simply not debug in 64 bit mode! I have googled for hours and tried everything i found - setting firewall, changing all the different paths etc. etc. Now I am in the process of moving Delphi and all my sources to a brand new computer, and a brand new Windows 11. So I installed Delphi 12, moved the sources, and made a very small project "Hello world", just a button and a Showmessage. Put a breakpoint, Pressed F9 and no succes. Breakpoint not found! More googling etc. Finally i found a post somewhere mentioning use of non ascii characters in paths. In Denmark we have three extra letter "æøå" and i have used one of these in the folder name for my "small stuff". Changing my folder name solved the problem completely, everything now works as it should. This might be a well known fact around the world, but I have seen other having the same problem, with no solution, so my hope is this post can help. Best regards Lars

Point #1 Before I started with the upgrade I seached for all Indy related files and and I searched all my drives. Before each Indy build I would also go and delete all DCUs, DCPs and BPLs. Point #2 You made me think about what was happening so this weekend I realized that because I use a Build Group and each project in the Project group first builds the Debug then the Release I realized that because after each build per $(Config) the DCPs and BPLs are replaced. I am not sure which carries the signatures for the units. So obviously what would happen is that for instance IndySystem's DEBUG gets build then its RELEASE. So when it is IndyCore's turn its DEBUG gets build but references IndySystem's RELEASE DCP/BPL. Thats when the problem starts. So now I first finish building all the DEBUGS for all the projects first then I build the RELEASES for them and it works perfectly. Thanks for your help and thanks for injecting some perspective here to guide me to the answer.

Probably because of its size. Most Noto fonts are huuuge. Noto Color Emoji contains both COLR and SVG data. The COLR data is ~1Mb while the SVG data is ~18Mb... I'm not sure what you are saying here. Microsoft is the primary author of the COLR format and DirectWrite supports all the common color glyph formats: https://learn.microsoft.com/en-us/windows/win32/directwrite/color-fonts However, the client has to specify what format to use during Shaping and if the client asks for SVG glyphs then that is what it will use. https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_glyph_image_formats You can try subsetting the font to exclude the SVG data and see if that makes a difference (apart from the 18 Mb data saved 🙂)

I do, but I know a dozen other things I would rather like to have, and know most of them have been reported for almost a decade or longer and nothing has happened about them - such as this no-brainer.