|
can anyone tell me what kind of help C# or .NET Framework provides to find all/any I/O device(s) installed in the system?
|
|
|
|
|
None. .NET (btw, C# is a language that only targets .NET - nothing special in and of itself) is a higher-level platform. C# and a few other languages that target the CLR do let you use lower-level programming with pointers in an unsafe context, but P/Invoking (calling Win32 native functions) what you need to accomplish what you want, and creating all the structs and what not, would be very time-consuming. Using C# (or the .NET Framework in general) would not be the way to go.
If you need this information in a .NET application, consider putting such functionality in a Win32 DLL and P/Invoking it, or - perhaps better - create a COM object that does this and get that information in a much simplier COM interop call.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Is there any way to make a single control usable on both Windows Forms and Web Forms?
|
|
|
|
|
Interesting question... doesn't a forms control have to inherit from System.Windows.Forms.Control and a web control System.Web.UI.Control in order to function correctly in their repsective environments?
Are you looking to make any control in particular?
|
|
|
|
|
yup actually i was thinking why repeat the code for them separately but looks like it is not possible to do so on the lines of Activex controls , they were usable in both kinds of apllications. Intersting thing is that , since Windows forms control is derived from Component class and Any Component derived from Component class can be used in a web page. IF that is right then why can't we use a Windows Forms control in a Web Page?
|
|
|
|
|
Muhammad Nauman Khan wrote:
IF that is right then why can't we use a Windows Forms control in a Web Page?
You can. There are 2 ways to do this. One way is to create a .Net .exe as usual, then just navigate to the executable on the webserver; IE will use IEExec.exe to run the .exe in a sandbox. If your application is a Windows Forms app, the Form will be displayed as a new window.
Another option is to compile a System.Windows.Forms.UserControl as a .dll library, then reference that dll in an html's object tag like so
<object
="" id="anID
" classid="http:myAssemblyDll.dll#namespaceHere.ClassToInstanciateHere" height="300" width="300">
Where namespaceHere is the namespace containing the class to instanciate, and ClassToInstanciate is the name of the class whose constructor to call.
When using the latter method (UserControls in html), the UserControl will appear embedded inside the webpage, much like a Java applet would. For more information on using .Net assemblies in Internet Explorer, see www.csharphelp.com/archives/archive109.html or http://www.windowsforms.net/Forums/ShowForum.aspx?tabIndex=1&tabId=41&ForumID=17
Both of these options will work even from non-IIS servers such as Apache, buth there's more server scripting code needed to be done in order to get it to work on non-IIS servers.
Another option is the newly released (first released on Oct 6th) J# browser controls[^] Basically you could use them much like you would Java applets. If you don't like J#, you could write a small front-end in J# that would simply launch one of your C# assemblies.
The graveyards are filled with indispensible men.
|
|
|
|
|
Thought I'd throw up an example. Have a look at this System.Windows.Forms.UserControl embedded in an html page: http://www.pressenter.com/~bhimango/t3.html
It's simply a user control with a button and a tree view. Click the button to add a node to the treeview.
Unfortunately, IEExec doesn't interpret system colors, which is why all the controls have a white background. :P
The graveyards are filled with indispensible men.
|
|
|
|
|
To add good scripting support, see my article on DevHood at http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=388. I'm porting this and expanding upon it in several ways to move it over the CP by the end of the month.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
In .Net you can inherit only from one base class, so this is not possible.
Another way is to host WinForms control in web browser, but this works only with new versions of IE.
|
|
|
|
|
|
|
Very good article, Heath. I'm putting that one in my favorites. 
Any idea how to get around the SystemColors issue?
The graveyards are filled with indispensible men.
|
|
|
|
|
Nope. Even a reply in the same thread above ours was saying something about that. The control just refuses to use / understand it.
If you want, though, colors can be passed as params in the control (even without coding, so long as the property is public and you pass an enum name from the SystemColors). I haven't tested this doing it with system colors, but it does work for web colors. I just know the control can't be initialized with system colors.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Yeah, you can even set the color of a control inside the class constructor without trouble.
Figures, though. MS isn't really pushing this technology yet, maybe due to odd bugs like the SystemColor issue.
The graveyards are filled with indispensible men.
|
|
|
|
|
I wouldn't say that. They have mentioned it several times. This "technology" is nothing new or ground-breaking, though. .NET is essentially built on the fundamentals of COM, as it is a natural progression from COM (which is a natural progression from OLE). The ability to host the control comes from the CLR exposing the .NET control through a CCW, which is better developed by programmers to be scriptable (i.e., an automation server) and versioned correcly.
I think you typically don't see these because embedded controls such as this are increasingly becoming stagnant and ill-used. When's the last time you saw an ActiveX control that was useful and not some spy- or ad-ware (like CometCursors)? I think they realize this.
Besides, every application has specific requires. Most applications are either light-weight web applications or heavy-weight client applications (either installed or deployed over the network). Very few, I think, could be satisfied in such an HTML-embedded manner.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
When's the last time you saw an ActiveX control that was useful and not some spy- or ad-ware...
Wrong: All what you see inside of yours IE is COM object exposed as HTML element. Yes, they are all windowless, but they are all COM controls.
All plugable MIME types are resolved as COM objects too.
ObjectBands, Toolbars and etc. are COM objects.
MSFTs Automation Document architecture viewable inside IE is pure COM.
Scriptable Hosts (VBScript, JavaScript and etc) -- COM.
So, what are you talking about? Of course ActiveX controls are useful...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Yeah, duh. I've been studying this stuff since OLE was early in its stages. The point I was making (read: intent of content) was ActiveX controls used in the content of HTML pages, like MSNBC's OLD navigation bar or the stock ticker control that you don't see much of anymore. I'm well aware of how IE is built and run, thank you.
With DHTML and server-side processing being used much more for dynamic content these days, there is far less ActiveX controls and Java applets being embedded in a web page than before. At least with Java, you can be somewhat sure that a JVM is installed on a user's computer and the security model is more simplified (and perhaps not quite as good).
With .NET, it's still early and not many people have it yet (especially, as we're seeing, the more cynical and paranoid corporate networks), and uses a much tigher control. You know how in .NET 1.1 that the Internet_Zone code group has at least SOME permissions? It was a lot of proof I presented to Microsoft via my MSDN Subscription accounts (and I probably wasn't the only one) that helped prompt that. Even the permissions they decided on don't let controls do much.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
It was a lot of proof I presented to Microsoft via my MSDN Subscription accounts (and I probably wasn't the only one) that helped prompt that. Even the permissions they decided on don't let controls do much.
And so what? Your point was: that ActiveX controls are not used much anymore.
Wishfull thinking: they are used alot and will be used for very long time.
You are talking about security issues and etc. I'm talking about business: MSFT can start and stop support for anything at any time. What about you? What if you invested your time/resources/money into development of some very usefull ActiveX? And now this is your only source of income: you beleived in MSFTs hype about ActiveXs and you've done your part + your customers are pretty happy about your product...
Now, if I correctly follow you: you are are one of many prompting MSFT to stop support of ActiveX inside IE? Is this true? So, what's your agenda here? And who are you to do that? Is this prompted by something else then trying to grab the market share? What is that?
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Can you read English? You're totally mis-reading my comments and putting words in my mouth.
I was saying that I don't see near as many ActiveX controls embedded in a web page as there was even a short 2 years ago! Then, ActiveX controls (and Java applets) where all over the place. Java applets are still pretty oft-used, but it seems that fewer and fewer ActiveX controls embedded in HTML pages (I'll once again make the distinction, although you'll probably miss it a third time) are being used.
I'm not against ActiveX. I use it often for a great many things, and I often needlessly expose my .NET controls for CCWs just in case I decide to interop them later. Where in the hell did you get that I oppose ActiveX? I'm merely making an observation based on countless sites that used to use ActiveX and now don't.
And I'm not speaking solely about security issues. I'm speaking about - at what the original post was hinting - how embedded user controls are, perhaps, not pushed by Microsoft because 1) it is nothing new and is based on the fundamentals of COM, and 2) is often trouble-some because of the framework support and security, yes. ActiveX isn't sandboxed and uses only a couple constraints. .NET is far more picky and requires (typically) far more effort to "enable" on a client machine than what it's worth, especially when ultra-thin clients like web applications or thick clients like Windows applications are more effective.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
OK, thanx for clarification.
Contrary, I see not less ActiveX controls embedded in a web page as I used to see them 2 years ago. However, I agree with latest MSFTs responce to Eola settlement, we may find less of them someday. But again, it just demonstrates my point of MSFT being able to stop/start anything at any time.
Regards
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
I don't think this will necessarily deminish the ActiveX controls we see now, such as Flash, Acrobat (Reader), QT, etc. (regardless of activation, i.e. in-place vs. MIME handler). I am hopeful that Microsoft (et. al., even some open-source players are backing them on this) will defeat EOLAS and perhaps take the prior-art argument mainstream once and for all. If not, users may be greatly annoyed by Microsoft's solution (among others), but the major ActiveX controls are still required for such content (at least for a few years to come - who knows what the future will hold).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
But there are instances where html simply won't suffice as far as functionality or a rich UI. I think there are many instances where this technology could be applied.
It's interesting you mention ActiveX being overly used as adware - I'm a big fan of Wildtangent 3d technology (which has heavily relied upon Java applets and ActiveX for years now), and the company has recently been the focus of a lot of privacy issues (they are getting better now though). It seems that companies can make a lot of money off of users' information, and ActiveX controls in the past have been a nice way to harvest that information. So your points there are very valid IMO.
On that note, managed controls could address these issues in many ways. IE could prevent managed apps from doing certain things, such as launching other ActiveX controls (requires higher security clearance), doing file IO, etc. This could potentially prevent managed controls from being used as spyware - IE could limit or prevent the information the control has access to on the client machine.
I think in the end this technology will be used mostly for streamlining the deployment process, not necessarily as an alternative to ASP.Net, though that idea has been thrown around inside MS. We'll have to see.
That said, I wonder if managed DirectX 9 will run right in the browser...that'd be cool. 
The graveyards are filled with indispensible men.
|
|
|
|
|
Actually, all this stuff is already controllable by the CLR (not IE). This means that the control accessed in any way (other than a custom host that doesn't abide by the rules) falls under the same restrictions (see .NET security permissions, policies, code groups, etc. for details). For instance, you could say that any control in the URL http://www.somedomain.com/* or http://www.somedomain.com/somesite/* can have certain IO control, control over the UI and clipboard, and much more (you can even customize these permissions that are used by the code in question but must be installed locally to be used during initialization of the CLR). This shouldn't be a function of IE, and, rightly so, it isn't. It's a function of the CLR - the very thing that "runs" .NET.
That said, IE does enforce some control on ActiveX controls as of late (IE 5.0+). The control must implement certain interfaces and belong to certain COM categories to do certain things, but nothing even close to .NET or Java. IE's security control also gives you some control over what ActiveX can do, but it 1) isn't as restrictive, and 2) doesn't allow for as much "matching" as in .NET. For instance, you can say that signed ActiveX controls from a particular zone can do X, but unsigned ActiveX controls from the same zone can only do Y. And you get 4 zones from which you can choose. This further breaks down into safe ActiveX controls and unsafe ActiveX controls (those that implement those interfaces and catagories I mentioned before. All together, that's something like 4 zones * 2 signed states * 2 safe states = 16 possibilities (roughtly). In .NET, the possibilities are countless (even with the default membership conditions, since granular control is possible).
As for DirectX, that would be kind of cool, but would probably be far too dangerous. SVG (if ever finished / widely adopted) does give you dynamic control over most basic things you can do with DirectX (such as object-oriented graphics, control, and some basic meshes(?)) and is fully scriptable (I think that's the part that's holding up the committee). You could, however, make a .NET embedded control that is a graphics surface with which you could use DirectX, should it be installed on the user's machine (but that's pretty much the case for anything like Flash, QT, etc., sans ActiveX itself on a Windows computer with IE 3.0+).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I think a lot of responces here suggesting writing WinForm UserControl and hosting it inside IE are valid solution in having the same source base.
However, the most important thing is not touched by those answers:
WebForm Control usage doesn't require client to run .NET, while WinForm controls will require .NET runtimes installed on the client.
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
True, good point. Fortunately .Net will be installed everywhere come 2005-2006. 
The graveyards are filled with indispensible men.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Sheep | [baah]](https://codeproject.freetls.fastly.net/script/Forums/Images/sheep.gif)
