JonRobertson

I am not sure what you are comparing. PDFFonts.pas on github does not have different versions of the source units by Delphi version. There is only one PDFFonts.pas. SysUtils not being in the uses clause of PDFFonts.pas would not cause the issue that you are seeing. If SysUtils is needed by PDFFonts, a compile error would occur when building the component package or compiling any unit that references PDFFonts. It is also possible that SysUtils was moved from the interface uses clause to implementation, or vice-versa.

Open PReport.pas and add PDFFonts to its uses clause. I'd suggest after PdfImages: PdfImages, PdfFonts {$IFDEF USE_JPFONTS} Close PReport.pas. Open the DelphiPowerPDF group project and do Build All. If you don't have the group project, build PowerPDFDR followed by PowerPDFDD. (Building PowerPDFDD should not be required, but I always build run-time followed by design-time when rebuilding packages.) Now go back to your project and see if you can add a TPrPage without getting the exception.

Actually, that would only solve a run-time exception. If the exception is occurring in the designer, then the code that registers the components in the IDE is not registering the PDF font classes.

Windows fonts are not represented as individual classes in the Delphi VCL. This error is occurring because PowerPDF is trying to create an Arial class implemented by PowerPDF. The actual class name is TPdfArial. It is registered in PdfFonts.pas. My guess is the design-time support in PowerPDF is lacking and that the unit PdfFonts is not added to the uses clause when you drop a TPrReport on it. (I do not have PowerPDF installed to test.) If PdfFonts is not in your uses clause, add it and then try adding/dropping a TPrPage on the form.

The Graphic property does not represent the "type of graphic". Think of it more as a helper class that is capable of loading multiple graphic formats. The only "conversion" is unpacking the image file format, such as color depth, color map or palette, compression, etc, to a Windows Bitmap GDI object. Once an image is loaded, SaveToFile or SaveToStream may be used to write the image to a different format. Yes. If you look at the source for TPicture.LoadFromFile, you will see that it internally uses TGraphic to load an image. Looking at the source code is an excellent way to find answers, particularly if the documentation seems lacking or confusing. They are used the same way. Depending on the file type you have loaded the required object is created. To expand a little, loading an image only creates one instance of a graphic class. Bitmaps, icons, metafiles, and WIC images are not the same type of image. Try loading a TImage with a PNG (Image1.Picture.LoadFromFile('image.png')) and using the Icon property to save it as an icon (Image1.Picture.Icon.SaveToFile('image.ico')). The exception "Icon image is not valid" will be raised. However, using Picture.SaveToFile('image1.ico') does work, at least in the test that I did. Random flounder is an excellent way to learn. Create a new VCL project, throw a TImage on the form, and try various things to see what works and what doesn't. Take some time to look at the underlying source code. Start with Vcl.Graphics.pas for the foundation, then look at the Vcl.Imaging units, such as GIFImg.pas, JPEG.pas, and PNGImage.pas. That is what I did while writing this message.

Once you add pngimage to the uses clause of any unit, the TPNGImage class is registered with TPicture, which enables your application to load and save PNG images. This is done in the initialization section of pngimage.pas (TPicture.RegisterFileFormat('PNG', 'Portable Network Graphics', TPngImage);). This provides PNG support to any class that uses TPicture to load or save impages, for example: TImage.Picture.LoadFromFile. If you want more control over the image itself, then declare and use an instance of TPNGImage and the provided methods and properties to load, save, or modify the PNG image as desired.

I found a demo project at https://github.com/Walibeiro/DockDemo. And a 9 page article that Brian Long wrote, titled Drag & Dock, published in issue 63 (November 2000) of The Delphi Magazine. I did not find anything more recent. I don't recall any significant changes to docking in the Delphi VCL. It has also been 9 years since I worked on an application with dockable forms.

The Delphi compiler is also a single pass compiler, unlike C/C++. Being a single pass compiler is one of the reasons that Delphi builds projects much faster than a similar C++ project. I would expect changing Delphi to support multi-pass compiling would be a huge task with few benefits. But I don't know much about writing a compiler.

It may very by Delphi version. $(OUTPUTFILENAME) worked for me in Delphi 11.3.

You could try a pre-build event as a workaround: CMD /C DEL $(OUTPUTFILENAME) If your output path or filename has spaces, try CMD /C DEL "$(OUTPUTFILENAME)"

As does the Delphi debugger.

Or build the desired applications using C++ Builder?

You don't "set" it. You launch it. Click the Windows Start Button and either expand the Embarcadero Delphi group, or type "Delphi" or "DPI" or "Unaware". One of those should reveal an icon for Delphi (DPI Unaware). If you launch BDS.exe by another method, add /highdpi:unaware as a command-line parameter.

Perhaps it was a request (in Delphi 13) for a new VCL combo box control that is not a subclass of the Win32API COMBOBOX class.

I recently came across a company online developing AI "clones", and decided to ask an "Abraham Lincoln clone" the question "Why do you believe you were assassinated?" After giving a three or four paragraph response that I would expect from documented history, the AI then asked me what circumstances led to my assassination. That isn't artificial intelligence. That is a complete lack of intelligence.

Yep, I fought that headache even as a solo developer on a project. My dev machine is a laptop. The laptop's display has a different recommended scaling than the monitors attached to my docking station at the office. I would get so frustrated during commits because I only commit intentional or needed changes. I do not want commits littered with changes to Left/Top/etc due to the form designer running at a different scale/dpi. All of that headache thankfully went away after I discovered DPI Unaware mode.

Genuine question on HighDPI. So far, working in DPI Unaware mode works well for me. As long as the run-time handles scaling "correctly". Since switching to DPI Unaware mode, I have not needed to write (or borrow) workarounds for HighDPI issues. Are there scenarios where designing in HighDPI would be beneficial? Just to improve the development experience or to improve the user's experience when using the produced app?

Try https://my.embarcadero.com/, login, and then My Downloads (icon/button on left that looks like a cloud with a down arrow inside).

When I code any Office app automation in Delphi using the bundled wrappers, I use the more recent one. There may be a reason to use the Office 2000 wrapper. But I've never had a reason to use the older version.

Has anything changed in the Delphi environment between the "original compiled dll" and the one you are testing? Such as version of Delphi and any third-party components? Is the DLL interfacing with Word through COM Automation? If so, are you using the component wrappers included with Delphi or something else? Are your tests with "original dll" and new dll each talking to the same version of Word on the same machine?

I came across this while searching for something completely different. Although an old thread, I have a suggestion (if you have not already tried): Change your program to create .bat files in C:\coboldev to do a batch compile, say 50 compiles per batch file. Launch cmd.exe and pass it the name of the batch file. Monitor for completion, as you mentioned previously. Or have cmd.exe exit upon batch completion (cmd.exe /c comp01.bat) and wait for the created process to end. Perhaps have 10 cmd.exe processes running simultaneously performing batch compiles. And delete each batch file once the process completes. This may solve the slowness cause by the AV scanner, if it is having fits about separate processes being created for each launch of ccbl32, but not when launched several times by a single process. You could also try using a language/tool more powerful than cmd batch, such as PowerShell or Python, to prompt which folders to compile and launch ccbl32 for each file. Or roll your own CI by comparing timestamps of the source against the most recent compiled module. Or try a tool like Jenkins. Lots of options.

Using AInitialCount and AMaximumCount values of 1, the semaphore may only be acquired "one time" and other calls to Acquire will block until the semaphore has been released by calling Release. You could call GlobalSemaphore.WaitFor(1) and check the result for wrTimeout. But that only tells you that the semaphore was already acquired when the call as made. The semaphore could be released, and possibly acquired by a different thread, before you called Acquire again. I hope that makes sense.

You want to look for Vcl.ExtDlgs.* and Vcl.Dialogs.* Do you recall modifying either Vcl.ExtDlgs.pas or Vcl.Dialogs.pas? Do you have multiple versions of Delphi installed? Are your library and search paths set correctly? The compiler is finding versions of those two units that are not compatible. This primarily occurs when the interface section of one unit does not match the interface that the other unit was compiled against.

Take a look at PrintWindowExample. I opened the project in D11, hit F9, and it worked. It does not take a screenshot of the current app, but hopefully it will help you with your code.

I do not see it in standard Delphi RTL/VCL units. However I did find it defined elsewhere. const PW_CLIENTONLY = $1;