I think you are talking about a Resource Script of some type. Dealing with a Button or Menu.
I must admit, my knowledge of C# is Zero. However, this happens in MFC if you try to use the same Underscore twice.
( As in &Underline in One Menu, and &Undo in another menu) The Framework does not bother to disambiguate, to make you choose between 'Underline' and 'Undo'. The idea of Shortcut Keys is 'Shortcuts', not a philosophical set of Dialogs about what you Really meant when you typed CTRL + U. If there is ambiguity, the system does unexpected things, such as not underlining YOUR &U if the system has already a Ctrl + U in its Scope. Don't know the rules, but I guess, that is where your problem lays.
In effect, there are only 26 Ctrl+... shortcuts available, a bakers dozen of which (such as Ctrl + X for 'Edit.Cut') have been used by Microsoft.
I take it you understand the gist of where I'm getting to.
I am experimenting with Microsoft Visual c++ 2015, for quick tests of console only program I just edit .cpp files with an editor then I call the "developer Command Prompt for VS2015" and compile source using:
cl /EHsc mysource.cpp
then run executable.
My question is, how can I manually now set breakpoints in mysource.cpp file and step through them in a same command line environment?
I agree there must be a way, but any particular reason as to why you don't want to just use the IDE? VisualStudio is actually a pretty darn good product, so why not use it?
If you prefer command line tools, why not use gcc tools on Linux instead? ...I'm on Linux as I type this btw, I just really like what MS has done with VS overall (some of the incremental releases were a bit ridiculous but it's still a good product).
And typically I do not need that to figure out problems. And in critical situations they are not available as in postmortems on production problems.
The C# IDE is in fact the best one that I have used. Best in the context of least difficult to get up and running.
But even then I still run into cases where debugger can't be used because I am always working in threaded situations and at least sometimes dealing with time critical operations. And a break point significantly changes behavior in such situations often making it impossible to diagnose the problem. Prints (or more specifically logging) allows for that.
Should note that I do not and have not for a very long time work with UI code. So mileage on that could be significantly different.
Last Visit: 15-Aug-20 8:23 Last Update: 15-Aug-20 8:23