|
Is there a C / C++ / MFC question in here somewhere?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Can't assign an access key to a label ... because a label can't get focus.
|
|
|
|
|
It's a Windows Form (.NET) thing.
|
|
|
|
|
Fine ... It still looks like that's what he's trying to do.
Ampersand; underline; label; ...
|
|
|
|
|
|
He also used that reference (?)
|
|
|
|
|
That has nothing to do with C/C++. Please post in the correct forum and show the code that is not working.
|
|
|
|
|
|
|
Isawyouoo wrote: doesn't work
I just tried it and it works fine.
|
|
|
|
|
|
I suggest you open a new question in the correct forum[^], and show the code that you have, and explain clearly what is going wrong.
|
|
|
|
|
Well,
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.
Hope this is helpful
Regards,
Bram
Bram van Kampen
modified 11-Feb-16 20:16pm.
|
|
|
|
|
by pressing the alt key, or using a timer with sendkeys.send("%"),
or turning on 'the Hide keyboard navigation indicators until I use the Alt key on control panel'
fixed this poblem
|
|
|
|
|
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?
|
|
|
|
|
As far as I know there is no command line debugger in Visual Studio.
All you can do is launching the (windowed) debugger from the command line, see /DebugExe (devenv.exe)[^].
|
|
|
|
|
that just launches MS VS IDE and that's it. I am curious if there at least some way to "debug" in a proper way using command line tools?
(not just cout << statements..)
|
|
|
|
|
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).
|
|
|
|
|
|
Having used a command line debugger years ago I can say for a fact that I have no desire to go back to that.
But then I haven't actually used a debugger for about 3 years. I just add some prints and let it run.
|
|
|
|
|
Prints are a pain... debugger is way better when you can use it. No need to recompile just to figure out different sets of info.
|
|
|
|
|
I have used debuggers - many of them.
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.
|
|
|
|
|
Nobody NEEDS a debugger, just like nobody NEEDS an IDE, it's just another tool to make your job easier.
As to time critical aspects, well... you just have to know how to use a debugger effectively (conditional breakpoints, watchlists) and certainly in conjunction with any other methods in your toolbox. I work with real-time systems every day, I'm a communications/DSP engineer.
|
|
|
|
|
Albert Holguin wrote: it's just another tool to make your job easier
And...AGAIN...I have used debuggers.
Used them for C#, C++ and Java. For years. And they do NOT make what I do significantly easier.
And in the difficult cases the do NOT help.
Albert Holguin wrote: you just have to know how to use a debugger effectively
To be clear with 40+ years (and approaching) 50 and having used IDEs and debuggers for DECADES I can state that I do in fact know how to do exactly how to use them and do in fact know what features you are talking about and have in fact used them....
So if we can in fact move beyond the implicit denigration I can speak that for what I DO (not you and not others) between being able to actually figure out bugs by doing nothing at all (by just knowing how the flows work and what the code does where the problem lies), by looking at the code and by understanding how the flow works MOST problems that I encountered can be determined without a debugger.
And the problems that are most complex involve interactions which a debugger would NOT help UNLESS I already knew what the bug was.
Albert Holguin wrote: I work with real-time systems every day,
And I do not. So YOUR mileage may vary.
Finally of course, as I originally pointed out, I have also used a command line debugger which is per the OP. And those are NOT easy to use. Certainly when I used them they didn't support complex debugging support and I suspect setting them up to do that would be extremely difficult.
|
|
|
|
|
Take a step back... deep breath.... now realize that what people post on internet posts is of little relevance to your every day life. With that said, let's agree to disagree.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
