By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,931 Members | 1,422 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,931 IT Pros & Developers. It's quick & easy.

Response.TransmitFile - Windows Mobile 6.0

P: n/a
Hi,

I have use the following code to transmit a file back to the browser that
worked fine on a HTC_TTyN device running windows mobile 5.0. The code
executes in the onclick event of a mobilelist control. Now on a similar
device running window mobile 6.0 the file is not displayed - the link causes
a post back succesfully and the code appears to execute - on the browser a
bar is displayed breifely at the bottom of the window (although ist show 0KB
to the right of the bar.) - seaming to indciate that a file is being
transferred but the file save option (or the file) does not appear.

Does any one have any ideas why this is not working ? I suspect it may be
something that is specific to the HCT_TTyn devcie as we have identifed a
separate issue where the browser capabilities where not being detected
correctly - this was due to the fact that the useragent string was being
prefixed with 'HCT_TTyn ' - to work around this we have defined a new
htctty.browser file and registered it with asp.net which seams to have solved
all the problems we were having - apart from this file transfer issue.

protected bool SendFile(string filePath)
{
string fileName = System.IO.Path.GetFileName(filePath);
if ((fileName != "") && (System.IO.File.Exists(filePath)))
{
try
{
Response.Clear();
Response.ClearHeaders();
Response.ClearContent();
Response.ContentType = "application/octet-stream";
Response.AddHeader("content-disposition", @"attachment;
filename=""" + fileName + @"""");
Response.AddHeader("content-length", new
System.IO.FileInfo(filePath).Length.ToString());
Response.TransmitFile(filePath);
Response.Flush();
Response.End();
Response.Close();
return true;
}
catch
{
return false;
}
}
else
return false;
}

Nov 26 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Hi Woodgnome,

As for the file downloading issue you mentioned, I think your analysis is
reasonable. for mobile or smart device requests, the http useragent is the
default evidence of the device and ASP.NET runtime will probably respond
quite different due to it.

I think you can make some simple tests to verify the behavior. You can use
some .NET winform client application to send http request(with the
useragent set to the same value as your smart device), if the response (you
can view it through some network trace tool or directly get it through
network component such as HttpWebRequest) still give the same problem
result, the problem should be caused by the device's useragent. And for
such case, I think customize the server application's browser/device
detection setting should be the reasonable method.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>Thread-Topic: Response.TransmitFile - Windows Mobile 6.0
thread-index: AcgwM8zdaNC3/emhQ3OlyEuh+rCpgA==
X-WBNR-Posting-Host: 82.110.100.247
From: =?Utf-8?B?V29vZGdub21l?= <wo*******@community.nospam>
Subject: Response.TransmitFile - Windows Mobile 6.0
Date: Mon, 26 Nov 2007 05:54:01 -0800
>
Hi,

I have use the following code to transmit a file back to the browser that
worked fine on a HTC_TTyN device running windows mobile 5.0. The code
executes in the onclick event of a mobilelist control. Now on a similar
device running window mobile 6.0 the file is not displayed - the link
causes
>a post back succesfully and the code appears to execute - on the browser a
bar is displayed breifely at the bottom of the window (although ist show
0KB
>to the right of the bar.) - seaming to indciate that a file is being
transferred but the file save option (or the file) does not appear.

Does any one have any ideas why this is not working ? I suspect it may be
something that is specific to the HCT_TTyn devcie as we have identifed a
separate issue where the browser capabilities where not being detected
correctly - this was due to the fact that the useragent string was being
prefixed with 'HCT_TTyn ' - to work around this we have defined a new
htctty.browser file and registered it with asp.net which seams to have
solved
>all the problems we were having - apart from this file transfer issue.

protected bool SendFile(string filePath)
{
string fileName = System.IO.Path.GetFileName(filePath);
if ((fileName != "") && (System.IO.File.Exists(filePath)))
{
try
{
Response.Clear();
Response.ClearHeaders();
Response.ClearContent();
Response.ContentType = "application/octet-stream";
Response.AddHeader("content-disposition",
@"attachment;
>filename=""" + fileName + @"""");
Response.AddHeader("content-length", new
System.IO.FileInfo(filePath).Length.ToString()) ;
Response.TransmitFile(filePath);
Response.Flush();
Response.End();
Response.Close();
return true;
}
catch
{
return false;
}
}
else
return false;
}

Nov 27 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.