October 2007 - Posts
There a lot of things to think about when it comes to serializing static fields, how it will be stored, how it will be reinstated, duplication of data, and design. Although, it usually is a sign of bad design if you are trying to serialize static fields, there are some cases in which you need to. In which cases, some work arounds are way to tedious, for what you are actually trying to do, especially some sort of templating. Well here's one way you can do it.
public class Desk {
private static string _manufacturer = "Hard Furniture - {Id}";
private static string _serial = "HFSTYLE{Id}";
private int _id;
// Properties to serialize static fields
public string Manufacturer {
get { return _manufacturer; }
set { _manufacturer = value; }
}
public string Serial {
get { return _serial; }
set { _serial = value; }
}
// Properties
public int Id {
get { return _id; }
set { _id = value;
SetupLocals();
}
}
private
void SetupLocals() {
// Assign local based on static
someLocal = Manufacturer.Replace("{Id}", Id.ToString());
someLocal2 = Serial.Replace("{Id}", Id.ToString());
}
// Constructors
private Stop() { }
public Stop(int id) {
Id = _id;
}
}
Have you ever been developing a Windows Forms application, and then somewhere in the form you want to create a new Timer (System.Threading). When you do this you run into a ambiguous reference problem because System.Windows.Forms already contains definition for a Timer. So, usually you just end up prefixing wherever you want a Threading Timer by adding the "System.Threading" text in front of it. Although, this does work it creates harder to read code, there is a solution.
using
System;
using t = System.Threading;
using tTimer = System.Threading.Timer;
using System.Windows.Forms;
namespace AmbiguousReferences {
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e) {
Timer winFormsTimer = new Timer();
t.Timer threadTimer1 = new System.Threading.Timer(ShowMessage, "Timer 1", 500, t.Timeout.Infinite);
tTimer threadTimer2 = new tTimer(ShowMessage, "Timer 2", 500, t.Timeout.Infinite);
}
private void ShowMessage(object msg) {
Invoke((MethodInvoker)delegate() {
MessageBox.Show(msg.ToString());
});
}
}
}
I have seen a lot of code lately using "is" instead of "as". I just want to get the word out there that it is much better to use "as" as it is more efficient. For example, here's a sample code post using "is":
if
(someType is Point) {
Point myPoint = someType as Point;
// Use myPoint as needed
}
This post actually casts the object stored in someType twice, to see if it is indeed a Point. Now, look at the following post using "as" which is more efficient. This only casts the object stored in someType once.
Point
myPoint = someType as Point;
if (myPoint != null) {
// Use myPoint as needed
}
Assigning the Icon of a window in WPF, should seem rather simpllistic and straight forward. You should be able to simply grab an icon, say the question mark from SystemIcons.Question and practically just assign it to the Window's Icon property. Oh, but of course not! The Icon property is implemented as a ImageSource, now you have hit a war battle, trying to figure out how to convert this damn Icon into an ImageSource. Well, here's how you do it...
http://infosysblogs.com/microsoft/2007/04/wpf_assigning_icon_to_image_co.html
As you can see from above this post is about using WCF in Windows Services. This means anything I talk about below will be considered a long running service, as this is the point of Windows Services.
Singleton
Session
Per Call
I've finally figured out a way to install Windows Media Player 11 on Windows Server 2003. This has been the only thing holding me back from running Windows Server 2003 on my developer machine.
http://www.msblog.org/index.php/2006/12/17/install-windows-media-player-11-on-windows-server-2003/