|
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.
|
|
|
|
|
True, good point. Fortunately .Net will be installed everywhere come 2005-2006.
... And by that time as described in Avalon/Longhorn preview: Windows Form will be considered "legacy" .NET programs.
"...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
|
|
|
|
|
Hahah how the years go by....I suppose by then we'll be running 3d rich GUIs in our Windows apps. Maybe we'll not even need programmers - we'll just tell the computer what to do. 
The graveyards are filled with indispensible men.
|
|
|
|
|
Maybe we'll not even need programmers - we'll just tell the computer what to do.
... Hope by that time computers will perfectly understand Chinese
"...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
|
|
|
|
|
Hi!
Anybody know how to put IStorage or IStream interface into NET clipboard?
(with example please)
Good Luck
Alex Kucherenko
|
|
|
|
|
This really requires quite a bit of knowledge of OLE/COM. Remember that the .NET clipboard (and drag and drop functions) are just wrappers for their Win32 counterparts. The same stuff is possible, but in many cases you have to recreate some structs, enums, and interface definitions for stuff that is already in Win32. For example, the System.Runtime.InteropServices.UCOMISTream interface already exists, but an equivalent for IStorage does not. You'll have to create an interface with the proper GuidAttribute and interface methods (taking into account marshaling parameters).
To do this correctly, you'll have to implement .NET's IDataObject yourself and recreate structures for FORMATETC and STGMEDIUM. .NET's IDataObject is created specifically for .NET, using objects instead of structs and interface pointers. You'll have to override it to make it work more like COM's IDataObject interface.
After that, simply call Clipboard.SetDataObject(object) or Clipboard.SetDataObject(object,bool) in your client code.
My recommendations, make your IDataObject implementation class take an object (perhaps of a specific type) and some other parameter to dictate whether the implementaiton itself should wrap it up in an IStorage or IStream object.
So, I'm sorry there isn't example code like you asked, but this is actually a very big problem to solve and requires that you read-up on COM to understand it. Be sure to look at FORMATETC and STDMEDIUM. Both contains links to other material that should be helpful.
-----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-----
|
|
|
|
|
Hi!
this is not realy what i want... I mae port of structures and interfaces long time ago, but I think I make something wrong... that is why I ask for example of code.
BTW
Heath Stewart wrote:
After that, simply call Clipboard.SetDataObject(object) or Clipboard.SetDataObject(object,bool) in your client code.
such code will not work with Clipboard implementation provided by NET Framework. That is why I need example with OleSetClipboard and OleGetClipboard API methods calls.
Good Luck
Alex Kucherenko
|
|
|
|
|
Actually, such a call will work if you take something into account that I forgot to mention (sorry). If the data object implements System.Windows.Forms.UnsafeNativeMethods.IOleDataObject, it does work. Unfortunatel, it is a nested interface of an internal class, but the System.Windows.Forms.DataObject does. You can use reflection to set the FORMATETC and STGMEDIUM structs. Calling Clipboard.SetDataObject does, in fact, call OleSetClipboard.
You should try downloading .NET Reflector and take a look at how Clipboard.SetDataObject is done. Like I said, everything you need is already there. You may have to use Reflection to do get at it or you could redefine your own structs and interfaces in the same way it does (except that your IOleDataObject won't be the same Type as theirs, but you can at least make your call to OleSetClipboard work the same).
With that, I can understand how your interface methods aren't always correct. This happens often. I had a custom IClassFactory method with the same params. When I tried a trick where you write IDL, compile it with midl.exe to a typelib, then use tlbimp.exe to import that, the method had a mysterious third parameter. Using Reflector (that can disassemble in a much easier-to-follow way than ildasm.exe, and can also decompile), you can see how MS defined their interfaces and match them. Once you get your IOleDataObject interface defined correctly (remember, don't forget the GuidAttribute), you can pass the object directly into a correctly imported call to OleSetClipboard.
-----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 have download a few example on Remoting, but none could run on .NET Framework 1.1. How do I overcome the security settings.
|
|
|
|
|
|
Hi,
I have seen that it's easy to calculate the time a process has been alive, the CPU time spent... But I would like to know the time that the application has been activated or used by the "user" ( I have read that some people uses hooks to the keyboard, would it be possible to retrieve the current focused window and get from there the process id ?).
Greetings
Braulio
|
|
|
|
|
Braulio Díez wrote:
But I would like to know the time that the application has been activated or used by the "user"
Well, "activated" and "used" are two different things, philosophically. For example, I may have several browser windows open that I'm referencing while writing something in Word, which is the only active doc. So, how do you measure which app I'm using? I'm using all of them, active or not!
Still, it would be a cute app to write. I wonder if someone's done it already? (A very brief search on google came up with nothing).
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Hi,
I have seen some software that monitors that usage. I would be happy just having the time that the user has a windows active ( and it's doing something with it), the CPU time consumed is not valid for me because a Math app can consume more, and surf in the internet or write a doc in Ms Word doesn't consume much CPU...
Braulio
|
|
|
|
|
The user can open the app without using it. To calculate the real time of usage, I think you can use Form.KeyPreview and the Mouse-Events.
1) Mouse enters the main form: Capture the time
2) Mouse leaves the main form: Capture the time
3) Calculate the time span
While the user is typing, the mouse cursor can be anywhere on the screen, so you have to define a maximum time span between two keys:
1) Key is pressed: Capture the time
2) Another key is pressed: Capture the time
3) Time span is longer than the timeout: The app has not been used since the first captured time.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
