Our web page is only available internally in our company and we am very intrested in being able to offer interactive .net usercontrols on our departments website in the .Net 2.0 enviorment. I have been successful with embeding the object as so:
<object id="Object1" classid="http:EmbedTest1.dll#EmbedTest1.UserControl1"
width="400" height="400">
<param name="TestStr" value="Test Param String" />
</object>
The control worked just fine and the value was passed to the control without issue.
But I had a problem with passing subsequent values back to the embedded control
attempt to Recieve event from control:
attempt to update control:
<script type="text/javascript">
function UpdateStr()
{
Object1.Text = "update string";
}
</script>
Reference:
http://www.15seconds.com/issue/030610.htm
http://windowsclient.net/articles/iesourcing.aspx
Questions:
Is this technology outdated? - if so is there a replacement
Should I just work with action script instead of trying this?
I have got this to partially work and I was attempting to connect to a webservice that I have running and I got many security exceptions...I didn't get the same exceptions when I used action scipt2 in the same manner?
(side note : - how do i paste html script examples?)
Thanks.
Brad
Not out-dated so much as rarely used, and IE-only. If you want web-like deployment for desktop apps, use ClickOnce. If you want C# code that runs in the browser without security issues, use Silverlight. You could also look at XBAPs, which are sandboxed WPF apps that run in the browser, works on IE and Firefox, but requires the full .NET to be installed client-side, whereas Silverlight does not have this problem. Bottom line: look at Silverlight.
That's certainly an option. If you're more familiar with the Microsoft stack, you should try Silverlight, where you can code C# against a subset of the .NET framework right inside the browser.
We've used .NET controls in web pages internally and had a wide variety of strange issues, mostly related to scripting or security. Hard to determine the problem without more information.
p.s. write all code examples using the <pre> tags. There's a "code sample" button on the toolbar.
If the things that you are doing with the Windows Controls could be done with ASP.NET web controls instead, I recommend that you consider switching. You'll have much better control over the exchange of info from the client to the server.
1, 2) Yes it is outdated. If you want to work in .NET (and you're bent on having a control rather than an ASP.NET-style page/site), give Silverlight a try instead.
3) .NET code running in the browser is subject to very strict security controls (can't call back to a web site it didn't come from, for example).
Related
kindly tell if there is any way to solve the connectivity of the vcsharp with asp.net. as i am trying to run the c# windows form application on asp.net to make my website more knowlodge able. Is there any other connevtivity option besides aspnet.
You can run web application in windows Forms application. You may embed the WebBrowser control. It makes sense, but if you want to run desktop application in a asp.net web this doesn't make sense IMO.
If you want to benefit from Rich Controls behaviors, you have web widget available within jQuery UI, BootStrap, etc.
Don't mix things
EDITS: According to your first comment, I'd suggest you to search for the web sdk for arcgis or an equivalent. Or You may need to reference dll available in the SDK and use web controls to display data
Plz read this
I want to run my WPF application on asp.net web application. Actually I have a WPF page.xaml which contain the image viewer, which actually open image and edit it as required.
Now I want to embed that in my Asp.net Web application. I have a asp.net web application user control on which I want that WPF stuff. I research on it on the internet, I find a way that we first publish the WPF application on the IIS server and then past the URL in asp.net web application page iframe. as I follow this below link:
http://msdn.microsoft.com/en-us/library/aa970060.aspx#deploying_a_xbap
now I not want to follow this approach. I want an alternate way of this. Is there any way to handle this scenario. If yes then how can we achieve this?
Yes there's a better way: you can use Silverlight (basically it's a C# equivalent to Flash).
Even if Silverlight is quite the same as WPF, there is some differences due to the fact that silverlight is made for web. So you'll have to make some changes to your application.
About integrating it in your page, it seems quite simple:
You can use an object html element (as you would do with Flash)
Here are some links about that:
http://msdn.microsoft.com/fr-fr/library/cc838145(v=vs.95).aspx
http://www.c-sharpcorner.com/uploadfile/raj1979/host-silverlight-in-Asp-Net/
2 years later, a possible answer appears! Maybe someone else will see this and get some use out of it.
I have been hearing rumors that it is possible to run your WPF application in a browser, it's called an XBAP?
https://msdn.microsoft.com/en-us/library/aa970060%28v=vs.110%29.aspx
I am about to give this a try myself, I'll update this answer with any limitations I find.
I am new at C#.Net and i have one question that i couldn't manage to find on the internet. When should i use a classic combination of html + javascript + css instead of using an aspx page with a code behind?
As i experienced since i started .net , i found that aspx pages and code behind is a huge ease for developers. I didnt need any piece of javascript code since i started. There must be something wrong. I think i am missing a point. Can you answer my question and tell me some examples that i must use html+javascript+css instead of aspx + aspx.cs or vice versa??
Have a nice day.
Javascript is a client side technology, running only in the browser, whereas ASP.NET runs on the server side. These allow you to achieve different and complementary things.
With a classic server side language, any user interaction that you want to respond to must typically be posted across the internet from the browser to your server. It is then processed by the server, which responds with a new page for the browser to load. This generally means that the response time for the user is slower, though you will have access to a much richer programming environment on the server.
With a client side language, everything is processed on the browser. This allows for faster feedback to the user, though at the expense of working within the much more restricted programming environment that the browser gives you, and with no access to stuff your application may depend on, such as your database.
Of course, the lines are blurred somewhat when you make an AJAX request (usually a call written in Javascript that makes a request to the server, receives the response, and updates the page dynamically).
You mention that you have not used any Javascript so far. Perhaps as a starting point you'd like to investigate validating user input on the client side? This way, errors are caught and reported to the user immediately without the cost of the round trip to the server. http://www.tizag.com/javascriptT/javascriptform.php
Both client side and server side technologies can be powerful and useful. Use a combination of them both to give the best experience for the user.
In my experience, using Javascript/jQuery in .NET has been for UI and client-side validation purposes. If you are building an app that does not require Javascript to meet your client's requirements, then take advantage of what .NET has to offer. However, implementing Javascript is not that hard, so feel free to use what you prefer and is in the best interest of the client. You can still write and use Javascript in an ASPX page.
One of your considerations might well be speed. Javascript in a web-page will run on a site visitor's browser. Code-behind runs on the server hosting the page.
from my experience the main aim to use the companion of html,css,javascript with asp.net when the client needs is for a web app that acts exactly like win app
that u don't need to flush over the page to the server and come back again
Points you are missing
Code behind is not what makes ASP.NET; you can make a web app with all C# code right into the aspx files.
If you choose ASP.NET and C# for a web app, all your pages should be aspx ones, except for very specific and not very common situations.
You need to understand the difference between server side scripting and client side scripting. ASP.NET is a server side scripting technology while javascript is a client side only one. Take a look.
You can create aspx pages that are as simple as you want -even without any relevant serverside scripting- and thats all right.
Attempt to answer
You use the word must, so:
You must use aspx instead of only javascript if you want any kind of server side processing.
You must use an html file with plain javascript, jquery and css if there is the specific requeriment to do so, wich would be very uncommon. That could be a situation where a) the page should be as fast as it can possible be b) you don't mind everyone to be able to see your full code by just selecting view source on the browser c) there is no need at all for server side processing d) you don't mind about the little extra mix of technologies on your web application.
You use Javascript/JQuery to perform operations that does not need any server side processing like validating controls for a range or for empty values, some fancy UI stuff. It is much faster than the code behind because it does not post back to server however you could use UpdatePanel aspx server control to have partial post back and avoid reloading the page.
As a web developer you should always use combination of server-side processing and client-side processing. Working logic and application processes on the client-side allows browser based applications to seem more responsive and to have more "snappiness" to them.
If you are looking for highly customizable and high performance pages, then I would go with html + javascript + css and make calls to some webservice. This way you are not restricted by asp.net controls. Also, there are a lot of caveats with standard out of the box web forms that can lead to page performance issues and overhead - ViewState being one. You can also design your own asp.net controls as well, but there is some learning curve.
It really boils down to personal preference (there isn't anything in one that you can't do in the other) : Fundamentals vs Abstraction. To me javascript has always felt somewhat cumbersome when used in conjunction with webforms, however, with mvc it is a lot more natural, as it would be with a standard html + javascript + css page.
When you want to create static pages you can use html+css+javascript instead aspx.
In case you want things more dynamic you have to use aspx with cs.
For more info go http://www.w3schools.com/aspnet/aspnet_pages.asp
Can someone tell me how to retrieve an ActiveX component with an OBJECT tag?
On my ASP file I have retrieved an ActiveX control with the following code:
<OBJECT classid="clsid:A919AF5F-637C-423E-835A-B56448C1AD9B">
</OBJECT>
The result is that the Activex control popup on the web page..so far so good.
The problem is that this piece of code always look for the ActiveX control
on the Client machine, I want the ActiveX control to be retrieved from the
server (of course)
In the documentation for the OBJECT tag, I saw that there was an attribute
called RUNAT=Server that should be included to get the object from the Server
instead, so I tried with the following code to retrieve the ActiveX from
the server instead of the clients machine
<OBJECT RUNAT=Server id=whatevername
classid="clsid:A919AF5F-637C-423E-835A-B56448C1AD9B">
</OBJECT>
...but, when I do like this, the ActiveX control doesn't show up. Can someone
understand why ?? Is it neccesary to instantiate the "whatever"-id before
I use it in the OBJECT-tag, or can this id be set to whatever value ? ....I
only want the ActiveX to show up in the clients browser, WHAT is wrong ??
ActiveX is a client-side technology only. It is designed to allow COM objects registered on the client machine to be instantiated in the browser.
Therefore, the question you should be asking is "How do I install/register my COM object on the client PC".
Bascially, you will need to add a codebase attribute to your object tag, specifying a URL to your (correctly packaged) ActiveX object. e.g.:
<object
classid="clsid:<guid>"
codebase="http://mydomain.com/path/to/mycabfile.cab">
</object>
The ActiveX object will typically be packaged in a CAB file and, if it was written in .NET, then it will need to be packaged in an MSI inside the CAB file.
For information on deploying a .NET ActiveX component from a web-server, please see my answer here.
For information on deploying a non .NET component, just search Google - it's much more straightforward than the .NET way!
Finally, if you are in an intranet environment, don't forget to consider using Active Directory Group Policy, or a similar technology (like SMS), for deploying the ActiveX component - it might be a lot simpler this way.
ActiveX showed up initially as client side component standard in 1995 but 4 years later became standard for server side wbe apps. All classic ASP web application systems/PHP/ColdFusion/Perl on Windows were built with non interactive ActiveX sever side components allowing increase of performance for interpreted VBScript-based web application code and access to all kind of APIs and distributed COM functionality on server side.
COM+ added possibility to run these components in efficient way e.g allowing pooling of COM+ applications/COM objects/threads.
ActiveX is a simplified version of OLE with only a two mandatory light weight interfaces to be implemented by COM component to be ActiveX (vs numerous interfaces required by OLE): IUnknown (lists available properties/methods exposed by ActiveX component) and IDispatch for late binding of methods and functions.
ActiveX server side support allowed simplistic generic type-based web app programming style without need to care about type declaration.
It supported popularity growth of XP programming style and Agile SDLC in general.
I am building a windows forms application that I will be adding a control within that will display quite a bit of different data. For the most part the data inside will be navigation buttons and help/training text.
I think it would be ideal if I could write the contents in HTML and then just display that in the control in the application, but I am not sure if this is a good idea.
Another point to note is there will be a web based version of the same application at some point in the near future, and doing this part of the application in HTML will make for very easy reusability.
The users will not have IIS installed, if this matters.
For this purpose, I think that an embedded web browser would be absolutely great. Alot of applications use a web browser control for navigation, information, training, etc. Steam is one example. In addition, reusability is almost always a best practice.
But I would use WebKit instead of the built-in IE web browser control.
I have a similar application and I think the WebBrowser control works very well. If you think it's what you need, I would for it and there's many other applications that do something similar. You can call Javascript functions in the HTML page from C# using HtmlDocument.InvokeScript(), and C# from Javascript using window.external and having this two-way communication makes life simple.
Users do not need IIS installed as you're not running a web server, just displaying content using HTML.
I would go for the built-in IE control rather than webkitdotnet to be honest. Although WebKit itself is superior to IE, the webkitdotnet project at version 0.5 it doesn't have the C#<> JavaScript communication or DOM access and it seems hard to tell if it's still being actively developed. It'll be great if/when it gets feature parity as IE is obviously far from perfect, but the advantage of the built-in IE control is every user of your app will have it already installed and the WebBrowser control is well tested. There are some disadvantages I've found:
IE versions may range from 6 to 9, so you'll to test to make sure your content works in all (as with a website).
There's a bug in IE (at least up to 8) that relative links do not work in combination with a <base href="file://...">. This can stop you being able to use relative links in your local HTML documents.
Sometimes pages display differently inside the WebBrowser control than they do out of it. For instance, http://bugs.jquery.com/ticket/7104 is one and I've come across another similar bug affecting cufon.
For compatibility reasons, even if your users install IE > 7 the WebBrowser control will still render your content in IE7 rendering mode by default. This is different to standalone IE which renders in the most-standard mode by default, so it can catch you out if you're not expecting it. You can change this by adding <meta http-equiv="X-UA-Compatible" tag if you want, though I actually found it makes life easier as it reduces the amount of different versions you've got to test against.