Hi,

I've just uploaded the latest version of VsaControl for IE on GotDotNet.

Why would you care about VsaControl?

* It lets you embed JScript .NET code directly inside a client-side IE web
page (VB .NET is also partially supported)

* It lets you easily handle events fired from .NET controls inside a web
page

* It lest you build rich HTML / WinForms hybrid applications

* It shows how to host a VSA engine in a "script" scenario

If you are interested in doing any of this, check out:

http://www.*-*-*.com/

It should be noted that this control requires FullTrust to run, so is not
really appropriate for general Internet usage (only intranet usage).

Peter

P.S. XML FormBuilder has also been updated;
http://www.*-*-*.com/

--

Waiting for the Vengabus? http://www.*-*-*.com/
Please post all questions to the group. Thanks.

Hi Peter,

Any special reason for not supporting C#? Is it planned?

Thanks,
-Victor.

Hi,

Good question. The main reason is that C# is not exposed as a script engine
in .NET.

The bigger reason is that it doesn't make much sense for a client-side web
page (where everything is late-bound) to be written in a language that does
not support late binding. You code would consist of endless Reflection calls
and be incredibly hard to write, understand, and maintain. (Of course this
only applies to OM manipulations; code that doesn't interact with the DOM
can be early bound in any language)

It would be possible to do add it, using the CodeCompiler, but I just
haven't gotten around to it yet. It's on my (long) list of things to add,
but it's closer to the bottom than the top I'm afraid.

Peter

--

Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.

I was anticipating some of your answer while I was asking the question but
then your really fast response didnt allow me to anticipate the rest of it
:)

Thanks,
-Victor.

Hi,
one question regarding this theme:
I have read (I think it was an article by Dino Esposito) that JScript.Net
will not be part of a future IE version, because it's main usage scenario is
server side. Is this right? The readme of your download says

"This sample is provided as a demonstration of the kinds of solutions
that might be possible if JScript .NET were to be incorporated into
the browser at a future point in time"

and this sounds as MS thinks about integrating JScript.Net into IE.

Thanks,
Konstantin

--
PIRONET NDH
Dipl.-Wirtschaftsmathematiker Konstantin Breu - Senior Consultant - SBU
Software
Josef-Lammerting-Allee 14-18 - 50933 Cologne - Germany
Tel.: +49 (0)221-770 1801 - Fax: +49 (0)221-770 1005

Besuchen Sie PIRONET NDH auf der CeBIT 2002 in Hannover, Halle 6, Stand C
04, vom 13. bis 20. M?rz.
Visit PIRONET NDH at CeBIT 2002 in Hannover, hall 6, booth C 04, from March
13th to 20th.

Hi,

There are no concrete plans for this at the moment but that could change.

We are looking for customer feedback on this (there is very little so far).
Embedding JScript .NET inside the browser is definitely a "cool" thing to
do, but unless customers come back and say "Hey, this would really make my
life easy!" or "This enables a whole bunch of new scenarios for me" it's
probably not going to happen.

Peter

--

Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.

a bigger problem is that there is no .net based browser control. currently
you can use the com based browser, but then your .net code is unsafe (will
not run off a network share or from a download, unless security settings are
changed). But as application security gets tighter, I see com support
falling fast from.net applications. IT department are going to want trusted
applications only.

almost all window apps nowdays host the browser control, for web integration
if nothing else, but often for the ui. we really need a .net html browser
(which would presumably run jscript.net).

-- bruce

Whilst not opening any new scenarios (COM and various plugins and JScript
provide similar abilities) it would make those easier to develop -
although depending on how well Mozilla comes along and if they can ever
sort out a plugin-archetecture I'd stick to what worked on more than one
platform.  However I do deliver a lot of resources which work purely on
the client and the practical impossibility of using JScript.NET in this
enviroment means I won't use it all, so yes JScript.NET in a browser will
make my life a bit easier, but not that much, however it will mean
JScript.NET being actually used.

Jim.

Additional support of JScript.NET would be good, but if the support of
JScript 5 (and ActiveX?) would be discontinued because of the .NET-support
("Internet Explorer.NET"), then I would not be happy. There are some issues
which I don't like in the JScript DHTML world:
- when a DHTML app needs special permissions, then the complete site gets
these permissions; I can't give special permissions only to some pages or
script parts of the site.
- the offered HTML UI elements are poor, I have to use ActiveX components
for many issues. ActiveX components have installation problems at Win2000
(cannot be installed by normal users).
- the script based interaction with the browser could be very much better
(for example: print customization, browser authentication control). Again I
need ActiveX components for many issues.

That means: In a rich IE-based WebApplication I need very much (often
un-secure) ActiveX components, and I fear that for security reasons, such an
application will not be acceptable any more, in a couple of months. So right
now I could
- write a secure large ActiveX component (or Windows application), which
contains the whole application, and is not html based
- write a secure large Swing application
- write a web application without ActiveX (cross browser, "reach
application")

But I don't like large components, I don't want to program Swing
applications, and I don't want to write applications with poor gui comfort.
I like JScript and I like DHTML.

If .Net components and JScript.NET would help me, to solve the problems I
have with ActiveX, then I would try to migrate my solutions to .NET.

Regards,
Konstantin

--
PIRONET AG
Dipl.-Wirtschaftsmathematiker Konstantin Breu - Senior Consultant - SBU
Software
Josef-Lammerting-Allee 14-18 - 50933 Cologne - Germany
Tel.: +49 (0)221-770 1801 - Fax: +49 (0)221-770 1005

Sorry about that empty message, 2nd try;

Peter,

No concrete plans for a managed Internet Explorer? I hardly believe that! Of
course this would make the life for me and probably a lot of other customers
easy.

Currently I see three types of Internet applications; thin (ASP.NET and
generated (D)HTML), thick (DHTML & HTC's) and fat (local installed &
compiled applications). I am looking for a solution that lies somewhere
between that thick and fat types because of my following application needs;

 * A rich and fast UI; HTML still lacks advanced controls like a Tree. (yes,
I know the TreeView behavior, but don't try to put more than a 1000 nodes in
it).

 * Fast server response times (caching data on the client needed, ASP.NET
roundtrips are not a solution)

* A large code set (script in (D)HTML is just too limited; slow
(interpreted), lacking true OO features (i.e. no inheritance) and uses too
much memory (try to instantiate a 1000 big VBScript classes).

*My clients don't want to perform some kind of manual installation of 3rd
party software on top of a default installed workstation (dotNET supplies
auto install).

In this case, a managed IE hosting the CLR is the solution. IMHO, a managed
IE fills a gap where thick DHTML applications are too light and fat local
applications are too thick.

Two final notes;

 * I really don't understand why MS hasn't released a managed IE control
yet. The COM control needs FullTrust, that's out of the question for
Internet Applications. And how hard can it be? I saw a managed MS Word
application on some conference, so where's the managed IE?

 * You guys at Microsoft want to put the .NET CLR on every desktop in the
world? Just release managed IE7 + CLR!

Thanks for reading,

Koen

Hey, this would really make my life easy!

This enables a whole bunch of new scenarios for me

--
Thor Larholm
<URL: http://www.jibbering.com/faq/> FAQ for comp.lang.javascript

Come now, that's cheating just a little bit ;-)

Peter

--

Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.

Please note that I didn't say that -- I said at the moment we have no
concrete plans to embed JScript .NET inside IE.

Microsoft is investing heavily in rich client technologies that leverage
.NET, but it's too early to talk about specifics.

Thanks for your feedback though. It sounds like you don't actually want IE
per se (DHTML was not good enough for your tasks), you want a
zero-deployment story... you already get that today with managed controls /
managed EXEs that can be run / launched from IE

Peter

--

Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.

Yes, but it's friday and I'm in a hurry - I'll have to owe you on the lengthy
explanation ;)

--
Thor Larholm
<URL: http://www.jibbering.com/faq/> FAQ for comp.lang.javascript