divil

Offering $50 is laughable.

Only the bottom two files in that list need to be registered. It looks like perhaps you're missing the actual ActiveX controls that the top assemblies are wrapping - the common dialog and common control ocxs. I can't for the life of me think why you'd be using them as .NET has its own wrappers for those win32 controls. If the COM registration type still doesn't work, isn't there a ComSelfReg one? I'd try that.

Yes, the only built in way is through CodeDom. You could serialize the CodeDom using a BinaryFormatter if you wanted. Alternatively, MS has a designer host sample of their own now (I don't have an url) which includes XML serialization.

http://www.pinvoke.net/ This is a Wiki for people to contribute declarations for win32 apis etc. A great resource for getting ready-written p/invoke calls without having to read includes.

Implement IEventBindingService, you'll find that's where the double-clicks are eventually routed in most cases (unless DoDefaultAction is overridden).

There is currently no windows forms control to display ActiveX (ole) documents. In the next release of .NET and Visual Studio, this will be addressed with the ActiveDocumentContainer control.

Looks nice, but it's nothing that won't be in the next version of Windows too.

The designer already has methods you can override to gain this functionality. See the CanParent method.

I'd go with drawing manually. You'll likely end up with a solution faster and smaller than using labels, and like you say, much more flexible.

http://www.bobpowell.net/grayscale.htm

VB.NET is a typesafe language. You cannot have "as any". Instead, replace that with the actual type of whatever you want to pass.

I think you'll have to go through the pixels checking. If you do this with pointers in C# it should be lightning fast. Check out the BitmapData class if you haven't already.

You should not call OnPaint(null). If you do, how are you going to actually use the method to paint anything, since you have no PaintEventArgs and therefore no Graphics?

At a glance, it looks like your SubItemConverter is returning the constructor for TextData, not SubItem like it should.

You need to give your property a TypeDescriptor, and override its GetStandardValues method. Searching for those two keywords should get you a load of samples.

You have to open the code files and set breakpoints in the debugger, i.e. the second instance of Visual Studio. Go to Debug -> Exceptions and tell the debugger to break the first time any exception is thrown, that's the easiest way of stepping through code that falls over in the first instance.

Pass false instead of true when you create your InstanceDescriptor, and a local variable will be declared in InitializeComponent to configure the object before it is added. I highly recommend providing more constructors to handle this though, as I have found local variables in InitializeComponent to be unreliable.

Ok, I managed to get your serializer working. You're right, you don't need nearly as much stuff in your ConfigureItemStylesEventHandler method as I had in mine as you're not dealing with components. The bare minimum you need to do is create your object and add it to the collection, no DesignerHost is required, you just create it using the normal constructor as it's not sited. You'll want to do a little more than the bare minimum though, and let the IComponentChangeService know what you're doing so undo and redo will work: c = (IComponentChangeService) GetService(typeof(IComponentChangeService)); newItem = new TextData("test", Color.Red); //(TextData) h.CreateComponent(typof(TextData)); c.OnComponentChanging(MyControl, TypeDescriptor.GetProperties(MyControl)["TextDataCollection"]); MyControl.TextDataCollection.Add(newItem); c.OnComponentChanged(MyControl, TypeDescriptor.GetProperties(MyControl)["TextDataCollection"], null, null); You were also opening a DesignerTransaction and not closing it, which will completely screw the designer up. That's all I needed to do to get your collection serializing. Bear in mind you can gain a lot by implementing an AddRange method on your collection, which the designer will use instead of repeated Add calls if it's available.

Look up indexers. public int this[int col, int row] { get {} }

Create it first, then add it.

You will have to rethink your design, as you cannot tell if something is being run in design mode from the constructor. You can apply a designer to a component, you just have to derive your designer from ComponentDesigner instead of ControlDesigner.

That control is not shipped with Visual Studio .NET, it is not part of the product and you shouldn't really be using it in a .net application anyway. The Winsock control has been replaced with the Socket and TcpClient classes.

Yes, the Adobe products have the same problem. What can I say, I'm a perfectionist!

I disagree with your statement about splash screens having to be topmost. I haven't known an application do this for a few years, I assumed nobody did it anymore because it became widely accepted to be too annoying. Splash screens should not be topmost. They should not even steal focus in the first place, let alone disappear when they lose it. Presumably if this is being used correctly the application will be loading its resources while the screen is displayed. You think API calls are "messy"? Maybe someone needs an introduction to windows programming :)

That's C# - VB doesn't do it. Actually I think it might do in VS Whidbey.