I just upddated from 7.9.1.0 to 8.5.1.0, and now my TAdvToolBar is dropping the left most TAdvGlowButton or it is dropping the left most TAdvToolBarSeparator.
In the text I said left most... but I meant right most as said in the topic
What screen DPI do you use?
Have you enabled high DPI in your app?
I use a Dell ultrawide, 3440x1440 for development (the PixelsPerInch setting on the form is 96). I've tried with and without a manifest entry for High DPI aware with no difference. Even copy and pasted the toolbar to a new VCL app with no manifest and nothing else that might influence the presentation. I normally have been running without the High DPI setting due to issues I was having a while back with your v7.
I could not reproduce this here so far.
This is our demo app where you the toolbar position is correct and also buttons on the toolbar.
Are you sure you use the latest version and if so, what's different in your project from our demo?
I don't know offhand, but some of the toolbars come out OK, but others not. You can download my demo from http://whispersolutions.com/downloads/ToolbarDemo.zip
It also contains the exe I built to show you what I end up with in case it works fine after you've compiled it. Delphi 2007's startup screen says I am using the 8.5.1.0 version of TMS Component Pack.
I have retested this here but could not see an issue:
Can you perform a runtime version check of the TAdvToolBar component and verify it is 6.5.0.5?
Bruno Fierens2017-02-06 10:34:49
If I delete the saved UnDockedAdvToolBars registry entries that saves the positioning/sizing etc, there is no problem. So it looks like v7's registry entries are messing up v8's positioning/sizing. Any idea how I can fix that? Customer's are not going to like me if they have to reset all their toolbar settings after updating to our next version.
If I then bring up the old version, followed by the new version, it gets messed up again. I'll try to figure out which setting is causing the failure.
It looks like something is turning off some of the toolbar items for no good reason. Example:
"AdvToolBar_Tools.sepTools2"=dword:00000000
"AdvToolBar_Tools.sepTools2"=dword:00000001
"AdvToolBar_Tools.btnToolsCamera"=dword:00000000
"AdvToolBar_Tools.btnToolsCamera"=dword:00000001
etc.
I don't even have that option available in my code to turn on/off certain elements. Any idea what would cause v8 to decide to turn off certain elements based on v7 registry entries?
Same thing happens in reverse. v7 will turn off some of the entries from the v8 written registry entries and get messed up.
Other than DPI handling, I cannot see a reason for this.
Can you verify that in AdvToolBar.pas the global variable ADVToolBarDPI_Scale is equal to 1?
Yes:
ADVToolBarDPI_Scale: single = 1.0;
The pas file is dated 2017-01-17
When this variable is 1.0, I cannot see a reason for the displacement.
When I start & close the app with persisting the position, this behaves correct here.
Right. The problem exists between versions, not the same version. I can bring up the app over and over again as long as I don't switch versions. If I run v8 and all are turned on but then run v7, some get turned off. Likewise if I started with v7 with all of them on, then run v8, some get turned off. If I stay within the same version, there is no problem. What I face is when my customers upgrade to our next version, some of the toolbar buttons are going to get turned off because of this version switch. It is almost like there is some logic that thinks the toolbar size has changed so it turns some off. Both v7 and v8 behave the same way but they don't like whatever the other wrote to the registry.
I hope I've explained it well. If you can't do it, I can downgrade and create a v7 sample so you can alternate between v7 and v8 versions to see what I mean.
The latest version has improvements for handling high DPI so that can cause that values persisted before high DPI was taken in account are not accurate for the new situation where high DPI is taken in account. There is no straightforward solution to automagically transform old v7 values not taking high DPI in account to a v8 situation with high DPI. I'd suggest to do a one-time clear of the persisted values in case of an upgrade from v7 to v8.
OK, I can do that but I don't want to. Consider that I don't know what version they currently have. If I blindly reset the persisted values every time a user installs our software, I wont have any happy customers. The next version was possibly going to allow users to turn on/off selected buttons. Also, sometimes users want to rollback to a previous version. Since v7 also is turning off buttons from v8 persisted values, they would be screwed.
This is not something new in v8 since v7 also turns off buttons. I need a better solution. I'll see what I can do to debug your code. Any hints on where the logic is that decides to turn off buttons on render?
I may save the persisted values to a new "v8" location so that it won't trash the v7 persisted values. I'll see if that resolves this... effectively doing what you suggested.
Unfortunately this didn't help.
What we have in our app is the ability to change the size of the toolbar. With v7, this did not cause any of the buttons or separators to get turned off. However, even after a clean registry, changing the size causes some of the buttons and/or separators to get turned off.
The size change was needed when we had High DPI Aware enabled to allow increase in button size on PC's set with a display of 150% or more, but as I mentioned before, we had to turn off High DPI Awareness due to other issues (but of course people are complaining that everything is fuzzy because Windows is doing bitmap scaling). But even with it turned off in our manifest, size changes using v8 is turning off buttons where v7 didn't.
Need another sample?
what exactly is meant with "changing size causes..." ?
Is this changing in code and if so how? Or changing at design-time and if so, how? Or something else?