|
OK, not zero, but i figured it out.
Thanks anyways,
Ryan
One of those days.
|
|
|
|
|
We are developing a C# application using .Net AsyncCallback delegates. The application currently executes, as expected,
using these asynchronous methods. Once this application is converted to a COM+ component (i.e. a .NET serviced component)
the program ceases to execute properly and 'hangs' without asynchronously executing the callback delegates.Any help with .Net asynchronous programming under COM+ would be grealty appreciated. Thanks. Rick
Rick
|
|
|
|
|
|
I am handling the double click event on a form (not a control) and I want to know the location of the double click. How? It was easy for a mouse up/down/hover/etc, it was part of the MouseEventArgs. That info is unavailable for the DoubleClick Event. Why? aaaaarrrrrggggg!
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
Try using the static System.Windows.Forms.Form.MousePosition.
Andreas Philipson
|
|
|
|
|
Thanks, I had already tried that and didn't get the results I was looking for...then it dawned on me to call PointToClient before I used it. Works fine, now.
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
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-----
|
|
|
|
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)
