GPRSNerd

In file CCR.Exif.BaseUtils.pas you have to change the following lines: From function Realloc(var NewCapacity: Longint): Pointer; override; To function Realloc(var NewCapacity: {$IF CompilerVersion >= 35}NativeInt{$ELSE}LongInt{$IFEND}): Pointer; override; {$IF CompilerVersion < 33} protected {$ELSE} public {$IFEND} And From function TMetadataBlock.TDataStream.Realloc(var NewCapacity: Longint): Pointer; To function TMetadataBlock.TDataStream.Realloc(var NewCapacity: {$IF CompilerVersion >= 35}NativeInt{$ELSE}LongInt{$IFEND}): Pointer;

Where did you put this additional code? In the component or in the program in the FormShow() or FormCreate() event?

Yeah, it was reproducible. I added a functionality to switch the embedded styles in my app on runtime. When I start the app and switch styles and in this procedure once the default Windows style was set, then the app throws the exception on close. It is not necessarily the "Windows" style which has to be set last before closing.

I can confirm that Delphi 11.3 has the issue fixed. No more exception on close when the default style "Windows" was used/changed during runtime.

Here are two bug reports that seem to describe the issue above: https://quality.embarcadero.com/browse/RSP-38114 https://quality.embarcadero.com/browse/RSP-39197 Both may have been fixed in Delphi 11.3 released today. I will check that after installation.

Hi, did you find a fix for your problem? I've exactly the same problem with one application, exception logged with madExcept: exception number : 1 exception class : EAccessViolation exception message : Zugriffsverletzung bei Adresse 004090BC in Modul 'NikonDecoder.exe'. Lesen von Adresse 0030FFF0. main thread ($4cd0): 004090bc +04 NikonDecoder.exe System 67 +0 TObject.InheritsFrom 00408fa6 +0e NikonDecoder.exe System 67 +0 @IsClass 007104bf +43 NikonDecoder.exe Vcl.Styles TStyleEngine.DoUnregisterStyleHook 00710716 +1a NikonDecoder.exe Vcl.Styles TStyleEngine.Notification 00667aef +f3 NikonDecoder.exe Vcl.Themes TCustomStyleEngine.UnRegisterStyleHook

Hi Angus, thanks for the heads-up, it's working now again. Thx, Stefan

Hi, seems that the svn servers (http://svn.overbyte.be/svn/ics/trunk) are down since 9 Apr. TortoiseSVN complains about "host unknown".

I'm using a tweaked version of ZipTV 2009.6.15, AFAIK that is from 2009. I've given up contacting the developers years ago, as they have gone out of business, also AFAIK. You should better use components that are currently developed, maintained and supported. AFAIR there was even a CVE on the components in the past.

Using it with Delphi X.4.1 Sydney, works fine, but just in 32bit apps, haven't tried 64bit.

Do the ShellControls come with two packages, one for runtime and one for designtime? Have you opened the runtime package instead of the designtime package and tried to install it? This works only for designtime packages.

Probably nobody will help you with this by Teamviewer or similar. You better copy the errors into the thread here, so that we can help you. ccr.exif works like a charm here with Rio and all predecessors for years.

Check my older RSP, that has an easier workaround: https://quality.embarcadero.com/browse/RSP-24070 Just load the corresponding color again with StyleServices: be2.Color := StyleServices.GetSystemColor(be2.Color);

Hi Remy, could you explain how to use the version from the git repo then?! As the Indy components are part of the Delphi standard installation, I guess they must be swapped somehow... Thanks, Stefan

Here's one of many: https://quality.embarcadero.com/browse/RSP-22230

Check the linefeeds of your source file. When you have a mix-up of CR and/or LF this might happen. Also errors when compiling show on the wrong line number and other spooky stuff...

Known problem with Rio 10.3. There are several unfixed bugreports at Embarcadero.

Programmers jokes, there exist a couple of these "HEX speak" or "magic number" addresses: DEADC0DE, DEADBEEF... https://en.wikipedia.org/wiki/Hexspeak I use them as constraints in unittesting to check that a peer or protocol is using the expected values. So the programmer wants to tell you something...

OK, figured it out myself. dcc32.exe -> dcc32compiler.exe dcc32.de -> dcc32compiler.de I've left dll and jdbg as original and it works.

Hmmh, the current set of files for 32bit is named slighty different, as a suffix is used: dcc32.exe dcc32260.de dcc32260.dll dcc32260.jdbg What do I have to rename them to exactly?

Same happens here as well, you have to resize it everytime the IDE is restarted.

So that it is also ignored as all the other high voted bug reports, that will probably never be fixed? It seems to be more important to add unwanted features than to get the existing stuff working.

Reason is, that the path to the core dll is common for all installed releases through a setting in the registry: [HKEY_CURRENT_USER\Software\Parnassus OU\Core] "Path"="C:\\Users\\Public\\Documents\\Embarcadero\\Studio\\20.0\\Experts" This always points to the last installation.

Aeemmhhh, you're actually showing the button with the half-moon glyph in your screenshot!

It's "hidden" in den application titlebar. Click on the "moon" icon on the right of the titlebar and you'll see..