A nice GPL alternative to Visual Studio.. :-) Make sure you had the .NET 1.1 SDK (rather than 1.0) and then download #Develop, it's a free development environment for .NET on Windows supporting C# and VB.NET through the SDK.. debugging features, etc. I'm not really a .NET developer so can't help you on the ActiveX question, although there is a wizard/template in #Develop to create 'controls'.. which might be along the lines. #Develop has a nice SDK help interface too, so at least it'd be easier finding some answers :-) Best of luck.

Oh, I should've thought of that.

There's a fork for Unix called MonoDevelop.

The ui restrictions on code running through internet are severe, but I haven't tried hosting Windows.Forms within I.E. Thanks for the tip.

Writing a Windows.Forms application with Microsoft's free C# compiler (part of the .NET framework SDK) is pretty easy. You just need to write the stuff that VisualStudio.NET would write for you, which is basically just a bunch of constructors and an add in a subclass of a container much like Java Swing.

I've no idea what you'd do under Mono, but I assume the code would be identical assuming the relevant classes and methods are available in Mono's implementations of Windows.Forms.

As said above, one doesn't typically write an AX component in C#. .NET has its own interop stuff that isn't really the same as COM.

I think if you want to have it run on IE without any kind of extra installation at all, it's going to have to be native. .net is still new enough that most people don't have it installed, and it's a 20MB+ download for the redistributable.

I'm sure it's possible with COM Interop (ActiveX objects are just COM objects with a certain set of interfaces), but it wouldn't be worth it. You'd need the .net runtime on every machine it ran on, and by then you might as well use windows forms controls.

You *MIGHT* be able to compile the MSIL code into x86 (using a tool provided by MS), link it to any .net dependencies, strip out the MSIL, and distribute it, but that's a lot of work and I'm not sure it's ever been tried before (or even possible).

Hm, I didn't think of the native converter. You're still stuck with a bunch of dll dependencies with it, though, I think. I'm not sure how far you can go with including extra deps in a .cab file, so maybe it's still possible.

Be a big mess though, that's for sure.

WebMatrix maybe?

A while back I wrote a little mandelbrot fractal explorer with Windows Forms in .Net and stuck it in a web-accessible directory. I noticed later that if I went to the URL, the app just opened up. I didn't have to download/install anything. It was pretty cool. (It was running in a sandbox of course.)

http://www.ljbox.com/youngoat/misc/FractalExplore.exe

Not sure if this will suffice for your purposes. I don't know about embedding a winforms application in a webpage.

I know you already know Java (S2 compiler) so what are you doing that can't work with AWT in a Java applet?

I'm sure you'd be doing something majorly interesting before you'd consider a Microsoft-only solution…

FB upload client.

Even if we force a flush of a new HTML page out to the client while they do a typical web upload, the browsers don't render it until their uploads are done. Laaame.

A Java applet can do this, right? I've not played much with applets, but my understanding is that they can attempt socket connections back to the server which served the applet under the standard security rules. The sockets stuff has been in Java forever, and if you stick to AWT it'll work basically everywhere. .NET on the other hand will only work in IE for people who have explicitly installed the .NET runtime.

I have the .NET framework SDK installed but I don't use IE, so this would be useless to me. I also know several Windows XP users who aren't computer people who don't have .NET installed. It seems that most people who would have .NET installed are sensible enough to realise that IE is junk and people who don't will usually not have the .NET runtimes installed. That might be a gross over-generalisation but I'm sure it holds true in a lot of cases. That's before you even consider Mac users!

The choice seems obvious to me.

But I don't think you're alowed to break out of the sandbox and access local files under the defaults. Atleast not without some serious prompting of the user.

I'm pretty sure the same is true of .net assemblies loaded from web pages.

I'm thinking of those dialogs that come up and say "You want to let this program take over your computer? If you don't click yes, you won't be able to play this fun game."

Ignoring the local file access problem that mge pointed out, most Windows users nowadays don't even have Java installed.

But I agree Java is the right thing to do for Mac users.

Java on Linux sucks (at least on Debian) because it's non-Free.

Really, everything sucks. I can't wait for a shift to standardized fat clients.

I imagine you could make something that only relies on javascript and dhtml. The upload page could be split into two frames, with one hidden. When you click submit, a javascript function changes the look of the main frame (to something like, "uploading... please wait", with a progress bar), causes the hidden frame to go to a special URL that monitors the progress of the uploads, and flushes out javascript code that updates the progress bar in the main frame, and starts the form submission in the main frame. Very hackish, but it might just work.

"and I have Mono"



::giggles::

I just stumbled upon this while googling for something else...
Hosting .NET Windows Forms Controls in IE

I can't get it to work with IE6 and Win2k SP 4. I have the .NET 1.1 runtime and SDK installed. I even added my site as a trusted site.

Does it work for you?

I didn't try it. I just happened upon the link by accident. If I have time I'll play with it tonight or this weekend maybe.

So, by "tonight or this weekend" I meant "never" Hope you don't mind. =]