Visual Studio Report Viewer 2010 with Internet Explorer 9 - reportviewer

My company has a system running in asp.net using the report viewer to display some reports. After upgrading to Internet Explorer 9, the reports are not displayed correctly when using different zoom from 100%. The problem not occurs when the compatibility mode is seted on IE.
The problem is easy to be reproduced and i upload some screenshots at https://picasaweb.google.com/102746433851783529556/ReportViewerScreenCaps#
In the test, I used the examples available in http://archive.msdn.microsoft.com/reportviewer
When viewing with zoom in "Page Width", the top of the report is cut.
When you view with the zoom in "200%", a track is added on top of the blank report. The problem occurs whith the versions 9 and 10 from rv control.
Is there a hotfix or workaround for this?
Thank you.

Related

ReportViewer 15.0.0.0 - Remove PageWidth and WholePage option from Zoom dropdown

We have an MVC web application, and recently we migrated from Microsoft ReportViewer from 11.0.0.0 to 15.0.0.0 version.
We started having different issues in terms of UI, one of which is mentioned as below.
The Page width and Whole Page options in zoom dropdown are not working as expected. When we select any percentage like 100% or 200% the report zooms properly.
However on selection of Page Width or Whole Page nothing happens. And the report remains in the zoom which ever it was already.
So I have below 2 questions
Does any one have idea why these options does not work with ReportViewer 15.0.0.0 ?
As a work around we would like to remove these options from this dropdown. How can we remove these 2 options from this zoom options related dropdown
Below image shows about which dropdown I am talking about. Please note that this issue comes when we use ReportViewer control 15.0.0.0 with our MVC web application.

ReportViewer 15.0.0.0 shows scrollbar along the parameter and report body section

We have an MVC web application, and recently we migrated from Microsoft ReportViewer from 11.0.0.0 to 15.0.0.0 version.
We started having different issues in terms of UI, one of which is mentioned as below.
When we run the report from SSRS (SQL Server 2016), we can see that the vertical scroll bar is displayed only in the report body section, as shown in below image
However when we display this report from our MVC web application, the vertical scroll bar covers the parameter as well as report body section, as shown below
Any idea why we are facing such issue with ReportViewer 15.0.0.0 ? We were not facing such issue with ReportViewer 11.0.0.0
Following is the screenshot of how we have used ReportViewer control

SQL Server 2016 vs Internet Explorer

I have several reports created with multi value parameters. They are deployed to the report manager and run fine from chrome. When ran from Internet Explorer 11, when a parameter is chosen, I cannot click on the down arrows or scroll bar of the multi valued param. When I do it closed the param and would not scroll. I can use the scroll wheel but clicking does not work. This only happens in IE 11 which happens to be what 90 percent of our users use. Any ideas on a fix? This is SQL Server 2016.

Oracle MAF: Clicking on Input text fields in a dialogue popups causing random crashes under Windows 10 Anniversary Edition

We have implemented a tablet-based application using Oracle MAF. The application runs on Windows UWP. When it was rolled out last year, it has been working fine until the customers upgraded Windows UWP on their laptops to Windows Anniversary edition. After some investigation, We found the following issues:
When user clicks on input text fields in a popup dialogue, the
application randomly crashes (not always but frequently).
When user clicks on input text fields in a normal window (i.e. not in a popup dialogue), and if the screen resolution is scaled (e.g. 150%), the
application also randomly crashes.
When screen resolution is not scaled (i.e. 100%), clicking on input text fields in a normal window
does not seem to cause crash. However, clicking on input text fields
in a popup dialogue can still cause crash.
We could not find any useful/relevant info in Windows log or in our application log.
We have also tested our application with the latest Windows Creator Edition and MAF 2.4.1, we found that the chances of random crashing seemed to have decreased, but crashing could still happen.
We have checked the Oracle MAF certification information at http://www.oracle.com/technetwork/developer-tools/maf/documentation/maf241certmatrix-3746359.html.
It states that "Any tablet or desktop running Windows 10 with Intel processor" are supported. Our customers' laptop specs are:
Lenovo Yoga with Intel Core i5 processor;
Windows 10 Anniversary Edition;
Full High Resolution screen (1920x1080)
Therefore, we believe the customer laptops provide certified runtime environment for MAF applications.
We have researched various technical forums. There seems to be little information about using MAF under Windows UWP environment.
Because our application has been used in production, and the customer corporate mandate is to use Windows 10 Anniversary edition, the customer expressed grave concerns to us for choosing MAF as the mobile platform technology, and we are now under enormous pressure to fix this issue. Any suggestions and pointers will be highly appreciated.
If you can create a reusable test case, my recommendation to you is to lodge a Service Request with Oracle Support so Oracle's development teams can look at this.
We have done further investigation on the issue "input text field causing crash on Windows 10 Anniversary Edition". This time we used the demo CompGallery application from Oracle. We navigated to the "text box" tab, clicked on the text box in "outside a form", entered some text, then clicked on "inside a form" text box. The application crashed (or repeat the above sequence a couple of times on Windows Creator Edition, the application would crash). Note by using "tab" key or screen tapping to navigate between input text fields, we can avoid crashing. With extra clicks on different input text fields before entering text, we can avoid crashing as well.
The CompGallery screen is shown below:
We then looked at the Windows log, not much details were revealed. It contains an event related to the failure of edgethtml.dll, as shown in the screenshot below.

Windows-8 & Internet Explorer-10 broke my ActiveX control drawing?

I am experiencing a very weird behavior while running my Active-X control on “Windows 8” OS, and browser “Microsoft Internet-Explorer 10”.
The control:
My Active-X control is very stable product that my company is already distributing for several years between hundreds of happy customers. The control is an ATL custom-draw control, written in C++, and built with “Visual Studio 2008”.
The problem – the drawing disappears:
While I press the link that opens my control for the first time, I can see that my control is being painted gradually (as my data loading is sometimes slow), but eventually all the drawing disappears, leaving a blank white background color where the controls is located.
Using ‘Spy++’ I can see that my control is really there, but all its painting disappear.
If I move the browser or change its size the control will be re-painted, but otherwise it is simply not visible.
I tried to debug this problem and find out who is erasing my drawing.
I came up with the following technique:
Using WinDBG I added breakpoints at ‘user32.dll’ DLL on the following methods: user32!InvalidateRect, user32!InvalidateRgn, user32!FillRect,
I defined these methods to only show stack and continue with to run,
I ran the above problematic scenario,
When the problem happens I am trying to view who called ‘Invalidate’ or ‘FillRect’,
Since all this happens very quickly I am using the ‘Print Screen’ button to freeze the moment
After doing this several times I find that exactly at the time my control disappears the following stack calls ‘user32!FillRect’:
user32!FillRect
MSHTML!memcpy+0x9805
MSHTML!COmWindowProxy::SwitchMarkup+0x468
MSHTML!CMarkup::SetInteractiveInternal+0x428
MSHTML!CMarkup::RequestReadystateInteractive+0x98
MSHTML!CMarkup::BlockScriptExecutionHelper+0xde
MSHTML!CHtmPost::Exec+0x794
MSHTML!CHtmPost::Run+0x1c
MSHTML!PostManExecute+0x5f
MSHTML!PostManResume+0x7b
MSHTML!CHtmPost::OnDwnChanCallback+0x3a
MSHTML!CDwnChan::OnMethodCall+0x19
MSHTML!GlobalWndOnMethodCall+0x169
MSHTML!GlobalWndProc+0xd7
user32!InternalCallWinProc+0x23
user32!UserCallWinProcCheckWow+0x100
user32!DispatchMessageWorker+0x3ef
user32!DispatchMessageW+0x10
IEFRAME!CTabWindow::_TabWindowThreadProc+0x981
IEFRAME!LCIETab_ThreadProc+0x378
iertutil!CIsoWinMsg::PostQueuedMessagesToComponent+0x4b
IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x66
KERNEL32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x72
ntdll!_RtlUserThreadStart+0x1b
This is consistent.
When examining this stack I found that this message belongs to a window of class Internet Explorer_Hidden, which is window of size zero (0x0), but with a WS_VISIBLE style. This window belongs to the browser.
Does anyone know this phenomenon?
Is it possible that the browser hidden window is causing this problem?
Could you recommend on other approach to try and hunt the stack that is erasing my drawing?
Many thanks for any hint!
Paz Offer
Conclusion:
The bug was in Microsoft Internet Explorer 10
I used Microsoft Support service to farther investigate this problem. Enclosed here are the findings:
Microsoft Support viewed the version of my IE (Internet Explorer) and suggested to first upgrade IE to its latest patch.
As it happens, the machine I was working on was not setup to be automatically updated by the Windows Update service for some time. As part of upgrading IE I had to first update windows using Windows Update service to its latest patches.
During the process of Windows Update the Microsoft Internet Explorer 10 was automatically updated to its latest patch.
Once IE updated the problem disappeared.
In addition, the ActiveX GUI load process became much faster.
The old version of Microsoft Internet Explorer 10, which caused the problem:
Version: 10.0.9200.16384
Update Versions: RTM (KB2718695)
The new version of Microsoft Internet Explorer 10, which solved the problem:
Version: 10.0.9200.16635
Update Versions: 10.0.7 (KB2846071)
Now all is working as expected.
Thanks, Pazo