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. |
In reply to this post by Chris Uppal-3
"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! ! |
In reply to this post by Chris Uppal-3
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 |
In reply to this post by Chris Uppal-3
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] |
In reply to this post by Blair McGlashan-2
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 |
Free forum by Nabble | Edit this page |