Mark-

That path was correct. I tried a few paths to be sure I was not wonky. I did not try any further. The goal was to convert AVIF files to BMP. I have a sub directory for "tools" that are not needed inside the main application. So, I created a very short application, no user interaction, put it and the four dlls in the "tools" directory and call the application from the main application to get the file conversion done. Thanks for your help.

Thanks I did not think it would work. Also testing shows, if all the dlls are in the exe path, all works as expected. Setting all functions to delayed and calling SetDllDirectory before any function is called, it fails, on the first call to the main dll, with: I tired several path options, no joy. Thanks for your help.

Thanks. That is what I thought. When exploring options I looked at "delayed". I will give it a go. I also wondered if I declared one function from each of the three dlls, (required by the "main" dll) and, used static linking for the the three dlls, if that would work.

Hello, Testing the AVIF image code (https://github.com/Xelitan/AVIF-and-HEIC-for-Delphi-Lazarus/) and have a question about dlls. (https://en.delphipraxis.net/topic/9060-anyone-know-of-an-avif-image-decoder-for-delphi/?tab=comments#comment-106499) The code uses static dll linking: const LIBHEIF = 'libheif.dll'; function heif_context_alloc: PHeifContext; cdecl; external LIBHEIF; I want to put the dll in a sub-directory of the exe, I use: const LIBHEIF = '.DLL\AVIF\libheif.dll'; That works for the “libheif.dll” but, not the other three dlls that are used by “libheif.dll”. When running that application, I get: “The code execution cannot proceed because dav1d.dll was not found. Reinstalling the program may fix this problem.” for the other three dlls. Question one, is there a method to have the other three dlls use the path of the calling dll? Question two, if I go to the trouble of modifying the code for dynamic linking for the “libheif.dll”, would it solve issue? I assume it would not. Ideas? Thanks, Mark

Hello, Old thread back to life. https://github.com/Xelitan/AVIF-and-HEIC-for-Delphi-Lazarus/ Anyone used it? Thanks, Mark

Thanks for your help.

Like MessageDlg the dialog (MessageDlg2) resizes based buttons, button captions, based on OS language, font size, etc., and it was cleaner to use a panel. TLabel, at least, had other issues to overcome. Drawing on the form, I had not thought of that solution. Good idea. I had the framework for a custom panel, from another form, so I grabbed it. For now, because the only issue is the "Windows" style, window color, I check for it when fetching the window and font color, Down the road I might look at drawing on the form. It is an interesting, and perhaps a cleaner, solution. Thanks for your help Remy.

I "FillRect" the canvas of the panel, with the color returned by the style manager. There is not a label. I DrawText the text on the canvas. Amakrits style works.

Yes. ParentBackground state made no difference. The form color is set to clWindow.

The text is drawn on a TCustomPanel. The custom panel is on the form (TForm).

Sure.

You mean what all the other styles return, I guess I am confused. Perhaps I am all wet, 10 are correct, one is incorrect; the 1 seems to be the issue.

See the examples above. Correct as in the color returned is the same, or not, as the color of the window.

Thanks for the response. The issue is: bgColor:=actStyle.GetStyleColor(scWindow); returns the correct color for all styles I tested, 10 or so, except one, "Windows".

Thanks for the response Remy. OK I can trim down the code. The text is drawn on a TCustomPanel. I am creating the dialog to replace MessageDlg. Styling is the last test. What confuses me is TUxThemeStyle.DoGetStyleColor(scWindow) works for all styles I tested, 10 or so, except one, "Windows". So, I will test with using another selector. I tested all the selectors, above, with Ruby Graphite and all returned the wrong color: Interesting...