Die Holländer

I view console applications not just as user (prompt) programs, but also as tools for performing tasks that just don’t require a GUI. We have numerous console applications that are often started by a task scheduler or installed as services. These programs are hard to write with scripts alone, which is why we use Delphi and its tools and libraries. (such as FireDac, sFTP and the mORMot HTTPs web server). These applications handle all the automated processes and tasks essential for our company. All the code can of course used in other projects for GUI or console applications.

In Delphi you just declare the unit where the functions you need are declared. For example Remy mentioned BoolToStr https://docwiki.embarcadero.com/Libraries/en/System.SysUtils.BoolToStr So, this function is in the System.SysUtils unit. In Delphi you can access that unit by declare it on top of your code: Uses System.SysUtils Now you can use the BoolToStr function in your code.

Console programming is easy with Delphi. The books will learn you the Delphi (Pascal) syntax and that is one of the most easy to learn of all the programming languages. That was dummzeuch's conclusion already 10 years ago: twm's blog Important : Console with parameters (With a Gui example..)

Its weird, but maybe it is something that is declared into the source of the Chart component. In my projects i managed over the years to get all the 3th party components without source out of the applications, apart from some of the native Windows. I would try to separate the form(s) with the Chart component from the application and continue the conversion of the application to the newer Delphi version. You can always try to compile the chart form as a separate application and create a communication with your main program to display the charts, like using the Windows Message system or creating a DLL.

Can you look into the TDBChart Unit code? I see in my version D12.2 that it is not installed as a default component..

For me its not a big problem. I already working a few months with it and I don't have to change the width of these panels. I noticed that in the debug layout it is working ok but it has also a minimum width.

The only way is to close it by that little pin. Then when you press on the closed inspector tab it slide open and you are able to make it smaller. But i find it nicer to have it open all the time..

Resize inspector.mp4

In my case when i make it large, like half way the screen, then I can make it only serveral times a tiny smaller, untill it reaches that strange minimum width..

I've the same behaviour. (D12 update 2) Also the Palette and Project ones does this. They are on both sides of the screen with the Palette under the inspector. (They use the same splitter) Lucky I saved my IDE desktop with the proper widths, so I can get them back to my default widths. I don't know why, but that doesn't make you dumb..

Bit offtopic but.. Internally, we use OneNote for creating help files and application overviews, such as screenshots of forms with explanations. For us developers, who don’t have dedicated manual writers, OneNote is particularly useful because it can be shared across the network. This allows everyone to contribute additional information and screenshots to the pages. Each page is accessible via a unique GUID, enabling us to link a help menu item in Delphi directly to a specific OneNote page using ShellExecute. Over time, with continuous edits from users, these pages have become very helpful.

Maybe one of these LLM answers can give you some clue.. 1. DLL Entry Points and Initialization - **Check the DLL's initialization code:** When the DLL is loaded, it executes its initialization code (like `DllMain` in Windows). Make sure that the DLL does not have any dependencies that might be failing to initialize. If the DLL attempts to access global variables, specific configurations, or other resources that are not set up correctly due to the complex app's environment, it might lead to an access violation. - **Library Conflicts:** If the DLL relies on other libraries (DLLs or packages), check whether those are being loaded correctly in the context of the complex application. 2. Runtime Library Differences - **Delphi Runtime Compatibility:** The new Delphi 12 runtime libraries might not be fully compatible with how the complex app was built in Delphi 5. Make sure you’re using runtime libraries in your complex app that are compatible with both the environment it was built in and the DLL. - **Compiler Directives:** Check if your complex application has specific compiler directives that might affect memory management or other runtime settings. 3. Project Settings - **Memory Management Settings:** There have been changes in Delphi regarding memory management across versions. It’s possible that your complex Delphi 5 application is still using a legacy memory manager. If your DLL was compiled in Delphi XE, it may expect a different memory management model. Make sure that both applications (the complex one and the DLL) use the same memory manager settings. - **Undefined Symbols:** If your complex app has issues with undefined symbols or might not be properly linking certain required libraries, this could be causing the access violation when trying to load your DLL. 4. Versioning Issues - **Runtime Package Issues:** Ensure that the application and the DLL do not have mismatched version dependencies on any runtime packages. Sometimes migrating code from older Delphi versions to newer ones introduces package version discrepancies that can lead to ABI issues. - **Conditional Compilation Flags:** Make sure you check for any conditional compilation flags that might affect how the DLL behaves when loaded from the complex app versus the simpler test app. 5. Diagnostic/debugging strategies - **Debugging the DLL Load Process:** Since you cannot modify the DLL itself, consider using tools such as Dependency Walker or Process Monitor to check what resources the DLL is trying to access when loaded by the complex app. These tools can provide clues if it’s trying to access a file or resource that isn't available or accessible. - **Logging:** If possible, add logging to the DLL load process (if you can do it through some means, like modifying the loader or using external logging). This would help identify where the access violation occurs specifically. 6. Running Environment - **Environment Configuration:** Check if the environment from where you are launching the complex application is different from where you are launching your test application. Different environment variables or configurations could also impact loading behavior. 7. Compatibility Mode - **Run in Compatibility Mode:** Consider running the complex application in compatibility mode for an older version of Windows (like XP or 98) to check if there are any odd behavior issues related to the OS.

Since you wrote that a small D12 app can access the DLL, maybe you can start a new D12 project to get rid of the old project files (dpr, dproj, res, dsk, ..) and project settings. Then add your forms and units from the old application on it.

Make a small form with only the TImage and create it on top of the parent TDrawGrid form.