|
In the project properties, go to the option called "Use of MFC library" and choose static library.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
hi! ampersand don't underline my label when i debug, usemenomic is true
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
