It doesn't matter. I was just giving you that simplified example to show you that the approach works. The key is to do the following:

Browser.IsWebBrowserContextMenuEnabled = False
Browser.ContextMenuStrip = ContextMenuStrip1 ' or whatever your ContextMenuStrip is called

Nothing could be simpler. Have you even tried this?

Using Monitor.Wait() is a great solution but comes with its own set of problems. Most notably, it has no guaranteed accuracy. If you tell it to wait one hour, it will wait AT LEAST one hour. A number of factors can delay the response. It would be much safer to use Monitor.Wait() to suspend the thread, then switch to a more accurate but processor-intensive method for precision. Also, when calculating the delay, since a number of factors (already pointed out by someone else) can cause this delay to be off, if you really want precision, I would calculate it a few times, then perform the reverse calculation for each result. This will allow you to be assured that your delay value is accurate.

If you followed the example I gave, my guess is that you did not follow it exactly. The example, as I gave it worked. Howevever, if you subsequently call WebBrowser.Navigate() to go to a web page, then the web browser's built-in context menu kicks in. My guess is that you didn't try the example as I gave it, or you did, it worked, but then when you tried to incorporate the concept into your application (where Navigate() is called) it stopped working there. That is just my guess though since you haven't really given much information. In any case, I modified the example by adding the line:

Browser.IsWebBrowserContextMenuEnabled = False

... which will disable the default context menu so that it won't override after you have navigated to a page.

... and you don't see how the use of multiple monitors lends to uninterrupted concentration? Let me use an analogy. Every once in a while, when refactoring some code, I will just go ahead and print out all of the relevant code. (I print on the back of used paper, so don't freak.) Then, I find a big open space and layout all of the code and go to work with a handful of highlighters. I do this because it helps me to see everything laid out in front of me. If I had to look at only one sheet at a time, I would quickly get lost trying to juggle the overall concept in my mind. For me (and nearly every programmer I have ever met), having multiple monitors is similar. I could Alt-Tab to flip back and forth between programs. However, each of these "flips" carries a bit of mental overhead. Each time, the brain has to switch from what it was doing in application A to what it needs to be doing in application B. There is a short period where the eyes and brain reorient themselves to the screen. However, when applications A and B are both right there, I can see out of the corner of my eye if something has changed in application B that even needs my attention, saving me from checking just in case. Likewise, my place in application B is at exactly the same point in space as it has always been, so my brain and eye don't need to refind it. In essence, applications A and B become parts of the same task. Really, what you are arguing is that I should have a single gauge on the dashboard of my car, and that I should have a button that toggles between speed, tachometer, fuel, etc. Or really, that I should pull over if I want to check my speed.

John, You're misinterpreting the study. The study only shows that people who multitask using multiple screens are less productive overall. This is not a commentary on the use of multiple screens, it is a commentary on the price of multitasking. Many of us use multiple screens to be more effective at a single task. For example, I frequently run an app on one screen while debugging in another. This saves me from flipping back and forth and helps me keep my mind focused on the task at hand, rather than repeatedly having to remember where I was either in the app, or in the code. They're both right there. My preferred setup has a third small monitor for debug output. Everything in front of me shows me exactly what I need to complete a single task. I know from considerable experience, that I can code and debug about 1.5 to 2 times faster using this setup than I can on a single monitor. This is not what I "think". I worked for years where I had to keep close track of my time, so I know this for a fact. To argue that the use of multiple monitors always resulted in decreased productivity, one should, by extension, argue that the larger the monitor (or higher the resolution), the less productive a person would be. After all, the larger the monitor, the more information you can see at one time. Effectively, you are arguing that the more you have in front of you, the less productive you are. Again, this is not what the study is showing. Granted, if you have email on one monitor, code on another, and a memo you are typing in another monitor, of course you are going to be less effective. This is simply a matter of how one manages ones workflow. Though I have 2-3 monitors most of the time, I have generally have only one task going on at a time. When I am designing software, I am just doing that. When I am coding, I am just doing that. When I want to check my email, I am just doing that. My brain is just not organized enough to multitask and I know it. Even just a coworker stopping by and saying, "I know you're busy, but when you have a minute can I ask you a question" - even that brief interruption of thought can cost me 15-30 minutes of productivity if I am really into something complex.

This has already been figured out. The solution I gave you works. If you want more assistance, you should provide more information other than, "It didn't work." Then, perhaps I, or someone else, can tell you why it didn't work for you. The solution I posted it how it is done though. I have done this in two commercial apps, and recoded a simple project (as I described) to verify I didn't miss any steps in describing it to you. Is it possible you are building a WPF app? As I mentioned earlier, the procedure is different for WPF apps.

Hmm ... I just did it to verify that it works. Do this: - Create a new Windows Forms Application. - Add a tab control to Form1 with a tab named "TabPage1" - Add a ContextMenuStrip control to Form1 named "ContextMenuStrip1" - Add an item to the ContextMenuStrip. (I made an item labeled "Test".) - Add the following code to the form:

Private Sub Form1\_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim Browser As New WebBrowser

    Browser.IsWebBrowserContextMenuEnabled = False
    Browser.ContextMenuStrip = ContextMenuStrip1
    Me.TabPage1.Controls.Add(Browser)
End Sub

- Run the app, and right click on the browser. It works perfectly for me.

modified on Monday, August 30, 2010 8:22 PM

Yes, this is possible in most circumstances. The first problem is in identifying which window you care about. Multiple applications can have text selected at the same time. You can make clever use of FindWindow() and FindWindowEx() to get a handle to the window in question. The second problem is in identifying the GUI element on that window that might have text that you are interested in. This is actually a much more complicated problem since the GUI element could be any sort of object, nested anywhere on the window. You could use GetWindow() to help with this. The third problem is telling what text is selected within that GUI element. The way you do this depends on the GUI element in question. In a few cases, it may not even be possible. I'm not really sure where I would begin to try to crack that nut. There are a ton of useful API calls that you can use at http://msdn.microsoft.com/en-us/library/ff468919%28v=VS.85%29.aspx[^] You might almost be better off thinking about this problem differently. You could, for example, set up some global system hooks to capture the relevant mouse and keyboard events that occur when text is selected. Then, you would have immediate and direct insight into the objects with which you were dealing. Read this article for an idea of where to start with that approach: Global System Hooks in .NET[^] Good luck.

Hi, It's pretty easy. You need to first make a ContextMenuStrip and add it to the form. It looks like you've already done this because you showed event handlers for items. I'm going to call that ContextMenuStrip "myContextMenuStrip". Clever, huh? OK, the WebBrowser object has a ContextMenuStrip property. If you can set it at design time, then do that. Otherwise, you can add it to your dynamically-created WebBrowser object:

Dim Browser as New WebBrowser
Browser.ContextMenuStrip = myContextMenuStrip

This assumes you are making a Windows Forms app. I don't think the WebBrowser control for WPF has this property. There are options though. As for the code to open in a new window or tab, that is a bit more complicated. You would think it would be easy, but it's not really straightforward. Here's why: The WebBrowser control is only a wrapper to a single IE window. Tabs in IE are handled by the application. Each tab contains its own WebBrowser control. (It doesn't actually use the WebBrowser control as such, but this illustrates the point.) So, the WebBrowser control that you put on your form doesn't know anything about tabbed browsing or other windows. If you want that behavior, you need to create it manually. For example, if you want to open a link in a new tab, you need to: 1) Ascertain the URL 2) Create a new tab 3) Create a new WebBrowser instance and put it on that tab 4) Navigate the new WebBrowser to the URL It looks like you understand steps 2-4. If you need help finding the URL of the link, let me know. Opening in a link in a new window involves a similar process: 1) Ascertain the URL 2) Create a new window 3) Create a new WebBrowser instance and put it in that window 4) Navigate the new WebBrowser to the URL Good luck.

Hi, I won't tell you that you shouldn't do this or that your question is all wrong. I'll just try to give you an answer you can use. There are a few nice built-in .NET methods for copying a file. Here are two: IO.File.Copy(sourceFileName,destFileName) My.Computer.FileSystem.CopyFile(sourceFileName,destinationFileName) They both do the same thing, though I prefer the first example. The second example is not available if you are programming in C#, so it helps with portability not to use it. Others have already warned you about the problems with hard-coding these paths and with possible/probable security problems in copying to your system directory Now, with regards to your second question (running 392.exe) without knowing the path, the short answer is, "No", it is not possible. The long answer is, "Yes", it is possible, but it is clunky. There are two strategies that I can think of. The first strategy involves environment variables, and someone else already talked about that. I wouldn't recommend that approach for a bunch of reasons. The second approach involves searching for the file, then running it. The problems with this are: - It is potentially quite slow. It could take a long time to find the file. - It is potentially dangerous. If there was another file named "392.exe" that you didn't want to run, the code might find it and run it anyway. However, the code for finding the file and running it would look something like this:

Private Function FindFile(ByVal fileName As String, ByVal searchDirectory As String) As String
    Dim fullPath As String = ""

    If Not IO.Directory.Exists(searchDirectory) Then Throw New IO.DirectoryNotFoundException

    fullPath = IO.Path.Combine(searchDirectory, fileName)
    If Not IO.File.Exists(fullPath) Then
        fullPath = ""
        Try
            For Each subDirectory As String In IO.Directory.GetDirectories(searchDirectory)
                fullPath = FindFile(fileName, subDirectory)
                If fullPath <> "" Then Exit For
            Next
        Catch uaException As UnauthorizedAccessException
            fullPath = ""
        End Try
    End If

    Return fullPath
End Function

This function will search all subdirectories to which your app has access for the file in question. You would use it like this:

myFile = FindFile("392.exe", "C:\")
If IO.File.Exists(myFile) Then Process.Start(myFile)

This woul