I'm only using the track bar component (PegtopNumEdits, PegtopNumForms, PegtopThemes and PegtopTrackBars units) and that didn't require any changes for Delphi 2009 and 2010 compatibility.

The only changes I did was to reverse the direction of the scroll wheel. IMO scroll-up should increase the value and scroll-down decrease it.

The track bar that is used in the bitmap editor to adjust alpha values is a custom descendant of TPegtopTrackBar.

The black icons are probably caused by a theme manager issue. What version of Windows are you running on (XP or later required) and do you have themes enabled? What is the color depth of your display?

What do you mean by "can't handle […] Vista png graphics"? Do you get an error? Are you unable to edit the bitmaps?
Vista PNG icons should work just fine. If you open ResourceEditor.exe with itself you should be able to view and edit an icon named "A" which contains a 256 x 256 x 32 bit PNG compressed bitmap.

I'm not sure if that would do you any good. What exactly are you looking for?

TImgView32Ex is just a TImgView32 descendant with improved handling of flicker. The TImgView32 component is part of the Graphics32 library.

I seem to have uploaded the wrong version. Sorry about that.
The version I uploaded was an internal test version. It was actually meant to break the resource file, but of course that is of no use for anyone but me.

I will upload a new version later tonight.

Grazie mille!

Have you tried the HSLRingPicker from mbColorLib? As far as I can tell it is just like the PSP color picker.

I'm writing an article on the shadow stuff. ETA within a week. The zoom animation will come after that.

What version of Windows are you running?
What kind of resource file (e.g. RES, RC, EXE, etc) are you trying to open?

Hi Fred,

1. No help file.
2. Open the project .res file and edit or replace the MAINICON icon resource. I can see from the bug reports you've submitted that you have already figured this out

To save a transparent PNG from PhotoShop you should make sure that the background layer is hidden before you save. Same thing when you flatten a layered image.

The resource editor's bitmap editor can load both PNG and PSD files so either formats are fine. In the bitmap editor use the first button on the toolbar (Load Image…) to load an image into the current bitmap. Be aware that although the bitmap editor support layers, the image will be flattened as soon as you close the bitmap editor (e.g. by selecting another resource).

Thanks for picking the ball up. I appreciate that.
I've pretty much given up on Embarcadero. Last I spoke with them about RE I told them I was done trying to push the project forward and that they'd have to come to me if they wanted it. I guess they didn't want it because I haven't heard from them since. With Nick and Chris gone I doubt there's anyone left that even remember the project anymore.

You're welcome to write or organize some documentation if you like, but I'm afraid that I don't have time to participate. Also I'm not sure if the effort isn't wasted if the goal is to have RE integrated with RAD Studio. Supposedly Embarcadero will want to write their own docs - they're so good at it .

I use the stack trace - and sometimes the screenshot to provide context.

For example the bugreport you submitted showed me that an Access Violation had occured in the TSeedFill.SetFillPoint(X, Y: integer) method after a tool was applied to the bitmap.
Looking at the TSeedFill.SetFillPoint() source I can see that the X and Y parameters aren't validated or constrained and that a pointer address is calculated based on their value.
The screenshot confirmed my suspicion that the error was caused by a click outside the bitmap area; An invalid coordinate produced an invalid address which caused an Access Violation. Easy to reproduce, fix and verify.

To locate the cause of Access Violations I generally use the SafeMM memory manager. With the normal memory manager an AV will often not occur at the exact moment memory is corrupted but might instead occur much later or even first when the application is terminated.
With SafeMM all memory blocks are guarded by a block of write protected memory before and after the block and all unallocated memory is protected. The AV will most often occur at the exact moment an invalid memory reference is made.

I'm actually trying to fix an AV just now that SafeMM helped me locate in RE.

I have resolved these issues with Fred via email but for the benefit of others I will also answer each item here.

1. The cause of the problem is an undocumented "requirement" Explorer has with 32-bit icons.

   An icon image always contains two parts: An AND bitmap and a XOR bitmap.
   The AND bitmap is a 1-bit bitmap that is used to specify transparency.
   The XOR bitmap contains the colors and can have a color depth of 1, 4, 8, 24 or 32 bits.
   When the XOR bitmap is 32 bit then the XOR bitmaps alpha channel is used to specify transparency and the XOR bitmap is ignored.
   All the above is per Microsoft's own ICON specification.

   Unfortunately there's a bug in Explorer…

   In some situations where Explorer needs to display an icon, it creates a 24-bit icon from the 32-bit icon. It does this by copying the RGB values from the XOR bitmap (ignoring the A values) and the transparency mask values from the AND bitmap. If the AND bitmap is blank then the icon will become completely transparent. The bug here is that Explorer uses the AND bitmap even though it isn't required to contain valid data for 32-bit icons.
   32-bit icons were introduced in XP but the code in Explorer which causes this bug obviously hasn't been updated since Windows 2000.

   Edit: It appears the problem is known. From Wikipedia’s article on the Icon file format:

   Windows XP can also and will use a 32-bit image in 24-bit mode by removing the alpha channel and applying the AND mask for transparency if no 24-bit image is available. Since the AND mask describes the transparency in 24-bit mode, if it is not included, an incorrect transparency pattern will be produced.

   I have now modified RE to always create an AND mask even when for 32-bit icons.
   In order to have RE fix your icons all you need to do is to open the icon image, modify it somehow (I suggest you just use the select tool to perform a selection, this is enough to mark the image as modified) and then save the icon or resource (note: this fix only applies to the new version which I haven't released yet).

2. Delphi doesn't support PNG compressed icons.
   If you add a PNG compressed icon to the MAINICON resource outside of Delphi and then modify the project options (e.g. the version info) inside Delphi, then Delphi will most likely corrupt the resource file.

   The way to use a 256×256x32 PNG compressed icon as the application icon is to add the icon to a separate resource file and then include that resource file in your project. Make sure you name the icon "1" or "A" because Explorer will use the icon with the lowest alphanumeric name as the application icon.

3. RE at present does not enable you to save PNG images directly as icons.
   You can however get there in a roundabout way:
   1. Save the PNG image as a PNG file.
   2. Create a new Icon resource item and edit it.
   3. Load the PNG file into the bitmap editor.
   4. Save the Icon resource as an ICO file.
4. The icon size used depends on the version of Windows and the current "view". Generally you don't need 24 bit icons if you have 32-bit icons. 4 and 8-bit icons are mostly only needed to support Remote Desktop.
   Windows XP
   Explorer will mostly use the 48×48 size, but will also use 16×16 and 32×32. If you need to appear in the right hand pane of the Start menu then you should also provide a 24×24 icon.
   Windows Vista and Windows 7
   You should provide 16×16, 32×32, 48×48, and 256×256 icons. For classic mode Windows you should instead provide 16×16, 24×24, 32×32, 48×48 and 64×64 icons.
   If you provide a 40×40 icon then that will be used in the Quick Launch Area. Otherwise the 48×48 icon will be scaled down.
   Shell overlays may need additional icon sizes.

   It is very easy to determine what icon size is used in a given situation if you create a test icon that has a different image for each size.

   Additional information from MSDN:

   • Windows XP: Creating XP Icons
   • Windows Vista and later: Icons

Yes, I see the problem.
I think the cause of the problem is that the application manifest states that the application supports DPI scaling although I haven't done anything explicit to make that happen. Another problem is that I obviously haven't done any testing with DPI scaling.

I will see if I can do something about.

I've (mostly) stayed away from JVCL for this project due to JVCL's interdependencies (use one little thing and everything else is linked in) and prior experiences with the quality of the JEDI source. Also since the resource editor was meant to be integrated into the Delphi IDE I could not use a third party docking manager - otherwise I could just as well have used the Developer Express docking manager.

Thanks for the feedback.

You can use the LoadImage API function:

var
  Icon: TIcon;
begin
  Icon := TIcon.Create;
  try
    Icon.Handle := LoadImage(hInstance, PWideChar('MYICON'), IMAGE_ICON, 16, 16, 0);
    ...
  finally
    Icon.Free;
  end;
end;

The reason is a bit complicated, but the short version is that a dialog control ID in reality is always a WORD even though the DLGITEMTEMPLATEEX structure allow DWORD values.
The reason I set the high word to 0xFFFF is so the DWORD becomes a valid ordinal resource identifier. Now that I think of it there really should be no reason to do this since the control IDs aren't resource identifiers. If the current behavior is a problem I can look into fixing it.

The Old New Thing: The evolution of dialog templates - 32-bit Extended Templates

Not that expanding the control ID to a 32-bit value helps any, because WM_COMMAND and similar messages still use a 16-bit value to pass the control ID. So in practice, you can't use a value greater than 16 bits.

Correction to DLGITEMTEMPLATEEX Structure

if you look carefully you will see that he thinks the id member is a DWORD. I took a look at the Windows source code and in fact the id is a WORD, but there is an unused word after it. (The Windows tree itself contains a bunch of definitions of this type, because it isn't in the internal headers either, and all but one have ID as a DWORD.

As you've discovered “Add from file…” will create a resource item type based on the file type regardless of the type of item you right clicked. This is by design.

To load a PNG into a RCDATA item, first create a RCDATA item and then right-click the new item and select “Load resource…”.

It is correct that TPngImage requires the resource type to be RCDATA but only if you use the LoadFromResourceName/LoadFromResourceId methods. I suggest you load from a TResourceStream instead:

Stream := TResourceStream.Create(hInstance, PChar('FOOBAR'), PChar('PNG'));
PngImage.LoadFromStream(Stream);

I have reproduced the VersionInfo problem and will investigate a fix.

So are you still sure there's no hurry
The StringTable problem is known and has been fixed. I'll mail you the new version.