JonRobertson

I don't agree with this. frmView := TfrmView.Create(Self); frmView.Parent := tsView; This makes the tabsheet the parent of the form. So now all controls on the form have the tabsheet as a grandparent, if you will. But the parent of each control on the subform is not changed to the tabsheet.

My laptop's "recommended" scaling is 125%. At the office, I have two external monitors, each has recommended scaling of 150%. I started this position eight months ago. The first project that I worked on uses a "tabbed interface", similar to web browsers, where each form is created and parented to a TTabSheet. Nothing more than setting frmSomeForm.Parent := tsSomeForm. Every form, except a few "dialog box" forms, are embedded in the app's main form. Two of the forms in that application also contain a TFrame, which is on the form at design-time rather than created and attached at run-time. I have not seen any DPI related issues since switching to DPI Unaware mode when launching BDS.

I would agree that it is easier than using C++, among others. But Delphi is also just as capable of generating executables that overwrite memory or have vulnerabilities, due to poor or improper memory handling. In that sense, I don't think Delphi has better memory safety than C++. And certainly capable of being used to intentionally expose memory related vulnerabilities.

The one difference that I encounter is that a "SubForm" is not linked to anything at design-time. If you have placed a TFrame anywhere in the project, the frame is now linked and "in use" by the designer. I often encounter "has open descendents [sic] or linked modules. Cannot close." dialogs when trying to modify a frame, TDataModule descendant, or a base form (when using form inheritance). This often happens when I try to switch between form designer and DFM text editing. I can close every unit that the editor/designer has open, re-open the "linked" unit, and still can't switch to text DFM. At that point, I could just edit the DFM in my favorite text editor, except Delphi will not reload the DFM once my edits are finished. So I typically restart the IDE. I still use D7 occasionally. While this does happen in D7, and I remember it in D6, there seem to be more scenarios where D11 refuses to switch and D7 doesn't.

Although I've been programming for 42 years, I know so little compared to how much there is to know. So thanks for the link. My preference is to handle/control the lifetime of memory allocations based on the purpose and usage, rather than leaving it to algorithms that attempt to figure that out. The code below is a hand-slap, don't ever do that. It was also the first thought I had to show that the memory manager does not "know" anything, unless it is told. Algorithms may be written to read my mind. But I digress... function BadAlloc(Size: NativeInt): String; begin var pStr: PChar; GetMem(pStr, Size); StrPCopy(pStr, 'bad code'); Result := IntToStr(Integer(pStr)); end; procedure BusyProc; begin var myBad := BadAlloc(20); // lots of other busy code... ShowMessage(PChar(StrToInt(myBad))); end; My expectation is that tracing garbage collection could release the 20 byte block immediately after BadAlloc returns, or any other time before the ShowMessage is executed.

The memory manager would have to "know" when the memory was no longer needed, otherwise it would release allocated memory too soon. Unless I don't understand the question, it sounds like Automatic Reference Counting, which was already attempted. And it was later removed for a few reasons.

I do, and I suspect many others do as well "Promoting tools to help in this area" sounds good. But "Sounds good" is marketing rubbish.

I do, and I suspect many others do as well. What I was mostly disappointed about was the statement below. The company promoted in that link and the accompanying webinar was DerScanner. I watched the webinar last September and it intrigued me enough to ask approval to pursue having a small project analyzed and review the results. Their home page had a short form to request a trial. Instead of providing a trial, I received an email that I will share, since it is typical marketing: I responded that I requested a trial from their home page. The reply was that my request for a trial was forwarded and included a whitepaper that "describes the key features of DerScanner". One of the key features was that DerScanner could analyze 36 programming languages, "even obsolete Delphi, COBOL and Visual Basic 6.0". I also noticed that the short form on their home page was changed from a trial request to "Get a Demo". They did provide a trial account and I submitted the project along with a couple third-party libraries (with each vendor's permission). The resulting report contained thousands of incorrect analysis. One of the more prominent and obnoxious was “hardcoded encryption key”, for code such as "ctrlKey := GetKeyState(VK_Control) < 0", and every other line of code that contained these three characters in sequence: k e y, including static text. The analysis that DerScanner provided was a complete joke and a total waste of time. The trial included two scans for free (I only used one), additional scans after the trial were $1,000 per scan. Sure, my employer can say "Yes, we are concerned about security. We had our application analyzed by a third-party that specializes in code analysis. They used a highly sophisticated tool named grep to analyze our code for vulnerabilities." I am particularly disappointed in the recent statement because I had direct contact with Ian regarding my frustrating experience, and the laugh that I had after reviewing the generated report.

My thought is that it is already too easy for code to be scattered rather than organized. At times, I get flustered trying to find my own code, let alone working in a code base that I didn't write. And the impact on the Delphi compiler and "breaking interface changes". When a change is made in the interface section of a unit, other units that depend on the change must be recompiled. But when changes are made only in the implementation or other sections of a unit, dependent units don't have to be recompiled. The compiler tracks these dependencies automatically and recompiles units only when necessary.

Not for me. I'd want a compiler option to turn it off. But that wouldn't prevent others from using it.

VirtualBox User Manual - Snapshots

I would suspect it depends on your usage and needs. I used to configure and manage VMs for a dev/QA test environment, initially using VirtualPC and later migrating to Hyper-V. Today I do not use VMs as often as I used to. I use Parallels Desktop on my MacBook Pro and VirtualBox on my other laptops.

Ping @Allen@Grijjy ? Have you tried using it? Per Getting Started, "To use GrijjyCloudLogging in your Delphi project all you need to do is include the Grijjy.CloudLogging unit in your uses list."

Does it occur again on the same project? DCUs are Delphi version specific (with a couple of notable exceptions). If Delphi 12 successfully your project after you manually deleted DCUs, but this error occurs again in Delphi 12 building the same project, then something is wrong. Perhaps something is off with your Delphi 12 install or environment. Or perhaps it is a defect in the compiler. Open a support ticket as DelphiUdIT suggested. An online search reveals a couple other things to try in the meantime. If it is a large project, go to Project Options, Building, Delphi Compiler, and set "Use MSBuild externally to compile" to true and see if that helps. Another suggestion is to disable the compiler's use of an unit cache. This is done by modifying the registry entry HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Compiling\Enable Unit Directory Cache.

Not on my system. A simple grep of 51,132 .pas files tells a different story. (Just a whole word search with no context). pointer, 150,825 hits in 7,939 files ^, 110,934 hits in 6,326 files Searching a few more popular (and current) open source libraries reveals significant use in current code. 8,625 hits was the highest I found in a single open source library on my system. Delphi 12 source\rtl\sys - 2,837 hits. 1,871 hits in system.pas alone. Delphi 12 source\rtl\common - 2,951 hits Delphi 12 source\rtl\win - 6,442 hits. I was surprised to see 2,243 of those are in the winrt subfolder. Delphi 12 source\rtl\osx - 4,751 hits Then there are thousands of casts using TObject(), such as storing object references in the legacy TList or, ahem, storing references or pointer values in TComponent.Tag. If I overlook RTL usage, VCL usage, and poor coding practices, every day Delphi coding uses pointers. At least I do. // lstOfItems is a pointer. You may say it is a "typed pointer", but it is still a pointer. ;) var lstOfItems := TStringList.Create;

From the docs, KeepDesignConnected is not about auto connecting to the design-time connection. If the project is built with Connected set to True, then loading the form/datamodule/components will set the property's state to True when the form is loaded, making (or trying and failing) to make the connection before your code starts. That is standard VCL component behavior for published properties. By setting KeepDesignConnected to False, the component will not make a connection during form load, even if the Connected property was saved as true. There are several other workarounds. There are add-ons that will set various property values every time the form is saved. Personally, I derive a component and change the stored attribute of the property, like so TmyADOConnection = class(Data.Win.ADODB.TADOConnection) published property Connected stored False; property LoginPrompt stored False; end;

Same LOL here. My first reply would have been much shorter had I paid attention to the forum. One of the dangers of reading from Recent Activity, I suppose.

I have not heard of VTK and decided to take a peak. The documentation references examples using MFC and C++ Builder. However, the Win32 folder is no longer present in the Examples\GUI folder in their git repo. Searching the history of the repo, the C++ Builder examples were removed five years ago. I suspect getting support for using VTK in Delphi will be challenging, since the group stopped supporting C++ Builder years ago. That said, the old code is available via git history. For example, vtkBorlandRenderWindow.cpp. This snippet is from GetRenderWindow: // Stuff the renderwindow into our window FRenderWindow = vtkWin32OpenGLRenderWindow::New(); FRenderWindow->AddObserver( vtkCommand::AbortCheckEvent, FAbortCallback); FRenderWindow->SetParentId(Parent->Handle); Without a deep dive into the source, it appears VTK is using OpenGL for rendering and setting the OpenGL's window parent to a form. If I wanted to use VTK from Delphi, I would attempt: Use a supported open source C++ compiler to build the C++ source to either OBJ or LIB. There are multiple OBJ file formats. Delphi can link with OMF86 or COFF for 32-bit and ELF or COFF for 64-bit. See Link object file (Delphi) for more details. Translate the VTK headers to Pascal, which will be a challenge. From what little I have read, VTK appears to use features only available in newer versions of C++. There are some open source projects for converting headers, although they may not be able to convert the VTK headers. The second one specifically does not convert C++ headers. I included it because it uses libclang, which I suspect would provide a better translation for the "pure C" portions of headers. https://github.com/yunkot/HeaderParser https://github.com/neslib/Chet There are others. Search engines are your friends. ;) Well, most of the time. Another alternative is Python4Delphi, since VTK can be used from Python and appears to actively support use from Python. An advantage of this approach is the ability to "prototype" using standalone Python and then incorporate into a Delphi app via Python4Delphi. You have likely seen Pyscripter's posts in this forum. https://github.com/pyscripter/python4delphi

I have heard or read many "justifications" for dismissing Delphi, but never that one. That said, DevExpress does have excellent components. I currently do not have the privilege of a license for any. Thank you for pointing out TdxLayoutControl , along with the video. I need to spend a little time to put together a proposal, I suppose, for my managers.

I found FortesReport Community Edition on GitHub. The only documentation that I saw is in the source code and is in Portuguese. Or you could roll-your-own. There is some example code in this StackOverflow answer: https://stackoverflow.com/questions/7496813/print-a-tdbgrid/7500147#7500147

If you are referring to persistent fields added via the Field Editor IDE window, the compiler will only complain if you update the field list after you update a query. If the query is changed and no longer returns one of the persistent fields, or returns a different data type for a persistent field, the code will still compile. Those "errors in dependent code" will not occur until run-time.

The error "42S22 Unknown column" is not coming from the Delphi compiler, MyDAC, or the underlying TDataSet. It is coming from MySQL. From an online search, the error means that the field specified (FILEVERSION) in the field list of the SQL statement is not a column in the table. https://sebhastian.com/mysql-unknown-column-field-list/ When you call MyTable.Open, MyDAC is generating a SELECT statement based on the fields that you have added to your MyTable component. That SELECT statement has FILEVERSION in its field list. When executed by MySQL, the unknown column error occurs. I don't know if the following will work with TMyTable, but it might since TMyTable has TDataSet as an ancestor. Drop another TMyTable component on the form or datamodule. Set its properties to the same connection, database, and table as your current TMyTable component. Double-click on the new TMyTable component. If a fields window appears, right-click it and select Add Fields (or press Ctrl-A). When the Add Fields dialog appears, is FILEVERSION in the list? Using the debugger, ShowMessage, or logging, verify at run-time that the Connection and Database properties on your MyTable component are set to the expected values.

Is the report's pipeline a TppDBPipeline? If so, add a BeforePrint event handler to the TppReport component. In the event handler, call Dataset.First on the master/primary dataset used by the report. I do not have 22.04 available to test whether that is an issue. With 22.03, the dataset is Eof after the report is exported and attempting to generate or export the same report a second time results in an empty report. I would expect you would have seen some dialog informing you of an Access Violation before you tried to debug, unless there is code in your unit that is "eating" exceptions (an empty except/end block). Looking at RequestPage in 22.03, my first thought is that a pipeline, datasource, or dataset is being destroyed before the TppReport component is destroyed. In the unit containing the line CustomReport.PrintReport, is there any code that calls Free to destroy an object?

Or US-CERT advisories from DHS. The advisory below may be 9 years old, but the Delphi language/RTL/VCL is as memory safe today as it was then. Possibly less safe. https://www.coresecurity.com/core-labs/advisories/delphi-and-c-builder-vcl-library-heap-buffer-overflow

I installed PowerPDF in Delphi 12 from GetIt Package Manager. Delphi 12 locked up on me due to LSP not responding. I killed that, Delphi 12 closed, and I went to try again. When I opened Delphi 12 again, the PowerPDF components were installed (despite the earlier lockup). I dropped a PReport on a form, followed by a PRPage, and the IDE showed the same "Class Arial not found" message that you have. I opened PowerPDFDR.dproj, opened PReport.pas from the Project Manager, and added PdfFonts to the uses clause (as suggested above). "Build" PowerPDFDR,dproj, "Build" PowerPDFDD.dproj, "Install" PowerPDFDD. I am now able to drop a PRPage on a form without error.