Announcement

**SimonF** · 16 Jun 2017, 08:04

I've found one addition to the button-behaviour in the ask-Prompt

7. Maybe this is the same problem, but creating a ask-Prompt does also look like the text is a bit off and is not centered vertically. Maybe it is the same as in 1 and 3 and some overflows are missing.

Code:

isc.ask("TestMessage", function (value) {},{showCloseButton:false});

8. Maybe somebody have already reported this, but I didn't see it here.
at: http://www-demos.smartclient.com/sma...ion&skin=Tahoe you can see the selectboxes are missing. For comparison this link: http://www-demos.smartclient.com/sma...kin=Enterprise

**Isomorphic** · 20 Jun 2017, 03:18

This looks like a list of recently corrected issues. Although you've posted your version, you likely have an issue with caching. Please make sure you've both cleared cache and restarted your browser completely. The surefire way to test is to try another machine.

**Isomorphic** · 20 Jun 2017, 03:19

Also, please don't forget to post the browser and platform you're testing. This is absolutely necessary information when posting about appearance issues as these are usually browser-specific.

**SimonF** · 20 Jun 2017, 03:44

Hi there,
I also retested it again with the latest downloadable nightly SmartClient_SNAPSHOT_v111d_2017-06-18_Pro
The reported issues (except Number 8) still exists with
* Firefox 53.0.3 (32-Bit)
* Firefox 54.0 (32-Bit)
* Chrome Version 58.0.3029.110 (64-bit)
* Chrome Version 59.0.3071.104 (Official Build) (64-Bit)
* Internet Explorer 11 (11.0.9600.18697, Updateversion;11.0.43).
All Browser are tested on a PC with Windows 7 Pro with the latest updated installed, also with inkognito mode and a complete cache refresh.

Please specify in your answer what's the meaning of "recently corrected" - is it in the build of the 18th? If so only one of the reported eight fixes does work.
Do you need another set of sceenshots for every browser?

As you may noticed all screenshots are indeed made with the density "dense" (Here you can click and copy paste every code-snippet I've reported to see the same images I've reported above: http://www-demos.smartclient.com/sma...crease=0&dhc=1)

By the way: Increasing the density does not work if the isomorphic files are delivered through a CDN (which is very useful with such a high amount of data). But I've already reported this one when the density-feature came out.

**Isomorphic** · 20 Jun 2017, 04:52

We'll double check the fixes. It's likely you are only affected because of your unusual choice of "Dense" density. Note that Tahoe is designed with "Spacious" density in mind and scaling to radically different densities is harder - we may consider several of these as "won't fix".

Also note that telling us what density your using is also critical information when reporting an appearance issue - please don't omit this.

Since programmatic calls are used to change density, we're not sure how you could break the feature by using a CDN... that is unless you put the programmatic calls into the cached files, but that's obviously not correct.

**SimonF** · 20 Jun 2017, 06:10

Thanks again.
Because the density "dense" is the default setting, I assumed that this setting is default, when no other setting is specified in the example.
I'll take care of this in the future reports, thanks.

If the support for the default density is quitted (or marked as "won't fix") you should also set the new density as a default. I think it's nonesense to set a default-value, if this default value will not be supported anymore.

Nonetheless, maybe you can help me with get this thing running with another density.
Our local application is running on http://localhost:7081/ the smartclient files are hosted with an installed webserver which listens on port 80, so the smartclient-files are included with the url "http://localhost/isomorphic/system/modules/ISC_Core.js". If I'm adding "Canvas.resizeFonts(5);Canvas.resizeControls(10);" before any component gets created the size of the created components gets increased, but the fon-size stays at the default font-size.

Saving the same html-output from our application to a file which is delivered by the webserver on port 80 (http://localhost/test.html so the js-files come from the same origin) the font-size are displayed correctly increased by the given density.

The same problem we will have on our production stage, where our server listens on "https://ssl.mydomain.com" and does include the Smartclient-Files with something like https://d4fxxxxxxxxxx.cloudfront.net...es/ISC_Core.js which also is another origin.

It seems that changing the font size of a "not same origin css" is not evaluated. Do you have a hint or solution how it is possible to also increase the font-size?

Best regards

**SimonF** · 20 Jun 2017, 06:30

I didn't know the source of this information about the cross-domain font-change restraint, but now I know, it's from the docs:
http://www.smartclient.com/smartclie...tionAppearance

Some browsers will disallow access or modification of styleSheets if they are loaded from a domain that is different from the loading page. In this case resizeFonts() cannot be used.

So we basically have this problem in our development and will also have the same problem in the production environment.
What can I do tha on one hand bugs that are appearing with the default font-size, are not fixed anymore and on the other hand the docs says that it's not possible for "some browsers" that the font-size is changed on cross-domain, loading?

Best regards

**Isomorphic** · 20 Jun 2017, 09:12

Sorry, but the default Density for a given skin is what we say it is, regardless of whether that requires a method call or not. We show what we consider to be the default densities for each skin in the Showcase.

We expect that a vanishly small number of users would want to use Tahoe at "Dense" Density so we don't plan to try to make it look highly polished at this Density, which would involve engineering a whole system to try to dynamically adjust padding and borders, which is unnecessary for other skin and Density combinations. You are of course free to make your own variation of Tahoe or any other skin to better suit your personal taste.

To avoid the issue with Density change needing to dynamically update styles, there are various ways to load from a CDN or other server and yet have the browser consider the loading as having happened from the same logical domain. Use Google to learn about this. If you don't want to do this, you could also statically change the resources to reflect your target density.

**SimonF** · 26 Jun 2017, 04:45

Thanks fot the information about the "won't fix". Because all reported issues are not fixed in SmartClient_SNAPSHOT_v111d_2017-06-25_Pro, I assume they won't be fixed what so ever.
We are using multiple servers and in every version there is a different smartclient-version, so with every new version there is also a new cloudfront-distribution... But to keep it short, thanks for the "advice".
We will change the resources statically to different font-sizes.

**claudiobosticco** · 26 Jun 2017, 05:09

SmartClient Version: SNAPSHOT_v11.1d_2017-06-25/AllModules Development Only (built 2017-06-25)

Chrome on OSX

Originally posted by Isomorphic View Post

We expect that a vanishly small number of users would want to use Tahoe at "Dense" Density so we don't plan to try to make it look highly polished at this Density, which would involve engineering a whole system to try to dynamically adjust padding and borders, which is unnecessary for other skin and Density combinations.

Thanks for the clarification on this point.
And what about the 'compact' density? Problems no. 1, 3, 4 and 7 are present also in that density setting.
Would you fix them?
Or the medium setting will be the minimum supported?

**Isomorphic** · 28 Jun 2017, 10:02

Hi Claudio
Firstly - we don't consider the skin "unsupported" at Dense or Compact density - it was designed with Spacious density in mind and as such there may be occasional cases where the appearance isn't as polished in the most compact setting (Dense).
Having said that at this stage most of the bugs you noted are resolved in our testing (performed on both Firefox and Chrome, on Windows and Mac).

This includes:
1) Button with no text renders too short vertically in Dense and Compact settings [resolved]
2) Buttons' sizes change on first roll-over in Dense setting [resolved]
3a) Mismatched sizing / misalignment between overflow:"visible" and overflow:"hidden" buttons in Dense and Compact settings [resolved]
4) Mismatched sizing / misalignment between Button and MenuButton instances (Dense and compact settings) [resolved]
8) Missing select boxes in TreeGrid with cascading selection for certain selection states. This is resolved

If you're still seeing these problems we'd recommend retesting with the next nightly 11.1 build (dated June 29 or above) to ensure you're testing with the latest code. As we observed earlier, a number of these issues were already resolved in at least some cases - but since you were not seeing the fixes - let's have you re-test with the next build to ensure we're looking at the same code.

The remaining issues are as follows:

3b) The height of the ToolStrip separator is very small. We intend to fix this shortly.

5a) The size of text in a TextItem's element is slightly larger than the title size for the item. This is as designed, so likely wont-fix - but we'll flag it for review by the design team in case we decide to change this.

5b and 6) DateChooser has small fonts and a lot of space between buttons at Compact and Dense sizing. This is currently under consideration.

7a) Ask dialog text is not vertically centered next to the icon. This is as designed (and occurs regardless of density), so likely wont-fix, but we'll flag it for review by the design team.

7b) Ask dialog buttons clip off their bottom border in "Dense" setting only [ok in Compact and above]. This is currently under consideration.

We'll follow up on issues 3b, 5b/6 and 7b shortly

Regards
Isomorphic Software

**claudiobosticco** · 3 Jul 2017, 02:32

SmartClient Version: v11.1p_2017-07-03/AllModules Development Only (built 2017-07-03)

Chrome on OSX

Thank you very much for the clarifications.

I can confirm all the fixes mentioned in post #12, apart the #4 in dense setting, this is what I see:

**Isomorphic** · 25 Jul 2017, 12:17

The mismatch in size in #4 is related to how the "boss" icon is written into the menu button.
The original test case specifies the menu button title as:

Code:

            "title": "<img src=\"https://cdn4.iconfinder.com/data/icons/6x16-free-application-icons/16/Boss.png\" style='vertical-align:-4px; padding-right: 5px; width: 16px'>Videos&nbsp",

If you use vertical-align:middle instead of setting it to a 4px offset, the issue goes away:

Code:

isc.HLayout.create({
    "ID": "theLayout",
    "height": "20",
    "backgroundColor": "red",
    "hideUsingDisplayNone": false,
    "align": "center",
    "leaveScrollbarGap": false,
    "members":
    [
        isc.MenuButton.create({
            "ID": "theToolStripMenuButton",
            "layoutAlign": "center",
//            "title": "<img src=\"https://cdn4.iconfinder.com/data/icons/6x16-free-application-icons/16/Boss.png\" style='vertical-align:-4px; padding-right: 5px; width: 16px'>Videos&nbsp",
            "title": "<img src=\"https://cdn4.iconfinder.com/data/icons/6x16-free-application-icons/16/Boss.png\" style='vertical-align:middle;padding-right: 5px; width: 16px;'>Videos&nbsp",
            "hiliteAccessKey": true,
            "overflow": "visible",
            "showDisabledIcon": false,
            menu: isc.Menu.create({
                "ID": "theMenu",

                "members":
                [],
                "data":
                [{
                        "ID": "theMovie",
                        "icon": "https://cdn4.iconfinder.com/data/icons/6x16-free-application-icons/16/Boss.png",
                        "title": "Movie1"
                    }
                ]
            })
        }),
        isc.Button.create({
            "ID": "theButton",
            "overflow": "visible",
            "title": "Button",
            "icon": "https://cdn4.iconfinder.com/data/icons/6x16-free-application-icons/16/Boss.png",
            "hiliteAccessKey": true,
            "showDisabledIcon": false
        })
    ]
})

Essentially the original specification requires more vertical space for the icon and since the button is overflow:"visible" it expands to accomodate it.

Having said that, it is incorrect that the button should shrink when the user clicks it. That appears to be a simple styling issue and we anticipate having it resolved shortly.

Regards
Isomorphic Software

**Isomorphic** · 25 Jul 2017, 14:05

The shrinking on mouseDown has now been resolved - this change will be present in the next nightly build, dated July 26 or above

Regards
Isomorphic Software

Announcement

Tahoe Skin Problem with button heights and DatePicker

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment