The dispose pattern if implemented correctly should supress calling the finalize method of the object. The GC when collectiong objects always calls the finalizer of these objects, but if dispose is implemented and the object has been disposed, u might gain this small advantage in performance allthough its probably insignificant. The main advantage is as been stated before, the release of unmanaged resources and the fact that ur helping the gc manage memory in a more efficient way.

U could, handling the paint events of the MdiClient control. But isnt easier to just use the designer to drop a picturebox with the logo where u want it instead of using background images? Maybe I misunderstood ur question.

U dont set Form.ActiveForm to anything. Its a read only property so u can't set it anyways. U read its value to know which form in ur application is the Operating System's active window. If the value u read is Null that means the active window is an external window to ur application or it could be that there really is no active window. System.Windows.Forms.Form.ActiveForm[^] When ur timer in Form B (which has started when Form B has been deactivated) triggers the Tick event for the first time, the event Handler which u should include in Form B should check for the static memeber Form.ActiveForm as I posted before. After that its just a question of style. U can either make a public get/set property in either FormA (SnapBackToB) or in FormB (SnapBackToMe) or whatever. In the first case, when A activates it would: 1) Check if Form B is open 2)check its own property and if true it would give focus to Form B. On the other hand if property was in FormB, FormA would check when it activates: 1) If Form B is open 2) If FormB's SnapBackToMe is true, it would give focus to B. As I said before, this is a question of style and there are many many ways to implement this. Of course there r some details i havent touched like handling correctly what happens when Form B is closed and not only loosing focus (remember that the Deactivate event triggers when closing a form too) and u dont want ur SnapBackToX property to remain true when ur form B is closing....but u should be able to sort that out without too many problems.

Its a tricky problem because u dont want the form snapping back to B when ur only activating A and not an external app. Still, i think u can do it this way (havent tried it but it looks pretty sound): Create a timer in the B Form with a low interval. 1-10 miliseconds will do. When B looses focus (deactivates), start timer and in the Tick handler check for the static member Form.ActiveForm and stop ur timer. If ActiveForm is FormA then dont do anything. If ActiveForm gives u Null then the active window is no longer part of ur app and u should set a property in ur A Form, for example SnapBackToB to true. Whenever A handles and Activate event, check for _snapBackToB and if true, activate Form B. That should do it. Oh, one other thing, when Form B activates, it should always check for SnapBackToB in form A and set it to False. GL, and if things dont work at all as I/u expect please let me know :p P.D. Its important u stop the timer after first tick because, even if it doesnt harm the algorithm, a timer running with that small interval may not let windows detect correctly ur idle app and u might have issues with power management, screensavers, etc.

That still leaves the problem of how to refer to, say, Player.Name(xyz) from the Room class, as that player was instantiated under System. Make the room class keep a reference to the system object that created it, or just keep a reference to ur player hashtable. U can pass this reference through the room's constructor. public Room(System owner){...} Everytime u need to get some player from a room object u can get it through your System object that "owns" the room and hass all the necessary information.

If all ur optional parameters are the same type, u can use the 'params' keyword. U could use it even if they weren't the same type, but u would need to use an object array which u dont want. Otherwise, the only solution is to overload ur 400 different functions, C# does not support optional parameters. params[^]

I'm not sure what the attribute is right now, but there is a way to make objects callable only from specified assemblies. If ur calling object is managed and u can place it in an isolated assembly then u can reach the solution u are looking for.

If ur calling the Show method of ur TaskBarNotifier in a different thread to the one where the control was created u have to use Invoke. taskbarNotifier1.Invoke(new myShowDelegate(taskbarNotifier.Show),new object[] ({"Chatter",what,500,5000,200})

Would you also kindly write the above code using windows/object code rather than the command console? The DirectX.DirectDraw.DisplayModesCollection collection contains all the information u need of the available modes of ur gfx card. U simply have to iterate through its members. These members are DirectX.DirectDraw.SurfaceDescription objects which have all the information you are looking for through its properties: Hieght (in pixels) Width (in pixels) RefreshRate etc. Basically each DirectX.DirectDraw.SurfaceDescription in the collection represents a possible screen mode in the clients computer. I just used the console so u could visibly see some of the output the collection can give u, but its up to you and how you manage the DisplayModesCollection collection and the SurfaceDescription objects contained within to extract the information u need. would also appreciate it if you would also write the code so that the code provides the "current" screen resolution that was "chosen" by the end user? I think u are referring to the screen resolution the user is using when running ur app? If so, u dont need directX for that: System.Windows.Forms.Screen.PrimaryScreen.Bounds or System.Windows.Forms.SystemInformation.PrimaryMonitorSize will give u the resolution (through Width and Height) of ur primary system monitor.

U could use managed directx to get the available modes. I'm no DirectX guru so maybe there's a much easier way to do this, but using DirectDraw its pretty straightforward and didnt take too long to figure out a way:

using Dd=Microsoft.DirectX.DirectDraw;

public void GetModes()
{
    Dd.DisplayModesCollection modes=new Dd.DisplayModesCollection(Dd.GetDisplayModeFlags.StandardVgaModes | 
Dd.GetDisplayModeFlags.RefreshRates,null,new Dd.Device(Dd.CreateFlags.Default));
    modes.MoveNext();
    for (int i=0;i!=modes.Count;i++)
    {
        Dd.SurfaceDescription desc=(Dd.SurfaceDescription)modes.Current;
	Console.WriteLine(desc.Width.ToString() + " * " + desc.Height.ToString() + " "
 + desc.RefreshRate.ToString() + " " + (desc.PixelFormatStructure.AlphaBitDepth).ToString()
 + "bpp");
	modes.MoveNext();
    }
    Console.ReadLine();

}

I cant see what is wrong with ur code...at least not to the point where the command line would give u the error ur stating, unless ur querying ParentForm.StatusBar when its out of scope although I doubt that. Whats even wierder is that, if I'm not misunderstanding, when ur application runs, your not getting any exception. Just to cover all possibilities, I'll ask u to post some more code once again...sorry :p : Please post ur StatusBar property.

are u sure ur frmEventList_Load is getting callled? Try putting a break point in the event handler and following ur code. U should see where ur code is failing to do what u expect. What u've posted looks fine but we're missing a lot more that could be wrong.

Ok, lets see if I can explain myseflt: Basically, an Event needs a delegate of the method its supposed to call when the event fires. In your example:

private void AddButtons()
{
Button B1 = new Button();
B1.Text = "OK";
B1.Location = new System.Drawing.Point(8,8);
B1.Click += new System.EventHandler(buttonB1Click);
}

private void buttonB1Click(object sender, System.EventArgs e)
{
MessageBox.Show("Hello");
}

u are using a delegate although you might not be aware of it. The delegate type is: public delegate void EventHandler(object sender, System.EventArgs e); and the instance is pointing at buttonB1Click(object sender, System.EventArgs e) if u dont see it too clearly, use intellisense and create a new instance of the delegate: EventHandler handler=new EventHandler(.....); Anyway, u will see this more clearly when u try to create ur own Events for your own classes.

Use this where it applies: if (!this.DesignMode) { //Direct3D rendering code }

A user control with two buttons and a context menu should do it.

I must be misunderstanding your problem because I cant seem to see where the problem is. Lets see if I got it straight: 1)You have a MDI application with a main MDIParent Form 2)U have a MDIChild form A maximized 3)In A u have a button or whatever that opens up a Form B through Show() or ShowDialog(this) (actually, the owner will always be the MdiParent, MdiChilds cannot own forms, but the Framework will do that for u). If thats how it is then textboxes will work perfectly fine in Form B., U can select with mouse and whatever. Are u using normal TextBoxes or are u using your own derived classes?

I've run ur code and it works perfectly under these conditions: 1) No devcomponents Could be some fault in the assembly? Have u tried running the code commenting out all DevComponent references? One thing i've noticed in your ContainerLoadControl event handler: Ur safe casting "sender" into a "BaseItem" through "BaseItem item = sender as BaseItem;" but then, on the next line, ur not taking into account that the cast might fail and "item" be a null reference. In that case "item.Name" will fail. Can ur error be in ur event handler? This error might be triggering while the form is performing native calls during loadup and thus the debugger cannot catch it properly. Try commenting it out and see what happens or try putting ur code after the safecast in this way and see what happens: if(item!=null) {//your code}

Does ur ControllerForm have any code yet? If so, can u please post all ControllerForm code that gets called when instantiating? If ur overriding any methods that might be getting called then please post them too.

DBManager could be used for wrapping all tables in the DB. If ur only updating and selecting, u could still keep the class public interface pretty simple and wrap all tables. It also depends on how u are encapsulating other objects equivalent to Members. U could even use a generic object and through Reflection and Attributes obtain the properties of the objects that represent fields in your underlying DataBase tables and thus create a very decoupled DB Manager with signatures like: Update(object changedRegistry) etc. (U could create a custom TableFieldAttribute(string fieldName) to mark the properties that represent real fields in the DB tables in order to acheive this...this comes in handy if u expect using additional properties in these objects that dont necessarily represent underlying fields). Concerning the threeway implementation, ur right about the LastOnline method, this is probably where overkill comes in :p. The utility class would not be really necessary if only these type of methods appear. Maybe u could keep the implementation to just two classes (DBManager and Member) and Member would take care of methods similar to LastOnline, as it is logical that only Member should have access to the LastOnline setter. On the other hand, if some utilities require extensive work with Member instances then the threeway solution would be plausible, keeping methods like LastOnline in the Member class as a tool for the Utility class.

I suppose it all depends on the coder's style. I'd do it this way: 1. I would create a Member class which would be an abstraction of a "real life" Member, or in other words, a Member object. It would have all the cunningly named strongly typed properties like string Name, int Id, date ExpirationDate, etc, and not much else. U could even make it a struct, but if it gets passed around a lot, it might be better to keep it as a class. 2. Then I would create a DBManager Class that would fetch, insert and update Member instances from/into the DB. This would be like your barebone original Member class but all methods/properties would be strongly typed to the Member class when necesarry:

public Member GetMember(int memberId)
{
   //Implmentation
}

public void UpdateMember(Member changedMember)
{ 
   //Implementation
}
etc...

3. And finally I would create a utility class that would perform all the functionalities upon the Member instances such as the ones you mentioned above: "UpdateLastOnLine", etc. All changes in the member instance would then be updated into the DB through the DBManager.

public void UpdateLastOnLine(Memeber member)
{
   //Implmentation
}
etc...

Hope this helps....if not quite your coding style, it might still give u some ideas. It might be an overkill for the true requirements of your app, but I always try to make my stuff in a orderly and structured fashion, even if its really not necessary.