Bug: toolbar items misplaced *only* when deployed

Hi all,

Here's a strange one.

I'm having problems with a deployed application which uses a toolbar with the
"flat" style turned off.  Running the application in the image, the buttons
render themselves nicely, but the same code/layout in a deployed application
draws all the buttons two pixels lower down the screen.

A bit of background: the application needs to run from the image, and also as a
standalone .exe.  Also the toolbar is being used in a slightly non-standard
place, and so I have to make it look as if it *is* a toolbar, not just a couple
of pretty pictures (which is how a flat toolbar does look). So I use a "client
edge" around the bar, and impose the non-flat look on the buttons.  (Which
works very well, by-the-way.).

The non-standard use of the toolbar isn't causing the problem, it happens with
"normal" ones in the "normal" place too. Also the problem occurs whether I
deploy on Win2K or WinXP, and whether I run the app on Win2K or WinXP.

Anyway my users* are getting impatient, but the developers** have run out of
ideas for how to fix it..  Can anyone suggest anything ?  I hate to bugger-up
the GUI just to avoid a Windows (or possibly Dolphin) bug...

I've put together an example package, but the STBed Views make it too big to
append to this message, so I've put it and a couple of screenshots on the web,
here:
    http://ephemera.metagnostic.org/buggy-toolbar/

    -- chris

[*] Me.

[**] Also me.

Chris,

> I've put together an example package, but the STBed Views make it too big
to
> append to this message, so I've put it and a couple of screenshots on the
web,
> here:
>     http://ephemera.metagnostic.org/buggy-toolbar/
>

This looks something like a problem that I've been having with reference
views to scrolling decorators embedded inside of views with the client edge
style, or something like that.  I didn't have time to track it down.  If
there are any reference views involved, you might try dereferencing them to
see if it fixes it, even w/o saving the image.  Also, look for separator
styles in the toolbars.

<tryingToBeHelpful>
First, every native widget I remove is one less headache - nearly every time
I try it.  My stuff is faster and more reliable than the native alternative.
I offer OA's Moen Tree as the gold standard.  A view containing some images
with a little mouse tracking and decorating to show interaction would
produce something at least as slick and w/o the mysteries.

Second, do you really care about a couple of pixels here or there?  Life's
too short, unless you are thinking of selling this later.
</tryingToBeHelpful>

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill,

> If there are any reference views involved, you might try dereferencing
> them to see if it fixes it, even w/o saving the image.

No reference views at all....


> Also, look for
> separator styles in the toolbars.

No separator styles either...

As I say, this is a difference between how a toolbar looks in the image vs. how
it looks in a deployed application.  I don't see how the "aspects" of the
toolbar (or any other implementation detail, come to that) should change
between the two cases.  Indeed I don't see how they *can* change... But they
do... ;-)


> First, every native widget I remove is one less headache - nearly every
> time I try it.  My stuff is faster and more reliable than the native
> alternative. I offer OA's Moen Tree as the gold standard.  A view
> containing some images with a little mouse tracking and decorating to
> show interaction would produce something at least as slick and w/o the
> mysteries.

I've been tempted a few times -- I suspect it'd turn into a can of worms,
though, if done with an eye to *completeness* (a compulsion of mine ;-(   I
know how much effort I put into getting "minor" aspects of the behaviour of my
ListTreeView* as close to Window's standards as possible.  I doubt if it would
be any easier getting roll-my-own widgets "right" in that sense.

Still tempted, though...


> Second, do you really care about a couple of pixels here or there?  Life's
> too short, unless you are thinking of selling this later.

<grin>

But yes, I do care.   It looks like s**t (see the screenshot), and where's the
point in being a programmer at all if I have to put up with that kind of thing
?

    -- chris

[*] BTW, for anyone who's been waiting, I haven't forgotten that I promised the
world an editable version of the ListTreeView -- the code's all there, I just
haven't got around to packaging it up and updating the website.

"Chris Uppal" <[hidden email]> wrote in message
news:400a9495$0$61053$[hidden email]...
> Hi all,
>
> Here's a strange one.
>
> I'm having problems with a deployed application which uses a toolbar with
the
> "flat" style turned off.  Running the application in the image, the
buttons
> render themselves nicely, but the same code/layout in a deployed
application
> draws all the buttons two pixels lower down the screen.
> ....[snip]...

The difference in behaviour can be explained (in the case of Windows XP) by
the presence/absence of an application manifest that enables the WinXP look
and feel of the common controls. The Dolphin development environment has a
manifest, though it is in a separate file so you can remove/rename it to
revert to classic look. If you go to the Dolphin installation directory
(where Dolphin.exe is placed), and rename or remove Dolphin.exe.manifest, I
expect you will see the same behaviour in the development system and your
deployed application.

Deployed applications will not have a manifest unless you create one - just
copy the Dolphin.exe.manifest in the same directory as Dolphin.exe and
rename it so that it is named after your application. It must be placed in
the same folder as the executable. In Dolphin 6 this will not be necessary
because Lagoon optionally binds a manifest into the executable.

> A bit of background: the application needs to run from the image, and also
as a
> standalone .exe.  Also the toolbar is being used in a slightly
non-standard
> place, and so I have to make it look as if it *is* a toolbar, not just a
couple
> of pretty pictures (which is how a flat toolbar does look). So I use a
"client
> edge" around the bar, and impose the non-flat look on the buttons.  (Which
> works very well, by-the-way.).

It works on Windows XP? Not always. XP will force the flat style for an
application with an appropriate manifest unless the Windows Classic style
setting is chosen on the display properties Appearance tab. Of course since
the end-user is you (and I imagine you do use the "classic" setting Chris
:-)), this shouldn't be an issue for you.

>
> The non-standard use of the toolbar isn't causing the problem, it happens
with
> "normal" ones in the "normal" place too. Also the problem occurs whether I
> deploy on Win2K or WinXP, and whether I run the app on Win2K or WinXP.

I was initially surprised you observe no difference between Win2K and XP,
until I thought of enabling the classic Windows style under XP.

>
> Anyway my users* are getting impatient, but the developers** have run out
of
> ideas for how to fix it..  Can anyone suggest anything ?  I hate to
bugger-up
> the GUI just to avoid a Windows (or possibly Dolphin) bug...

Its a recognised bug (if the MFC developer responsible for the comment in
CToolBar::OnSetSizeHelper() is to be believed anyway) in the Windows common
control DLL for which we currently have no workaround in place. However I
have pasted one below for you to try.

Hope this helps

Blair

---------------------
ControlBarConstants at: 'TBSTYLE_TRANSPARENT' put: 32768!

!Toolbar methodsFor!

changeButtonSize: aNiladicBlock
 "Private - Apply an operation that affects the button geometry of the
toolbar, requiring
 that it recalculates its layout. Due to a bug in the common controls DLL if
we want to
 maintain a consistent border width (of zero) between flat and non-flat
styles we must turn
 on the flat/transparent style for the duration of the resizing operation."

 | style |
 style := self getWindowStyle.
 (style allMask: TBSTYLE_FLAT) ifTrue: [^aNiladicBlock value].
 ^
 [self setWindowStyle: (style bitOr: ##(TBSTYLE_FLAT |
TBSTYLE_TRANSPARENT)).
 aNiladicBlock value]
   ensure: [self setWindowStyle: style]! !
!Toolbar categoriesFor: #changeButtonSize:!helpers!private! !

!Toolbar methodsFor!

onFullyCreated
 "The receiver window has been created (but is not yet visible).
 Finish the job and install the known ToolbarItems"

 super onFullyCreated.
 bitmapsStart := LookupTable new.
 self changeButtonSize: [self tbSetBitmapSize: self bitmapSize].
 #todo. "Store extended style in an inst. var (appear to be some unused?)
and provide accessors/mode settings"
 self tbSetExtendedStyle: TBSTYLE_EX_DRAWDDARROWS.
 self clearIdMap.
 self basicAddItems: items! !
!Toolbar categoriesFor: #onFullyCreated!event handling!public! !

!Toolbar methodsFor!

updateSize
 "Private - Update the toolbar button and bitmap sizes."

 self changeButtonSize:
   [self buttonSize notNil ifTrue: [self tbSetButtonSize: self buttonSize].
   self tbSetBitmapSize: self bitmapSize].
 self tbAutoSize! !
!Toolbar categoriesFor: #updateSize!operations!private! !

Chris,

> As I say, this is a difference between how a toolbar looks in the
> image vs. how it looks in a deployed application.  I don't see how
> the "aspects" of the toolbar (or any other implementation detail,
> come to that) should change between the two cases.  Indeed I don't
> see how they can change... But they do... ;-)

Well, no complete solution for you but...

I loaded up your example package into D6 and imagine my surprise when
neither of the toolbar buttons was shown with the non-flat style
anyway. Yes, the style was checked on for the second button in the View
Composer but was not visible. Strange.

However, remembering that you were at least a friend of Ned Ludd when
he was leading his throng against the excesses modern society (i.e.
Windows XP :-) ) I wondered whether it might be anything to do with the
XP manifest information that indicates whether an application should
assume the default XP appearence. Sure enough, when I deleted the
"dolphin.exe.manifest" file the non-flat buttons reappeared in the
development system. However, and here's the rub, they reappear in the
shifted location just as in your deployed app. Just to verify that this
wasn't just a D6 effect, I retraced these steps with a D5 image and the
same thing happened.

So, it seems there are more questions to throw into the pot:

1) Are you running you development system with XP style turned off
(i.e. no manifest)?

2) If not, how come you can see the non-flat buttons at all? Could this
be an XP service pack issue; I'm running SP1?

3) Why does your development image present the buttons shifted up by
one pixel.. since this doesn't appear to be the "normal" alighnment
that I see in the development image or deployed apps.

Hope your user(s) remain cool while we sort this out!


Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Chris,

> I've been tempted a few times -- I suspect it'd turn into a can of worms,
> though, if done with an eye to *completeness* (a compulsion of mine ;-(

That could be a problem.  However, I was somewhat surprised to discover that
end users don't know what controls are, nor have they really figured out
that there is are user interface standards.  They _do_ understand that there
are conventions (e.g. File|Open), but tend not to see past the "screen"
level.


> I
> know how much effort I put into getting "minor" aspects of the behaviour
of my
> ListTreeView* as close to Window's standards as possible.  I doubt if it
would
> be any easier getting roll-my-own widgets "right" in that sense.
>
> Still tempted, though...

My advice is to try it in a simple case.  Maybe you could have your boss
(you??<g>) give you a time limit to make it work or simply give up.  It's
not trivial, but it is often less trouble than reverse engineering a moving
target.

In your present situation, I think Andy and Blair are on the mark with the
manifest.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy, Blair,

[Replying to both of you at once]

Many thanks for the help.  You are spot on, it is a manifest issue.

In case anyone's interested in the details of how it comes to show such odd
behaviour, here's my summary.

It seems that there are *three* implementations of toolbar buttons on an XP
box.

One is used for applications that lack a .manifest file.  This seems to be the
same code as was present in W2K, and is buggy in this respect.   It turns out
that the demo app's toolbar is wonky even running from the image under W2K.

The second is used by W2K in its new look.  As Andy mentioned, it seems to
ignore the no-flat-look directive entirely.  As Blair surmised, I don't care
much about that (I don't care much *for* it, either ;-).

The third is used by XP running in "classic" look-&-feel. Which is, naturally
;-), how I use it.  Despite the W2K appearance, this would seem to be a
re-implementation that doesn't share all the W2K code (and bugs).  So my image
(which has a .manifest) was picking up the XP libraries, when then rendered the
"classic" look using the new code, and the so application worked fine in the
image.  Once deployed, it lacked the manifest and so was falling back to the
W2K code, and hence tripping over the bug.


> Its a recognised bug (if the MFC developer responsible for the comment in
> CToolBar::OnSetSizeHelper() is to be believed anyway) in the Windows
> common control DLL for which we currently have no workaround in place.
> However I have pasted one below for you to try.

Thank you, I'll try the patch later (I'm up to my ears parsing .ZIP files
today) and let you know.

(Incidentally, I'm currently using a really nasty kludge as a work around -- I
embed the toolbar (without static edge) inside a same-sized container (with
static edge) and then do a run-time test in #onViewOpened to extend the toolbar
upwards by two pixels if it's in a deployed image.  Not the kind of code I'd
care for my Mother to see....)

    -- chris

Blair,

> > Its a recognised bug (if the MFC developer responsible for the comment
> > in CToolBar::OnSetSizeHelper() is to be believed anyway) in the Windows
> > common control DLL for which we currently have no workaround in place.
> > However I have pasted one below for you to try.
>
> Thank you, I'll try the patch later

I did.  It works very well on both XP and W2k.  Thanks again!

BTW, although I have removed the horrible workaround I was using, I am still
applying a belt *and* braces approach to this one -- not only does you patch
fix it, but I have also added the .manifest file as a resource embedded in my
deployment stubs, which *also* fixes it...

    -- chris