I'm writing what I think should be a simple add-in for Visual Studio 2012 to pin a tab upon opening a file. I have the event being handled with this:
_documentEvents.DocumentOpened += DocumentEvents_DocumentOpened;
But within the method handling the event, the error message "Command "Window.PinTab" is not available." is being thrown. It happens for either line below (calling from ActiveWindow or calling from the document itself).
public void DocumentEvents_DocumentOpened(Document document)
{
//document.DTE.ExecuteCommand("Window.PinTab");
document.ActiveWindow.DTE.ExecuteCommand("Window.PinTab");
}
I see that that command returns false for IsAvailable, but how do I get it to be available? Or how do I call Window.PinTab such that it will be successfully executed?
So it turns out that the pin tab command has to be executed from the Window, not the Document object. Apparently all panes within the main Visual Studio windows are also windows.
This worked:
window.DTE.ExecuteCommand("Window.PinTab");
Related
I am working on an MFC application with a Ribbon Bar and am experiencing difficulty adding event handlers for new controls from the Ribbon Designer. This was working fine the last time I edited the Ribbon roughly 2 months ago. For instance, adding a new button ("Test Function") I change the resource ID to "ID_BUTTON_TESTFUNC" then right click the button and select "Add Event Handler...". The dialog comes up with a Function Name "On18" rather than "OnButtonTestfunc" and adds a message map and function that don't respond to the button.
BEGIN_MESSAGE_MAP(CMFCApplication2View, CView)
// Standard printing commands
ON_COMMAND(ID_FILE_PRINT, &CView::OnFilePrint)
ON_COMMAND(ID_FILE_PRINT_DIRECT, &CView::OnFilePrint)
ON_COMMAND(ID_FILE_PRINT_PREVIEW, &CMFCApplication2View::OnFilePrintPreview)
ON_WM_CONTEXTMENU()
ON_WM_RBUTTONUP()
ON_COMMAND(18, &CMFCApplication2View::On18)
...
void CMFCApplication2View::On18()
{
}
I have tried the following, expecting (hoping) VS would return to normal behavior:
The same process on 2 computers with the same results
Updating Visual Studio to 17.4.4 (from 17.4.3)
Repairing Visual Studio
Creating a new blank MFC application - same results
In Account Options: UNchecking "Syncronize Visual Studio settings across devices and installs..."
Clearing all Visual Studio settings (Tools, Import Export Settings, Reset all settings)
Changed IDE Tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Rescan Solution Interval = 0 per Alen Wesker post on: Can't add event handler in visual studio 2010 (mfc project)
Manually adding the message map entry, function declaration and function definition works and responds to the button press:
MFCApplication2View.h:
afx_msg void OnButtonTestfunc();
MFCApplication2View.cpp:
ON_COMMAND(ID_BUTTON_TESTFUNC, &CMFCApplication2View::OnButtonTestfunc)
...
void CMFCApplication2View::OnButtonTestfunc()
{
//my code here
}
But I am concerned about what else might be corrupted in VS. Any thoughts would be very welcome.
Microsoft indicates that this is an issue and had been previously fixed in version 17.5 Preview 2. See: https://developercommunity.visualstudio.com/t/MFC-Add-Event-Handler-Dialog--not-prope/10211759.
I trigger an c# application by an custom action:
On failing condition, my application tells Install Shield to abort the installation process using an exit code:
static void Main(string[] args)
{
if(false)
{
Environment.ExitCode = 1;
}
}
Using this approach, Install shield´s setup displays an error message like expected:
How can I overwrite that error message by a custom text?
Reading between the lines here, it appears your custom action launches an EXE. If that is so, there is no way to do what you ask. You could show a message from your EXE before returning a non-zero exit code, but then Windows Installer would still show the Error 1722 message.
If you can instead run a function from a DLL, you have more options. Instead of returning errors, you'd be able to set properties (assuming this is an immediate mode action), and could use those properties to do further things, such as show another dialog, or exit the installation without the Error 1722 message. I don't think all the necessary configuration options are available in the limited edition - you certainly cannot edit dialogs in LE - so to do all of that, you would have to change to a more capable tool (including the Professional edition, or options from other vendors).
I've created very simple Visual Studio Add-in, ala this article by JP Booodhoo.
http://codebetter.com/jpboodhoo/2007/09/04/macro-to-aid-bdd-test-naming-style/
The addin works in debug, so if I F5 in the add in solution, and open a solution then the addin shows in the tools. However, it doesn't show when not debugging. i.e. after I've deployed the addin, closed and re-opened my solution.
Am I missing something?
In terms of deployment, I followed the deployment steps in this article and deployed it to C:\Users[your user name]\Documents\Visual Studio 2012\Addins
Alternative to macros in Visual Studio 2012
public void Exec(string commandName, vsCommandExecOption executeOption, ref object varIn, ref object varOut, ref bool handled)
{
handled = false;
if(executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
{
if(commandName == "KinghamExtensions.Connect.KinghamExtensions")
{
var selection = (TextSelection)(_applicationObject.ActiveDocument.Selection);
selection.SelectLine();
if (selection.Text == "") return;
var prefix = "public void ";
var index = selection.Text.IndexOf(prefix);
prefix = selection.Text.Substring(0, index) + prefix;
var description = selection.Text.Replace(prefix, String.Empty);
selection.Text = prefix + description.Replace(" ", "_").Replace("'", "_");
selection.LineDown();
selection.EndOfLine();
handled = true;
}
}
}
As I say, the code works when running the addin from vs in debug, but doesn't show in the tools menu.
Also, it doesn't show up in the keyboard options like the Git Extensions addin does meaning I can't assign a key binding.
Any thoughts?
It is hard to answer by the information you given, but at first you should check the followings:
Your AddIn should appear in the Tools>Add-in Managger...
If you set the first check box before it, than it should be loaded.
If it isn't and you get an error message, click to no, else the Studio will rename the deployed .AddIn file.
You should check if your release assembly is at the place referenced by the Assembly element like this: <Assembly>C:\Users[your user name]\Documents\Visual Studio 2012\Projects\MyAddin1\MyAddin1\bin\MyAddin1.dll</Assembly>
in the .AddIn file deployed by Visual Studio to the AddIn folder you mentioned in your question.
If it is, and the error pesrists, you should add some log to your Add-In (a Windows MessageBox will do)
and place it to the OnConnection method. The error can appear either OnConnection throws an Exception while the IDE trying to load it, or the FullClassName element in the AddIn file refers to an other name than your Connection class has.
If you get no errors and your OnConnection runs properly, then it could be an exception thrown while your code is adding your command, - if you do the same way as it is in a generated Add-In template in a try/catch block- and you need to resolve it.
I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode.
Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps?
I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled.
Seems like a bug. I would roll out my own assert method. Something like:
[Conditional("DEBUG")]
public static void Assert(bool condition)
{
if (!condition)
System.Diagnostics.Debugger.Break();
}
It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.
The DefaultTraceListener.AssertUIEnabled property is false. That's an implementation problem, can't display a message box on top of Metro UI. Which does actually work but the monitor switches to the desktop, pretty undesirable when you would have liked to click No. Hard to solve and no doubt on the todo list. You can't easily get to the property to set it to true, it is inaccessible from the metadata. Filip's workaround sounds half-decent.
There is the same problem with F# in WinRT, in VS2013. The assert statement, which is an alias for System.Diagnostics.Debug.Assert, does not raise an exception, so unless you are watching the Output window then your assertions can fail without being noticed. Even if you are watching, it is hard to find the spot where the assertion was raised.
I followed Filip's suggestion and wrote a short utility, as follows:
namespace MyProj.Infrastructure
module Diagnostics =
let Assert condition = if not condition then
System.Diagnostics.Debugger.Break()
I chose Debugger.Break over raising an exception because it stops the debugger at the place the assertion fails. However, raising an exception is an acceptable alternative.
I didn't have any suitable global projects or modules already in my solution, so I had to create them just for this, which was quite annoying.
I have a test method which requires Internet Explorer to be opened and closed numerous times during the test. I have been creating a process like this:
Process process = Process.Start(...);
And closing it like this:
process.CloseMainWindow();
However, I have found that I can only call this method once, otherwise I get the error message, "Process has exited, so the requested information is not available".
Once I have closed the process, I would then re-launch Internet Explorer. e.g.
process = Process.Start(...);
But this didn't work. I also tried nulling the Process variable before calling the Process.Start() method, but this didn't work.
I also tried using process.Kill(), but this caused problems too.
What is the correct way to do this?
UPDATE: Code
Process Browser;
[TestInitialize]
public void TestSetup()
{
Browser = TestBase.LaunchBrowser();
...
Browser.WaitForInputIdle();
Browser.CloseMainWindow();
Browser = null
Browser = Process.Start("IExplore.exe", ...);
}
[TestMethod]
public void MyTest()
{
// do things
Browser.Kill();
Browser = Process.Start("IExplore", "www.adifferentwebpage");
}
[TestCleanup]
public void TestCleanup
{
Browser.Kill();
}
I suggest to create another process without reusing the same variable.
Encapsulate your code inside a using statement to properly close and dispose the process variable
using(Process process = new Process())
{
// do you stuff
process.Start(.....);
process.CloseMainWindow();
}
Also remember that calling CloseMainWindow doesn't gurantees that the process will close. It only sends a request to close to the main window of the process. If the application ask for user confirmation before quitting it can refuse to quit.
I found a solution, but it only applies to those who have access to the Coded UI test DLL's (which I believe comes with Visual Studio Ultimate and Premium).
Therefore I will change the tags on the question.
If you create a Coded UI test project, these DLL references will already be there, but this using reference is what you need:
using Microsoft.VisualStudio.TestTools.UITesting;
To create a browser window:
BrowserWindow browser = BrowserWindow.Launch(new System.Uri("www.whatever.com"));
To close:
Browser.Close();
This worked no matter how many times I needed to relaunch the browser. This API also includes a multitude of other handy features like the ability to delete cookies, change the URL of the current browser, resize the window etc.