I don't know of any hard-core Socket programming books specifically for C# off the top of my head, but if you don’t mind C, I have found the TCP/IP Illustrated references I, II, & III, and especially the UNIX Network Programming Volume 1 by W. Richard Stevens pretty good. Regards

I could be off the mark here but couldn't you just let serialization happen naturally and mark the fields in the graph that you don't want serialized with [NonSerialized()]? Regards

I agree, I was not discounting your solution, just the consequences. I actually have requested the SDK and SWF file format from Macromedia (there automatic registration for this is down at the moment) to see what it would take to develop a pure .NET solution. DirectX 9 (coming soon) is supposed to have full .NET support, it could be very interesting. Cheers

This doesn’t sound like a very usable solution if you have to convince your clients to degrade a 3rd party (possibly non-related) component to a previous version just so you’re about box (or entire application) will display correctly. I would hope that Macromedia addresses the problem soon, or an alternative solution becomes available. I did see the COM component you were talking about, but in my case, it refused to instantiate, period. I assume that is what you where referring to when you said “it doesn’t work”. Regards

In terms of cleaner code, if the class carries a significant amount of initialization that is common across all constructors, yes a shared initialization member can be cleaner. I have also seen cases where these initialization members also become a reset mechanism for the class. Not that this is a bad thing, but in large projects and/or as time goes on and maintenance coding kicks in, it may be easier for a member of your team to forget what the primary purpose of the member was and start calling virtual members within it, which is a bad thing. My two cents. Regards

Again, its personal preference. In overhead terms, there really is nothing to pull off; the initial constructor does generate a call to the target constructor. If you were going to supply a common private initialization member, it may accomplish the same thing with or without parameter passing. If your initialization member is parameterized, I would venture a guess that it carries the same amount of overhead. Regards

It’s more personal preference issue, although I don’t see how it could be a bad practice and in this case it is an integral part of the language. Code reuse (outside of cut and paste) is never a bad practice in my opinion. Regards

I don’t believe you can Interop with a class defined this way directly. You will either have to COM’ify the class, or build a managed wrapper around it in MC++, or rebuild it under VS.NET as a managed class. Regards

class Foo
{
int value;
public Foo()
: this(0)
{
}
public Foo(int i)
{
value = i;
}
}

There is a Win32_TemperatureProbe class in the WMI hierarchy that looks interesting, you can get to it via the System.Management namespace. I have never played with tracking down the CPU temp, so I could be off the mark here. Regards

Nish [BusterBoy] wrote: but I have explained my reasons for smiling in my reply to Neil Van Note The smiles where not the reason I thought you sounded insulting. It was the fact they are surrounding what you said, I quote... Nish [BusterBoy] wrote: Yeah, When he got the 0, he thought it was an error Either way, I am dropping it... Regards

I beleive SysInternals may have something similar to what you are looking for w/source in C. Regards

Again, Try a IsWindow(hWnd) on the return value; it can't be assumed that it returns anything consistent, including null. The docs just do not specify null is or is not an invalid value.

Nish, There is no reason to slam people for asking a question. Educate me, which functions that return window handles return something other than NULL to indicate a failure. Like I mentioned above, IsWindow is a much safer check, as the documentation for GetDesktopWindow doesn't indicate it could fail. I wonder what this returns for a process that is running in a state where there is no desktop? In addition, HWND_DESKTOP, which is defined as ((HWND)0), fails IsWindow(HWND_DESKTOP) under Windows XP Pro. I haven't checked Windows 2000 yet. Regards

The only time I have seen INVALID_HANDLE (INVALID_HANDLE_VALUE) mentioned is for operations on file handles. i.e. CreateWindow/CreateWindowEx return NULL on failure. NULL is a common failure result when dealing with window handles. IsWindow is a safer check. Regards

GetDesktopWindow() does not necessarily return 0. It does not on my machine (Windows XP Pro), this morning it is returning 0x00010014. Regards

DateTime.Now.ToString("HH:mm") should do it. "hh:mm" for a 12 hour clock. There is also DateTime.Now.ToString("t") and DateTime.Now.ToShortTimeString(), the latter just turns around and executes the former. These last two are locale/culture aware. Regards

I was wondering the same thing recently. I am keeping my eyes peeled. There is a bunch of Java based source for this floating around on the web, if you’re feeling ambitious…

I think there is a sample in the C# section called LiveCode.NET that does something similar. I havent checked it out yet, but I am sure you have seen it in any event...

My wizard solution is something used by the clients developers, so it is more of a component than an application builder. Just out of curiosity, and I am definitely not the one that would try to stifle your ambition, but why are you trying to reinvent the wheel that was just built? It would seem to me that if you expose a good object model, extending an application built with .NET would be trivial without all of this, just having the clients developers use .NET to build extensions. Or are you looking for a mini environment like VBA in outlook? Regards