Hello,
I have a RadFileExplorer on my web form. When I select an Excel file (.xlsx) and choose 'Open' from the context menu the file is converted into a '.Zip' file and my options are either of the following: 'Open (The file wont' be saved automatically), Save, and Save As).
How can I prevent the file from being changed to a '.Zip' file? Is it possible to set a property that would just keep the file as is, an Excel file with (.xlsx) extension?
Here's my markup for my RadFileExplorer:
<
telerik:RadFileExplorer
ID
=
"rfeNASFileExplorer"
runat
=
"server"
Width
=
"980px"
Height
=
"750px"
AllowPaging
=
"true"
PageSize
=
"50"
EnableEmbeddedSkins
=
"true"
Skin
=
"Windows7"
EnableFilterTextBox
=
"true"
EnableOpenFile
=
"true"
>
</
telerik:RadFileExplorer
>
Thanks,
Shawn A.
5 Answers, 1 is accepted
I tried to reproduce the reported behavior, but the *.xlsx files are opened/saved as expected on my side. Can you provide a little more details on the scenario in which the problem occurs? Can you take a look at the video from my test and see whether I am not leaving anything out? - http://screencast.com/t/7Mg1Nt5WWOu
I made my test in all Firefox, Chrome and IE using the latest version of our controls (2016.1.113).
Regards,
Vessy
Telerik
Hello Vessy,
Thank you for your reply. I do not get the same options as you in the context menu. I've attached some pictures to show you what I do get.
The RadFileExplorer control in my application is located within a WebUserControl that gets loaded into a RadTab, but I don't know if that would make a difference. Also, I'm using Telerik control version (2015.3.1111.40). The application runs on IE8 or IE11, and it is developed in Visual Studio 2015. I tried upgrading my application to use 2016.1.113 but I run into problems where the loading panel icon will not go away after a page is loaded so I reverted back. Thanks.
Regards,
Shawn A.
Usually the prolong showing of an AJAX panel is caused because of a broken AJAX request. Were there any errors thrown on the page when you experienced the issue?
I tested FileExplorer with the used by you version of the controls but its opening functionality behaves as expected with it on my side. Can you provide some more details on the exact scenario in which you are using the FileExplorer control?
- From the attached screenshot I can see that the problem occurs in IE. Are you experiencing it in all version of the browser or only in a specific one?
- Are you using some kind of custom downloading logic (e.g. using a generic handler)?
- Is FileExplorer updated via external AJAX request in your application?
It would be best if you send us an isolated runnable version of your code so we can reproduce the issue and examine the problematic markup on our side.
Looking forward to your reply,
Vessy
Telerik
Hello Vessy,
Thanks for your reply. I was using a handler that I had downloaded from the following site: Use RadFileExplorer with physical and shared folder's paths
After reading your comment I realized that it may be the handler that is causing my issues and I believe I found a solution. I needed to add the following lines of code within the "ProcessRequest" method. After adding these lines I was able to download "xlsx" files and they were not .zip any longer.
if
(Path.GetExtension(physicalPathToFile).Equals(
".xlsx"
, StringComparison.CurrentCultureIgnoreCase))
{
WriteFile(physicalPathToFile,
"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
, Context.Response);
}
if
(Path.GetExtension(physicalPathToFile).Equals(
".xls"
, StringComparison.CurrentCultureIgnoreCase))
{
WriteFile(physicalPathToFile,
"application/vnd.ms-excel"
, Context.Response);
}
Thank you for your help.
Also, when I upgraded my Telerik controls to the new version I did not get any errors. In-fact the analyzer said that the upgrade was successful, and I did not have any errors in my code. At this point, with the older version running, everything is working fine and without errors, but as soon as I upgrade I get the hanging loading panel. I'm hoping that the next upgrade will fix this issue. In the meantime I will use 2015.3.1111.40.
Regards,
Shawn A.
I am glad to hear that my suggestion was helpful for you in narrowing down the source of the problem. The MIME type is the way the browser understands how to threat the downloaded file, so it is important to match the actual type and extension of the file.
Feel free to reach us again should we can be of any further assistance on the future.
Regards,
Vessy
Telerik