ExecWB not available in IE9 on VS2010 - vb.net

I have a program in VB.NET that has a webbrowser contorl. I wanted to zoom on a page and i found a tutorial online that involved something like this
webbrowser1.ActiveXInstance.ExecWB(OLECMD...
When i went on and typed it on, there's nothing called ExecWB.
Why is that? Is it because i'm using IE9?
I'm using Visual Studio 2010.
I think the problems with IE9. When i tried the same thing in VB6 (with a different code that is), i get an error "Method ExecWB failed to initialize" or something like that.
So, how can i fix this?

Security setup.
Initialization and script execution of an ActiveX control which are not marked if safe even if it performs a script.
It operated, when it was except invalidity.

Related

Why is debugging ultra slow in Visual Studio 2010 when stepping through Excel interop code?

To nip this in the bud, I have posted this question and workaround. I would like to accept an answer that actually quantitatively describes the problem.
I do some office programming using VS2010 and VB.NET. I have found that using VB.NET over VBA provides a much better user experience for office automation tasks. But, VB.NET IDE sometimes, not all the time, grinds to a halt when debugging Excel COM interop code, such as it takes 5 minutes to set a string equal to the value of cell, or just removing and adding breakpoints takes minutes apiece. This has been the bane of my existence for sometime, as I would have to restart my computer to fix it, but I have finally figured out the causal actions and a workaround. It happens when I have more than one other Excel instance open besides the COM server. I know Excel usually only opens one EXCEL.EXE, but, I have my registry settings so that every excel document opens in a new instance, so that I can look at separate docs on separate monitors. I don't believe this is uncommon. So, when I have left Excels open and my app starts an Excel COM server and breaks into the debugger, this is when the problem occurs, but also only if I click or operate in someway in one of the Excels after starting the COM server. Then it is like the COM server gets confused as a chameleon in a bag of Skittles of which it can't get out until I restart the computer. So, does anyone have enough debugging, COM, and Interop expertise to tell me what is causing this debugging hell? And possibly a way to preempt it?
To workaround this problem without restarting, I have found that I can end all instances of EXCEL.EXE, even the COM server, and close the IDE, then reopen Excel directly without a document and close it. Now, reopen the IDE, run code, start debugging, and stepping latency is non-existent or negligible.

Visual Studio: edit xaml while debugging (without stopping debugging)

I've got the very same problem as this question: Edit Xaml while debugging with a twist.
My debug session usually runs some code while I need to change stuff in the XAML, and if I detach all, as recommended as answer in that question, the debugged program might run on, but the WCF services which are also hosted in the debugger will be stopped immediately.
And without service my programm usually last mere seconds.
So, is there a way to exit xaml files during debugging? I don't care for debug and continue, I'm aware the changes will take effect only after a restart of the app. I just need to type in some stuff so I won't forget and am annoyed that I have to use an external editor instead of VS.
I always use another tool. Like notepad++ or expression blend.
You can configure this by right clicking the file -> open with. Or with expression blend you get the open in expression blend option and its pretty good for xaml anyways.
if you need dynamic build you can take a look at project Roslyn
more info here
"Developers could also use the output of such software to do tasks like refactor, or reorganize, their code more easily, to add C# and Visual Basic functionality to programs written in other languages. It also adds dynamic typing to the statically typed C# and Visual Basic, allowing developers to add objects and new variables to a program on the fly."

Cannot Debug In Visual Studio

I have just a form in my VB.Net project and even when I try debugging that - there is nothing going on besides the form being loaded - I get the error:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
I've tried using this solution from StackOverflow, but this is either oudated or pertains only to C++. I've also tried using this article from the MSDN Forum, however, this also did not seem to help as I wasn't quite sure what the answer was telling me to do.
Has anybody else came across this problem and found a solution? It's very frustrating that I'm receiving this error and I only have a form showing up.
Edit: I found another solution here but I don't quite know what that means ... yet. I was going to look into this but I'd really like to know why this doesn't work when Application Framework is enabled.
Make sure you are running in debug and not release. Build>Configuration Manager>Active Solution Configuration = Debug
Get rid of all compiler warnings/errors and rebuild. Look at your Sub New() and form_load events closely. Dodgy form inheritance can cause this. Dodgy module level vars also. From memory even when you fix the problem you need to rebuild to get the designer back. Might be a my.Settings issue.
Sorry for imprecise advice, I have had this problem before but I cannot remember the details.
A quick workaround is to just uncheck "Enable unmanaged code debugging" and "Enable the Visual Studio hosting process" in the Debug section of the Project Properties.

What can cause Visual Studio 2008 to hang while debugging?

I have a vb.net project which sometimes, when running in the IDE, suddenly hangs. Normally this wouldn't be a problem. Just hit 'pause', look at the currently running threads, and find the deadlock (or whatever else).
But now I'm running into a situation where not only does the program hang, but trying to pause it causes visual studio itself to hang. In order to get control back, I have to kill the program-being-debugged's process, at which point visual studio comes back to life and says it was unable to pause execution. This is frustrating, because killing the process means the program state is lost (of course), so I don't know where the hang is.
So are there any common causes for this behavior? What should I be looking for?
if your program installs global hooks (which communicate with app) - this might be the case. A hook tries to communicate with your app (which is paused by debugger) and gets locked. And debugger is unable to receive its window messages: classic deadlock between hooked debugger (with hook dll) and a hooking app.
Finding a specific fix for a Visual Studio problem can be tricky: http://social.msdn.microsoft.com/Search/en-US/?query=visual%20studio%202008%20hang&ac=3
Additionally, not all hotfixes from Microsoft get released directly to the public. Some are only given out to customers whose systems are exhibiting a specific problem. So you have to contact Microsoft to the get the fix. They do this to limit the potential downside of releasing a hotfix that may break something else. So if all else fails, give them a call.
Here are some other things that I like to do when Visual Studio starts acting up:
Delete old breakpoints and watch variables.
With visual studio not running, delete the intellisense file (.ncb)
Clean the solution and then do a rebuild of all of the code.
Check hotfixes and service packs. I've seen a bug related to .net programming and debugging hangs. (VS hangs for me when debugging C++ 32-bit apps on 64-bit os:es sometimes.)
I just had a very similiar issue (VS fails to break execution), using Debug -> Delete all breakpoints solved the issue.
I'd check the code of the program being debugged, I'm thinking there may be an infinite loop or race condition in the code you're trying to debug. This has been the case for me in the past, especially on a single-core laptop I used to have. Can you give any information about where in the program you think execution is when you try to pause?

Visual Studio 2008 designers screw up on large VB projects

We have 3 developers all using the same version (VS 2008 SP1) and we all use large VB projects (windows forms). From time to time, the IDE will have all sorts of issues such as locking up, crashing, and even not being able to drag a form object around or it will just instantly disappear.
On the largest of our projects (which is actually 5 projects in one solution file), a couple people here can only rebuild the project for testing 2 - 3 times before they have to close the studio and reopen it.
Has anyone else experienced this? Does this happen with large C# projects?
Yes, I experience this all the time! It has gotten better in 2008, if you can believe it.
I usually find that the reason has to do with an exception in my own code. The UI might bring in a custom control that does not behave well in design mode, causing the problem.
Sometimes, I will bring up a second execution of VS2008 and attach the debugger to the first execution of VS. Then, I can debug my own code as it is being run in the designer of the first instance. Often, an exception is thrown and I can fix my code to play better in the designer.
In other circumstances, I have no idea why it happens.
I have heard of people having this issue, however, I have never had an issue at all myself.
I have heard that a number of people trace the issues back to the use of ReSharper as the primary cause.
The most common problem I've had that causes the designer to crash is when I create a form where the only constructors require parameters.
To alleviate that, when I need the form only to be instantiated with parameters, I create a private parameterless constructor that the designer can use but which the form's consumers won't see.
I have personally experienced all sorts of designer wickedness with VS2008 sp1. I uninstalled the service pack to return stability to my dev environment. This is an unfortunate answer, but give it a try.
Only thing I've had close to this is the design view crashing and bringing up an error, formerly causing me to have to recreate the form and copy and paste the code across until I learnt how to fix it.
My problem was occurring because of me using ctrl+f a lot though. If you are using big files, this might be what's happening.