PeterBelow

Have you tried to explicitely set the OS compatibility of the affected bds.exe to Windows 7? I don't have Win11 installed yet but it should have this option like Win10 and older Windowses in the EXE properties dialog.

Try to not use anchors but set the new panel's Align to alTop instead. If you want vertical spacing set the panel's AlignWithMargin property to true and set its Margin.Bottom to the spacing you want and all other Margin members to 0.

Have you tried using scrollbox.clientwidth instead of scrollbox.width?

You don't. Use a TPaintbox as a drawing surface, it has a Canvas and an OnClick event. TImage is another candidate, it contains (by default) a bitmap you can draw on using the image component's Canvas, and it also has an OnClick event. As explained in other replies a TCanvas is just a wrapper for a window's device context, it cannot receive mouse events directly.

Moving from D7 to Delphi 12 (Athens) is a very big jump. If you can build the old codebase at least you don't have to worry about old 3rd-party components, but there have been a lot of changes on the way, the most important one perhaps the move from ANSI to Unicode (UTF16) characters. Sizeof(char) = sizeof(byte) = 1 is no longer true, and that hits hard if the old code misused string variables for storing binary data. Incrementing a pointer of type PChar will now increment it by 2, not by 1, and that can easily cause old code to overwrite memory, which may be at the root of your problem. It may work for debugging just due to a different stack layout caused by different options, e.g. for using stack frames. A stack overwrite can corrupt a return address and that may lead to the exception you see. As recommended in other replies using a tool like MadExcept may be the best way to nail down the problem location, but if it is indeed a stack corruption the actual cause may be far from the location where it finally manifests. In this case doing an in-depth code review may be a better option, since there are likely more of these problematic code bits in your project.

Do you know that you can supply up to four images in the bitmap you use for the Glyph property? See here for what they are used for. If your bitmap only contains one glyph image the control will synthesize the disabled image from it and the results are often not that good.

The old translation tool has been deprecated for a couple of versions already and was removed from D12 completely. Check if it is still available as add-on via GetIt, the IDE seems to still use it. It was probably dropped finally since it's Windows only and i'm not sure if it ever worked for FMX projects even there.

May be a problem in the dproj file, the IDE has never been very good in converting that from a previous Delphi version. Make a backup of the project's dproj file, delete it, and then open the project's dpr file. That will create a new dproj file without any garbage from the previous version. You may have to adjust the project options, though.

I think all you have to is to define the events with published scope and then register the property editor for that event handler type.

The import menu should also have an "import .NET assembly" item that allows import of a COM-interop-enabled .NET library.

Emba Blog: https://blogs.embarcadero.com/upgrading-and-maintaining-delphi-legacy-projects/ https://blogs.embarcadero.com/a-roadmap-to-migrate-your-legacy-delphi-and-c-applications-to-the-latest-blazing-fast-version/ Book review: https://dalijap.blogspot.com/2022/06/book-review-delphi-legacy-projects.html I hope you have plenty of unit tests etc. for your project. With a jump that large and a project using many 3rd-party components this will probably amount to a major rewrite...

Do you use the Bitmap property of the menu items or have you attached an imagelist to the popup menu and used the imageindex property of the menu items? The latter is the way to go these days.

A bookmark with a name given by the user, not just a number as the standard IDE bookmarks get. The latter do not make sense across units but the former do.

The one on d: contains stuff fetched by the installer, the one on C:\users stuff you fetched via GetIt yourself, so both are independent.

If you can reproduce the problem in the debugger the Run -> Program Pause menu item should get you the code location the program is currently executing.

Nested procedures/functions are basically legacy from the times of Turbo Pascal, before we could write properly object-oriented code. They are still useful for procedural code, but if you organize your program's tasks into classes then you can replace nested procedures with private methods of the class and either pass needed values as parameters or move the local variables used as private fields to the class declaration. IMO that gives a much cleaner and easier to understand design, and it keeps down the size of the methods.

This post may be better served in the Job Opportunities section off this forum.

Is this for defining a method parameter? I think you have to define it as SAFEARRAY[VARIANT] (perhaps the syntax is SAFEARRAY(VARIANT), do not remember) in the code editor part, that is: in the ridl file. The type library editor only offers long as the element type for a safearray parameter. The server would have to construct a safearray with variants of type VT_RECORD. I have never worked with such user-defined types in COM applications, but from the docs it looks to be horribly convoluted, to say the least... As far as I know Delphi's support for OLE Variants does not include anything for UDTs, you would have to implement the necessary details in your own code.

I remember another post with a similar issue that turned out to be linked to the size of the project (number of units, forms, something like that). Do you get the same message if you start the IDE with no project open (-np command line switch if memory serves)?

Perhaps you remember TGauge, one of the sample components that came with early Delphi versions, before Windows introduced the progressbar common control.

You misunderstand what this API function does. It does not release any memory to the OS, it just moves in-memory pages the application uses to the system swap file. That reduces the amount of RAM shown in use by the app in tools like Taskmanager, but it is in fact completely pointless to use since the OS is smart enough to move memory pages accessed infrequently to the swap file on its own when more physical RAM is needed for another process. All it does is slow down the app performance due to having to load memory pages back from swap when they are accessed. If your app is actually running out of virtual memory (the address space available for it) you have a problem in how you use memory in your application, e. g. trying to keep too much data in memory, not releasing memory correctly, or using a problematic allocation scheme that increases fragmentation of the memory blocks your app has obtained from the OS.

This does not make much sense IMO since how the text looks when viewing the file depends on the font the viewing application uses in the window that displays the file content, i.e. the width of what you consider a "column" depends on the font. If you cannot control that you may be better served by using tab characters instead of spaces for alignment. That format also imports easier into Excel etc.

How could it deal with selections spanning multiple lines or columns? That cannot be handled as command-line parameters. Just hitting Ctrl-C and launching a tool that processes the content of the clipboard and puts the modified text back on it, then pressing Ctrl-V is much more flexible, IMO.

Are you calling the DLL from a Delphi app or some other environment? Anyway, even if you use a DLL from a host app made with the same Delphi version it is not safe to pass data types to the DLL for which the compiler does automatic memory management (string, dynamic arrays, objects that internally use such data types, e.g. TStringlist). At minimum you have to use the SimpleShareMem or ShareMem unit on both sides to get both modules to use the same memory manager. This may not be enough if the DLL implements forms or datamodules, since these use global VCL variables like Application and Screen, of which each module has its own instance. The only way to make both modules share the same VCL instance is to build both with the core RTL and VCL run-time packages.

If you changed the interface section (bad idea, really) that means that every RTL and VCL unit using system.sysutils needs to be recompiled in addition to your own units and the resulting dcus need to be put in a folder where they replace the dcus that come with the Delphi installation. And remember that said installation has different dcus for debug and release and different platforms, something D7 did not have. Best reevaluate the original cause for this change in D7 and see wether you can avoid it in D11 completely.