PeterBelow

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.

Looks like the design-time package in the D11 folder (22.0 is the folder for that version) is in fact the version for D12, that is, should be in the 23.0 branch. But it may also be the correct version but tries to load a run-time package from the wrong folder. That is a common problem if the packages are not named properly with a version tag (280 for D11, 290 for D12). Run-time packages are loaded using Window's search strategy for DLLs (since they are DLLs in fact), which includes searching folders on the PATH. If you have several RAD Sudio versions installed each will have its BPL folder on the path, so the search may find the wrong version of a package if they all have the same filename. A possible cure is to move the run-time package in question to BIN folder of the matching Delphi version (where bds.exe resides), since Windows searches that folder first. Another is to start the IDE not via the start menu links the installer created but from a batch (cmd) file where you first redefine the PATH to only contain the folders for this Delphi version. Oh, and if you can rebuild the packages you can of course change the project options to use the proper version tags for the produced binaries.

If the DLL is COM-enabled you can use the Component -> Import component dialog from the IDE main menu: A pure .NET assembly without COM support cannot be used from Delphi with the tools available out of the box, but there are 3rd-party libraries available, some freeware. A google search for "host the .net framework in delphi" turns up this for example. I have no personal experience with such libraries.

Have you configured the IDE to load the last open project at start? The message may be caused by a corrupted dproj file. If you get the error without loading a project check the registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Embarcadero\BDS\23.0\Personalities. It should look like this: Depending on your licence you have more entries, but the one after "(Standard)" is what counts here. There is a matching key for the current user: Computer\HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\23.0\Personalities. It should have the same content.

The reason is quite simple: the component is based on a Windows common control which is intended to serve as storage for small images/icons used for menu items, buttons, listview items. To reduce the consumption of GDI handles the control merges all added bitmaps into one large bitmap for storage. That's the reason all bitmaps added are forced to the same size, this way the imagelist can calculate where on the combined bitmap each image resides and then paint that part to the target location. There is a maximum size to a GDI bitmap, so this puts limits on the size and number of the images you can put into a TImagelist. Looks like the control is simply not suitable for your task.

Stretching bitmaps to a larger size (e.g. a 16x16 bitmap to 64x64) has this effect. The Windows API function used by the VCL is not very good at reducing the unavoidable degradation in image quality by interpolating the new pixels added between the original ones. You get much better results using vector formats like SVG as source, which can be rendered to practically any size without quality loss as long as the aspect ratio is not too far off the original. For bitmaps used for UI elements (buttons, menus, listview items etc.) Delphi offers TImageCollection and TVirtualImagelist. The former can store multiple versions (different sizes) of an image and the latter is used to then pick the best fitting version for a particular screen resolution.

Works for me without problems (Win32 project with debug build, halted on a breakpoint). But dcc32270.dll does not belong to Delphi 12.1, that uses dcc32290.dll. 270 would be Delphi 10.3 if memory serves. Check the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Embarcadero\BDS\23.0\Debugging\Embarcadero Debuggers\Evaluators, that names the defaullt debug evaluator.

Depends on what you need to compare for. Equality is easy, that is a simple memory comparison. Larger/smaller implies a collation sequence, which is language-specific. Here converting to UTF-16 first is, in my opinion, the only practical way. Same if you need case-insensitive comparison, since case conversion is also language-specific and may not be applicable for the language in question at all (e.g. chinese).

Consequent use of interface references (with rerf counting for lifetime control) instead of object references avoids that problem completely.

Oy, that's a really open-ended subject. The RAD approach (using data-aware controls and connection/query components you create and configure at design-time) gets you results (= working application) fast but it tends to get messy fast as well, with business logic mixed into form and data moduls, poor reuse of code (unless you plan well ahead). This approach makes proper separation of application layers harder and is excellent at producing apps that are a nightmare to maintain and document. Code can be written to be self-documenting and serve as source for project documentation as well, but how do you deal with all the stuff set at designtime and scattered across dozens or even hundreds of dfm files? In my opinion RAD is workable for smaller projects with a few database tables and a few forms as well. For anything more complex and expected to have a lifetime of many years with frequent updates it pays to use a proper layered approach (e.g. model-view-controller or similar), with a object-relational mapper (ORM) as interface to the database and a client UI that works with data objects instead of directly talking to database tables, queries, or stored procedures. All the FireDac stuff would be hidden inside the ORM. Unfortunately Delphi does not come with an ORM, but there are some 3rd-party offerings in that area, including open-source projects like MORMOT. The learning curve can be steep if you have never dealt with such a design before, but it is worth it IMO. I wrote my own ORM for a larger project at work 20 years ago, took about half a year (part time, programming was not my main task) since nothing suitable was available at that time. It has served me well and some of the programs are still in some use... As for partitioning the app into modules that can be maintained independently: that is what packages are for, but it is not as straightforward as one would hope. It's DLL hell in disguise and you have to invest some serious though into how you partition your application. Packages are all or nothing, every unit used can only be contained in one single package. All other units requiring such a unit have to get it from the (shared) package, so you have to deploy not only your own packages but also all used RTL and VCL (or FMX) and 3rd-party packages. As long as you do not change anything in the interface part of a packaged unit you can replace the build package in the production app with an updated package. If you change an interface you have to rebuild all packages using the modified one, plus the host app. Since forms etc. are declared in a unit interface that severely limits what you can change in such a form unit without major hassle. Note that this applies to units you want to use from other packages directly. It does not apply to units only used internally by a package. So it is possible to achieve a better isolation of modules if the only exposed part is a factory function for an interface the host app then uses to talk to the internal stuff of the package. In this scenario you can get away with only building with the core RTL and VCL packages and one shared package declaring the interface types used, and actually you can use DLLs (build with packages) instead of full-fledged packages. But this can still degenerate into a maintenance nightmare if you are nor careful...