I am curious about why wouldn't this command work?
File.AddExistingItem
Since it's stated in MSDN library and it has its own chapter about it!
https://msdn.microsoft.com/en-us/library/6h4c0t7y.aspx
I am using VS2015
1. Open the IDE's command window by View->Other Window->Command Window
(or simply by shortcut key: CTRL + ALT + A
2. Type File.AddExistingItem Whatever_Valid_CSHARP_Filepath
(As you can see there is no auto-completion for File.AddExistingItem)
3.It comes out "Command "File.AddexistingItem" is not valid."
But the similar command File.AddExistingProject works adding *.csproj
(using File.AddExistingProject works, and no "Command xxx is not valid" coming out)
Does anyone know why it doesn't work?
And How can I fix it? If it's possible.
I added a bug report about this to Microsoft Developer Community (aka User Voice)
https://developercommunity.visualstudio.com/content/problem/536640/fileaddexistingitem-does-not-appear-visual-studio.html
Related
Visual Studio (the full-fat version, not Visual Studio Code) and SQL Server Management Studio both feature editing commands that emulate (replicate? reimplement?) UnderWare Brief and Emacs (but not Vim, hmpf!)
In the IDE's Tools > Options > Keyboard Shortcuts window, the Brief-emulation commands have the prefix Edit.Brief... and the Emacs-emulation commands have the prefix Edit.Emacs...:
I was setting up some custom shortcuts of mine (as I like to bind Ctrl+E to Edit.LineDelete and Ctrl+D to Edit.Duplicate), and I noticed that the IDE has seemingly duplicate functionality from the Brief and Emacs emulation commands, which made me wonder what the difference was.
Unfortunately there's no documentation available online that describes exactly how each Edit.* command differs from each other - I know I could dive through VS' editor's DLLs to try to find out but before losing a weekend down a rabbit-hole I thought to ask first...
So, can someone explain the differences between these similarly-named commands?
Normal
UnderWare Brief
Emacs
Edit.BreakLine
Edit.BriefBreakLine
Edit.EmacsBreakLine
Edit.LineDelete
Edit.BriefLineDelete
Edit.DeleteToEOL
Edit.BriefLineDeleteToEnd
Edit.EmacsDeleteToEOL
Edit.DeleteToBOL
Edit.BriefLineDeleteToStart
Edit.Find
Edit.BriefFind
Edit.Replace
Edit.BriefFindReplace
Edit.EmacsFindReplace
Edit.WordDeleteToEnd
Edit.BriefWordDeleteToEnd
Edit.EmacsWordDeleteToEnd
Edit.WordDeleteToStart
Edit.BriefWordDeleteToStart
Edit.EmacsWordDeleteToStart
Edit.WordPrevious
Edit.BriefWordLeft
Edit.EmacsWordPrevious
Edit.WordNext
Edit.BriefWordRight
Edit.EmacsWordNext
Additionally, what exactly does Edit.WordNextExtend and Edit.WordNextExtendColumn do?
I have now problem at home, when I wish to enter "greater than (>)" by AltGr+. in last version of Visual Studio, it doesn't do anything. I don't know what is this for feature, but I'm not able to solve that problem. In OS out of VS it works normally - like here - >>>. Interesting is that "<" symbol (AltGr+,) works normally. Here (at home) I have fresh installation without any custom settings, in work, I have same installation but installed before some time, without any custom settings too, but in work it works normally.
Thank to Joachim Isaksson
1) Check where is shortcut used
2) Manually search for that command
3) Now its removable
When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to
Press any key to continue . . .
thus requiring to activate the window and hit a key. Sometimes this is not appropriate.
Why this matters:
At the very moment I write json serialisation code, my workflow goes like this:
adapt c# code
run a console app that writes file out.json
view out.json in the browser with a json viewer
do this again and again, no need to debug anything, just trimming serialisation and check output is good.
It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps
activate the console window
press key
.
No answers:
Starting the application outside VS in a separate console is not an answer.
Saying, you dont need this.
I'm pretty sure that you cannot affect or change this behavior.
As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.
Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:
%COMSPEC% /k "C:\Path\To\YourApplication.exe"
or
%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"
With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.
Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.
In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.
If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.
If you do need to display output on the console window, you have a couple of options:
Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
I found a solution that works if you are using python (I could not test anything else).
You need to go to
Tools -> Options -> Python Tools -> Debugging
Uncheck Wait for input when process exits normally.
I hope you can apply this somehow to your problem.
2020 UPDATE : Microsoft has listened.
It also closes the console in "Start Without Debugging" mode ;)
The setting is a little buried, but works :
Well, at least in Visual Studio 2010, typing
Console.ReadKey(true);
Removes the "Press any key to continue....."
According to the VS2019 documentation:
Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.
It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.
In vs2017 you have to uncheck the python environment setting under the vs-options:
in german: Auf Eingabe warten, wenn der Prozess normal beendet wird
Here is an explanation how to define a custom keyboard shortcut for quitting the kernel of the selected notebook by modifying the file KeyEventTranslations.tr. This file is located by default (under Windows) for Mathematica 5.2 in the folder
C:\Program Files\Wolfram Research\Mathematica\5.2\SystemFiles\FrontEnd\TextResources\Windows
and for Mathematica 7.0.1 in the folder
C:\Program Files\Wolfram Research\Mathematica\7.0\SystemFiles\FrontEnd\TextResources\Windows
In this file after EventTranslations[{ I have added a line:
Item[KeyEvent["q", Modifiers -> {Control}],FrontEndExecute[FrontEndToken[SelectedNotebook[],"EvaluatorQuit",Automatic]]]
But unfortunately after restarting Mathematica the shortcut Control+q does not work on both versions.
Moreover, in Mathematica 7.0.1 executing the command
FrontEndExecute[FrontEndToken[SelectedNotebook[], "EvaluatorQuit", Automatic]]
and pressing "Quit" leads to an application error and closing FrontEnd with loosing all unsaved changes (I am using Windows 2000).
What am I doing wrong?
EDIT: The problem was in missing comma after added Item[...] (thanks to belisarius). Here is the right line to add to KeyEventTranslations.tr:
Item[KeyEvent["q", Modifiers -> {Control}],FrontEndExecute[FrontEndToken[SelectedNotebook[],"EvaluatorQuit",Automatic]]],
Now shortcut Control+q works nice both in Mathematica 5.2 and 7.0.1.
But the above bug with "application error" still appears (not when using the shortcut but only when evaluating FrontEndExecute[FrontEndToken[SelectedNotebook[], "EvaluatorQuit", Automatic]] in notebook).
This answer and the associated comments may help you.
HTH!
BTW ... I did the same in v7 and it worked. On what version are you having trouble?
Just a note: Be very careful with the syntax Verify that every Item[Keyevent ends with a comma, except the last one.
I'm a very new Cocoa user and running into all sorts of problems...
I'm trying to get the content of an Array and found this code to do this.
NSLog(#"array : %#",collection);
The problem is, I'm not getting any console or tracer window that shows this 'echo'
Is there another command I should use, i've tried opening all windows but I don't see the message that should show. I know the function that this call is in is executed, so the reference is right.
Thanks and sorry for these beginner questions... Using stackoverflow is way faster than reading through all the documentation apple has regarding the subject.
Update for 2023 : It's Command + Shift + C
Old answer : It's shift + cmd + R. Or go to View -> Debug Area -> Activate Console
From the 'Run' menu, choose 'Console' - keyboard shortcut is Shift-Cmd-R.
When Xcode runs your project, the editor changes to show a little black button with the letters "GDB" in it. Click on that to see the Debugger which has the console in it.
Good luck!
Oh, and I would read Apple's documentation. It's not that bad.
In Xcode 12, go to View > Debug Area > Activate Console
In the Xcode menu hit Run - Console. This is where NSLog / print / printf etc statements output.
The key command is Command + Shift + R.
The cocoa toString() method is called description as well.
NSLog(#"array : %#",collection);
Will execute
NSLog(#"array : %#",[collection description]);
Which will then call description on each of the collections elements.
If you want to see it every time you run your application select the "Debugging" tab from the preferences window and change the box that says "On Start" to "Show Console".
Additionally i like to check the "Auto Clear Debug Console" checkbox which will clear out the text of the output on starting your application.