Toolbar Buttons

I assume all buttons like the toolbar are first allocated from the OS then
used by higher level objects.  Can one trace that all the way back to where
it is alloated from the OS or is some of the code handled down in the VM (ie
not browsable)?  Thanks.

-g

Well, yes it can be done. Take a look in the ToolbarItem hierarchy.
ControlBarAbstract hierarchy also have a lot of 'low level' stuff, but
usually need to go there only when you need to extend a feature not in
normal use.

regards,

Sebastian

Geoff escreveu:

> I assume all buttons like the toolbar are first allocated from the OS then
> used by higher level objects.  Can one trace that all the way back to where
> it is alloated from the OS or is some of the code handled down in the VM (ie
> not browsable)?  Thanks.
>
> -g

Geoff,

> I assume all buttons like the toolbar are first allocated from the OS then
> used by higher level objects.  Can one trace that all the way back to
> where it is alloated from the OS or is some of the code handled down in
> the VM (ie not browsable)?

It's all browseable -- although finding out what's happening can be a little
difficult since it requires[*] familiarity with the Dolphin class library /and/
with the Win32 API.

You won't be able to browse the code to, say, deload the bytes in an icon file
or resource, because that's handled by Windows, rather than either by Smalltalk
code, or by code in the Dolphin VM.

Look at subclasses of GraphicsTool, and particularly of Image, for their
implementations of #createHandle (and the methods called from there) for
lowest-level details.

    -- chris

[*] "requires familiarity" in the sense of: "if you aren't pretty familiar with
it before you start, you will be by the time you've finished" ;-)

Yep, it is a tough one.  I was hoping to have a toolbar with raised buttons.
Can't see where that is done though.

Thanks.

-g

Geoff,


> I was hoping to have a toolbar with raised
> buttons. Can't see where that is done though.

If you're using WinXP (or later) then I don't think the horrible default theme
gives you any choice in the matter -- it just ignores that setting.

If your app has no manifest (either as a separate file or embedded as a
resource within the exe), then XP appears to fall back to the GUI code from
Win2K, and raised toolbar buttons work again.  Also, if your app /does/ have a
manifest, but the user has selected the "classic" theme[*] (I think it's
called), then XP appears to use different code, this time to emulate the Win2K
look -- which usually produces similar results.

    -- chris

[*] Which is how I run XP.

Good info, raises three questions in my mind, if anyone knows:

1.  Any good websites that explain manifests?  I found specific ones that
use like VB but nothing with a good general explanation.

2.  I assume dolphin uses a manifest as an embedded resource?

3.  Just for completeness, where is the setting in the code that says 'use
flat buttons', or is it not set since it does not matter?

Thanks.

-g


"Chris Uppal" <[hidden email]> wrote in message
news:4507c39b$0$765$[hidden email]...

Geoff,

> 1.  Any good websites that explain manifests?

I've never found one.  I presume they are like most MS "specifications" and
only exist in the code.


> 2.  I assume dolphin uses a manifest as an embedded resource?

D6 automatically embeds a manifiest in deployed .exes (I think that's a
selectable option, but I'm not certain).  D5 does not, although you can add one
yourself (you have to add it to the stub file /before/ deployment).  The
dolphin.exe program itself does not have an embedded manifest, but there is a
separate Dolphin.exe.manifest file in the installation directory, which has the
same effect.


> 3.  Just for completeness, where is the setting in the code that says 'use
> flat buttons', or is it not set since it does not matter?

I think you are looking for the #hasFlatAppearance aspect of Toolbar instances.

    -- chris