As you can see in the "credit" section of the source, I've tried to reduce memory leaks of that component, that was preventing me of using my program in Win98. Since I moved to Win2000, I corrected the code when also in Win2000 I had some problem, but since I'm not a Win guru and, as far as I've read in Google, .Assign has changed from old delphi version to new one, there is a lot of confusion about it's usage.
Anyway, I've find that is good after and assign to use the following code:
Buttons[i].Glyph.Assign( My_Glyph );
Buttons[i].Glyph.Dormant;
Buttons[i].Glyph.FreeImage;

so could you try to add the Dormand and FreeImage line when apropriate inside the SysStateChanged procedure? I think that eliminate resource leaks is the better way to avoid "impossible" bugs later...
Let me (and the list) know
Thanks
Marco Menardi

--- In IBObjects@y..., "Eric Handbury" <ehandbury@h...> wrote:
> Hello,
>
> (BCB6-SP2, IBO4_Hg, FB-1.0-796, TEnh 2.1.1)
>
> I posted a message regarding memproof errors in my IBO application
> about 2 weeks ago with no responses which is surprising since memory
> leaks are a component-library author's worst nightmare.
> The main GDI memory leaks seem to happen in the IB_UpdateBar.pas
> module (in the SysStateChanged procedure (line 584 in my IBO
> version)). The following code snippet from that procedure indicates
> that the memory allocated in the Assign (WinAPI CreatePalette) is not
> being freed.
>
> if (CustomGlyphs = nil) or not (ubPost in CustomGlyphsSupplied)
> then
> Buttons[ ubPost ].Glyph.Assign( StandardBitmap
> ( 'UPD_BAR_POST' ));
>
> Could this be researched to determine if it is a problem? Thanks
> for your help.
>
> Eric.