15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


run-time dynamic toolbars

Zeroth mark p sullivan -- msulliva@stevens-tech.edu
Tuesday, January 21, 1997

	Environment: VC++ 4.0, NT 3.51

Hello and good to meet you all (I'm a first-timer here),

    I'm trying to create a toolbar whose buttons are added at run-time.  I 
dream of a way to organize the individual bitmaps (from both resources and 
.bmp files) in a CImageList.  I would then pass the handle of the image 
list's internal bitmap (CImageList::GetImageInfo() writes it to the 
hbmImage member of the IMAGEINFO struct) to the function

BOOL CToolBar::SetBitmap( HBITMAP hbmImageWell );
and have to worry no more about the ugly details of bitmap manipulation 
(the image list would not be destroyed until after the toolbar was 
destroyed). 


    Though the SetBitmap() call returns success, the toolbar does not draw 
any graphics.  The help page for ::SelectObject() states in the Remarks 
section that:
  An application cannot select a bitmap into more than one device context 
  at a time. 

And so I speculate that the windows image list control has its internal 
bitmap perpetually selected into some memory device context.  Would anyone 
be able to offer insight into this hypothesis?   Does there exist 
something along the lines of a CImageList::GetImageWell() / 
ReleaseImageWell() pair paralleling CString::GetBuffer() / 
ReleaseBuffer()?  Is there any elegant way to duplicate a bitmap (the GDI 
object), or is there a way to make the image list draw its internal bitmap 
to another bitmap (via a memory device context?)?

I've left this message rather free of my own code; there are nasty things 
going on with the dwData of each button (accessed via the 
CToolBar::GetToolBarCtrl()) that I use to uniquely identify them, and I 
don't want to prejudice you toward any particular technique.

thanks

0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O
O i would expect this to be a common problem ... Zeroth  mark p sullivan 0
0 msulliva@stevens-tech.edu    http://attila.stevens-tech.edu/~msulliva/ O
O To a wonderful universe!                     I am proud of my universe 0
0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0O




Chris Cicchetti -- c_cicchetti@finisar.com
Thursday, January 23, 1997

At 11:02 AM 1/21/97 -0500, you wrote:

>    Though the SetBitmap() call returns success, the toolbar does not draw 
>any graphics.


I don't know if this comment relates specifically to your problem, but here
goes. 

I recently had to place some toolbars (CToolBarCtrl) in a property sheet and
could not understand why nothing showed up after initializing them. (All my
returns were valid as well) The answer was actually quite simple. The last
parameter in the 'CToolBarCtrl::Create()' member function is 'nID' which
specifies the toolbar control's ID. You might think, as I did, that this
specifies the the "control's ID", i.e. an integer that gives the control an
integer equivalent. Not true. This value must be AFX_IDW_TOOLBAR. That is,
you must tell the toolbar that it is a toolbar. If you don't you get zippo.
Maybe someone can tell me why you must tell a toolbar that it is a toolbar?

Hopefully your problem is as simple as this,
Chris
Finisar Corp.





| Вернуться в корень Архива |