So I have a report that requires scrolling row and column headers, I have checked the boxes on the tablix properties page that state 'keep header visible while scrolling' for both row and column headers. When viewing the report, the headers behave as I would like.
The problem arises when the report is deployed and then viewed in Microsoft Edge, Internet Explore, or Chrome. The headers do not remain visible, and makes the report pretty unreadable.
I have seen previous questions that claim to answer this problem, but I have had no success. People point to deselecting the boxes I mentioned earlier, and then going to 'advanced mode' on the grouping pane, and changing FixedData from False to True. This doesn't seem to work, and not even in the preview of the report, which worked with the boxes checked. I am using a matrix, and not a table, and some of the 'answers' I have seen, seem to talk about only working on a table.
To be honest, there seems to be a lot of confusing comments related to this issue, and I am at a loss as to what to try next.
Has anyone managed to find a solution to this problem, or could they point me to something that may help?
Related
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.
My report is a bunch of tablixes, one for each row (because the expressions are different for each row). They are all lined up and sized exactly the same, and the textbox property for CanGrow are set to False.
All tablix Locations are x = 0.34993in
All textbox sizes are x = 0.58333in
When viewing in MS IE, it looks as it should:
Beautiful, and maybe a little sassy.
When viewing in Chrome I get this mess:
Obviously this is the worst thing to happen ever.
I'm stuck in the middle here because IT doesn't support Internet Explorer, and so SSRS report consumers have to choose between half of their screen real estate being taken up by this silliness:
Or a poorly rendered SSRS report in Chrome.
Maybe somebody can just tell me which setting is making Chrome go crazy and fix that?
I'm not completely happy with this answer, but it's definitely the best solution in terms of ease of implementation: IE tab for Chrome
https://chrome.google.com/webstore/detail/ie-tab/hehijbfgiekmjfkfjpbkbammjbdenadd?hl=en-US
Display web pages using IE within Chrome. Use Java, Silverlight, ActiveX, Sharepoint, and more.
Puts an IE window inside of Chrome, answers all of my concerns.
I am facing speed issue problem in handsontable in mozilla browser. Whenever I am writing anything in cell then press "Enter" key to go to next cell then it is taking around 3-5 seconds to move to the next cell. I am facing this speed problem when there are so many records in a sheet.
Please help me out from this situation. To see this problem, you can go on following:
http://www.promact.semanticexcel.com/
And login with following details:
username: test
password: test
and then open "LSA_Output_2nd.txt" sheet and then try to work with this sheet then you will notice speed issue. Please have a look and let me know if any solution you have. Thanks.
I couldn't actually log into your test site, but your problem seems like a common one. Hansontable re-renders the whole table on any cell change. The best way to work around this is to limit the height of the table, then only visible rows will be rendered. See the demo page on scrolling: http://handsontable.com/demo/scroll.html
However, if you have many columns in your table, what you gain in editing performance, you lose in scroll performance, since all newly-visible rows need to be rendered when scrolling, which greatly worsens responsiveness. I'm yet to find a better alternative.
I am having an issue with an email template that has two tables aligned to left in one cell to make it responsive, but making it into a responsive isn’t the issue here.
When I opened up in Outlook 2010, the right column drops to the bottom and hangs in the right column. I noticed it only happens when the left column content is long.
Here is the HTML code:
Long left column: http://jsbin.com/aRUGOXu/1/edit?html,output
Short left column: http://jsbin.com/iGaFabo/1/edit?html,output
I read one of the article from Email on Acid and applied it, but still no luck. http://www.emailonacid.com/blog/details/C13/removing_unwanted_spacing_or_gaps_between_tables_in_outlook_2007_2010 and applied it, but I ran into the same issue.
Here is the example that I did:
http://jsbin.com/eTAdOMe/1/edit?html,output
This is known as the Outlook page break issue. One of the wonderful MS word rendering quirks. You'll need to shorten your long column to avoid this issue. Here is some reference:
http://www.emailonacid.com/blog/details/C13/horizontal_spacing_issues_in_outlook_2007_and_2010
Mailchimp also does a good job of explaining the cause (although it is in their context)
This article suggests using <tr style="page-break-before: always">, although I've never tried that technique myself.
I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.