Anders Melander

The kiss of death. Apart from I don't see it happening. What would "the VCL" use it for?

Ok then, imassumingthatthisisaWM_PAINThandler.ifnot,thenyouneedtoreadtheBeginPaintdocumentation.ifitis,thenthere'samissingcalltoEndPaint.youarealsonotusingtheinformationinPAINTSTRUCTfilledoutbyBeginPaint. andfinally,youstillhaven'ttolduswhattheactualproblemis.

Is it too much to ask that you make your code readable if you're asking other people to spend their time reading it? There's a whole bunch of stuff missing from the code you posted. So much that there's not much point in trying to figure out what problem you're having (you might also have stated that. we're not mind readers).

That's great! However, as far as I can tell, there's no documentation to explain this behavior. A bit unfortunate, to say the least. Or maybe I'm just not understanding how association arrays work. I have already updated my code to support registration under HKCU\Software\Classes instead of HKCR. I will update it to also add the SystemFileAssociation keys.

ShellExView seems to be having problems reading the registry entries related to my Property Sheet Handler (this is on both Windows 7 & 10):

I've now compared the log from Windows 7 and Windows 10.somethingsomething. I searched for "arw" in both logs. What stands out is that on Windows 7 the Explorer primarily uses the registry keys we're expecting; The documented ones. For example, it looks for (and finds) the property sheet handler in HKCU\Software\Classes\arwfile\shellex\PropertySheetHandlers and HKCR\arwfile\shellex\PropertySheetHandlers. On Windows 10 however, things are a bit different. Notably, it never looks for *arwfile\shellex\* Both Windows 7 and Windows 10 look for (and don't find) HKCU\Software\Classes\SystemFileAssociations\.arw\shellex\PropertySheetHandlers and HKCR\SystemFileAssociations\.arw\shellex\PropertySheetHandlers. They also read the more general keys HKCU\Software\Classes\*\shellex\PropertySheetHandlers, and HKCR\*\shellex\PropertySheetHandlers and Windows 10 additionally looks for HKCU\Software\Classes\Kind.Picture\shellex\PropertySheetHandlers and HKCR\Kind.Picture\shellex\PropertySheetHandlers. Apparently, the SystemFileAssociations keys are related to something called Association Arrays.

It's about 40,000 log entries on both systems, so it's not a small task. It's worth a try though. One might get lucky.

I just tried (on Windows 10) to: Remove/rename all the non property sheet related registry key/values from the .arw and arwfile registry keys. Copy all the .arw and arwfile registry key/values from HKLM to HKCU. None of this made any difference. I then renamed the HKCU .arw to .xxx and arwfile to xxxfile and was then able to display the property page on a test.xxx file. So my experience now matches yours 😞

I have another application registered to open it by default (PhotoStage), but yes, double-clicking your file in Explorer opens it correctly. Selecting "Properties" in Explorer bombed on the real file. The reason might be that there's another shell extension registered on the file type and that it's this extension that is causing the crash. All this is on Windows 7. On Windows 10 and later the property page is not displayed (and the arw-file is opened in Photo Viewer).

Doesn't work for me either on Windows 10 and later...

Yes, but the property page crashes explorer (endless "invalid window handle" error messages) with an actual .arw file. An empty text file renamed to xxx.arw works fine. I believe this is a problem with the content functionality of the property page, not with the registration and display of the property page (i.e. it's not related to this thread). Sure. I also shouldn't smoke and eat bacon 🙂 I have Windows 11 on my laptop for when I need a reminder of why I still use Windows 7 on my desktop.

Where else would it execute it? Did you expect it to execute the query locally? If you execute the exact same query remotely via FireDAC and remotely via SQL Server Management Studio and they don't perform almost the same, then the problem is most likely the way the data is fetched by the client. I solved a similar performance problem at one time by fiddling with some connection parameters... Here are the screenshots I took to document the difference in performance: Query executed via MSSQL MS: Same query executed via TFDQuery: Try to compare the network bandwith usage of FireDAC vs SQL Server Management Studio when the query execute/fetches, like I did above. Again, they should be almost identical. In the above case, I solved the problem by disabling MARS on the connection. Query executed via TFDQuery on a connection with MARS disabled:

Still works for me: I'm on a 64-bit Windows 7 so it might be the same problem as this: https://stackoverflow.com/questions/34011698/property-sheet-handlers-on-windows-10

I already did. What do you mean?

As I wrote: https://www.google.com/search?q=delphi+graphics+transitions As far as I can tell there's a ton of old transition effects code on Torry.net. No guarantee that it works as-is with newer versions of Delphi though.

My factory overrides GetProgID to return an empty string and TComObjectFactory.UpdateRegistry has this code: if ProgID <> '' then begin CreateRegKey(RegPrefix + ProgID, '', Description, RootKey); CreateRegKey(RegPrefix + ProgID + '\Clsid', '', ClassID, RootKey); CreateRegKey(RegPrefix + 'CLSID\' + ClassID + '\ProgID', '', ProgID, RootKey); end; Yes.

It's registered for a single extension. I'm not using your IShellExtInit implementation at all. I'm using the shell integration classes from the Drag and Drop Component Suite, so here's the full extent of changes I needed to make in order to register the property sheet handler: type TPropertySheetHandlerFactory = class(TDropContextMenuFactory) protected function HandlerRegSubKey: string; override; end; function TPropertySheetHandlerFactory.HandlerRegSubKey: string; begin Result := 'PropertySheetHandlers'; end; const // CLSID for this shell extension. // Modify this for your own shell extensions (press [Ctrl]+[Shift]+G in // the IDE editor to gererate a new CLSID). CLSID_PropertySheetHandler: TGUID = '{1067C264-8B1F-4B22-919F-DB5191C359CB}'; sFileClass = 'FoobarFile'; sFileType = 'File of foo'; sFileExtension = '.foobar'; sClassName = 'DelphiPropSheetShellExt'; resourcestring // Description of our shell extension. sDescription = 'Property Sheet example'; initialization TPropertySheetHandlerFactory.Create(ComServer, TDataModulePropertySheetHandler, CLSID_PropertySheetHandler, sClassName, sDescription, sFileClass, sFileExtension, ciMultiInstance); end. and here's the code to extract the file names (ShellExtInit.Initialize): function TDataModulePropertySheetHandler.ShellExtInit_Initialize(pidlfolder: PItemIDList; lpdobj: IDataObject; Hkeyprogid: HKEY): HResult; begin Result := NOERROR; FFiles.Clear; SetFolder(pidlFolder); // Save a reference to the source data object. FDataObject := lpdobj; try // Extract source file names and store them in a string list. // Note that not all shell objects provide us with a IDataObject (e.g. the // Directory\Background object). if (DataObject <> nil) then with TFileDataFormat.Create(dfdConsumer) do try if GetData(DataObject) then FFiles.Assign(Files); finally Free; end; finally FDataObject := nil; end; end; FWIW, I believe the thing that you were missing was registering the class ID in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved. The 4-space indent and capitalized keywords probably also had a negative influence 🙂 Source attached. PropertySheetHandler.zip

Works for me: I'll clean up the code and post it later...

Did you do any of this?

Should be pretty easy to implement with any of the libraries that can render text along a path. Image32, Graphics32, etc. Are there any particular effects you need, or are you looking at what's available for now?

IMO the restrictions you've put on the implementation seem a bit arbitrary and are getting in the way of the solution. I would definitely go with an out-of-process COM server; It's a piece of cake to implement, it's natively supported by Delphi and you'll get IPC and threading thrown in for free. You could even have the service host it - or have it as a separate component that is used simultaneously from three modules. So why is it a problem that the exe needs to run once (to take care of the COM registration) before the client can access it? If you really can't register the COM server before the modules are run, then just have the modules do it themselves when they are run. No "installation" is necessary when you have complete control of all the components of the system.

Well, at least it told you what happened so you can fix or work around it 🤦‍♂️

It sounds like you already know the answer to that one.

Yes, that's the formal definition of it. I'm more referring to professionalism as an attitude toward solving problems; Don't be lazy is the first thing I try to teach new developers. The vast majority of the work I do is horribly boring, but I don't get paid to write "interesting" code. I get paid to write high-quality code and if that means I have to write yet another damned factory, observer, or visitor class so be it. The effort spent will benefit everybody, myself included, down the road. I'm not against using a tool like ChatGPT as long as it is used as what it actually is.