Now, Microsoft's AJAX patterns use an implementation of IScriptControl to add javascript references to a page, but I didn't want to do that. So instead I wrote this tiny block of code in the control:
protected override void OnPreRender(EventArgs e)
{
ScriptManager sm = ScriptManager.GetCurrent(Page);
ScriptReference sr = new ScriptReference("myscript.js");
sm.Scripts.Add(sr);
}
This adds the reference dynamically at the correct point in the page's load process. Enjoy!
| permalink | related link |
( 3 / 265 )Whoah! So what happens if you have an "Object", and you don't know exactly what it is, and you want to serialize it and make sure it retains its exact shape when it comes out the other end of the serialization process?
Simple - you store the "Type" of the object as well as the object itself in your serialization stream:
public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
{
info.AddValue("ValueType", Value.GetType(), typeof(Type));
info.AddValue("Value", Value, Value.GetType());
}
To retrieve it later, follow this shorthand:
public MySerializedObjectConstructor(SerializationInfo info, StreamingContext ctxt)
{
Type t = (Type)info.GetValue("ValueType", typeof(Type));
Object Value = info.GetValue("Value", t);
}
| permalink | related link |
( 2.9 / 230 )Let's say you've got an object and you want to save it somewhere. Everybody knows you can serialize this object to a file, but file storage isn't always the optimum solution. What if you want to just keep this object in memory somewhere? I can think of a few different types of storage:
* Memory
* String
* Cache
* ... and so on.
So, you want to take this object and turn it into a string and save it somewhere. Strings are such fundamentally useful objects that they fit into pretty much anything. However, when Microsoft designed serialization, they specifically decided that strings weren't going to be a valid destination.
Instead, we need multiple steps in our code. First, we convert our object into an in-memory stream. This results in a whole bunch of binary garbage that won't be a valid string in and of itself. So, to turn this into valid text, we use an encoding method called Base64. This method takes all the unprintable binary data and converts it into something we can store in an ASCII string.
Base64 works by figuring that it can encode 64 different values safely into a single byte (which can store up to 256 different values). If you're familiar with binary logic, you'll notice that we're changing an 8-bit value into a 6-bit one. This means that for every three bytes, we require four ASCII characters to store the resulting value. This means that we need to preserve the exact original bytecount of the memory stream, otherwise we risk padding an extra zero or two onto the end of our data.
So, the code ends up doing all the work with a few short lines of code:
public static string SerializeBase64(object o)
{
// Serialize to a base 64 string
byte[] bytes;
long length = 0;
MemoryStream ws = new MemoryStream();
BinaryFormatter sf = new BinaryFormatter();
sf.Serialize(ws, o);
length = ws.Length;
bytes = ws.GetBuffer();
string encodedData = bytes.Length + ":" + Convert.ToBase64String(bytes, 0, bytes.Length, Base64FormattingOptions.None);
return encodedData;
}
public static object DeserializeBase64(string s)
{
// We need to know the exact length of the string - Base64 can sometimes pad us by a byte or two
int p = s.IndexOf(':');
int length = Convert.ToInt32(s.Substring(0, p));
// Extract data from the base 64 string!
byte[] memorydata = Convert.FromBase64String(s.Substring(p + 1));
MemoryStream rs = new MemoryStream(memorydata, 0, length);
BinaryFormatter sf = new BinaryFormatter();
object o = sf.Deserialize(rs);
return o;
}
| permalink | related link |
( 3 / 205 )Does your text file have more characters than just plain ASCII?
Typically, the lazy man (myself) opens a text file using this command:
StreamReader sr = File.OpenText("C:\\batchtoimport.csv");
However, if you have any high ASCII characters, ISO-8859-1 characters, UTF-8 characters, or whatever you want to call them, you will need to actually tell .NET what encoding your file will use so they can be interpreted correctly.
Remember, all your strings are being converted into Unicode internally. So if your file is encoded using something odd like 7-bit ASCII, .NET needs to know to ignore the 8th bit. The way .NET knows this is that it is told your conversion encoding when the streamreader is created. Here's what you do:
StreamReader input = new StreamReader(new FileStream("C:\\batchtoimport.csv", FileMode.Open), Encoding.UTF8));
Yes, I know this is a really simple issue. But when you're so used to just typing "File.OpenText", sometimes you need just need help to remember the correct answer.
FYI: If you want ISO-8859-1, which is usually always the correct answer, the correct encoding value is Encoding.GetEncoding(28591).
| permalink | related link |
( 3 / 218 )It's always this way: something really simple, like logging on a user, is difficult to figure out, but really easy when you find the answer.
I was hunting through the code looking for a "Membership.LogonUser(username, password);" function, but then I remembered - this stuff is actually handled through FormsAuthentication. So we determine this by using their cookie system.
Let's say you have a user, "bob_roberts", and he's just completed a complex, five-page registration form on your website. You don't want to make him log on by himself after he's gone through all this work. So here's what you do:
HttpCookie cookie = FormsAuthentication.GetAuthCookie(Customer.username, false);
Response.SetCookie(cookie);
Fun!
| permalink | related link |
( 3 / 206 )Back Next
Calendar
