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.
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.
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.
I do a lot of work in VS2008. It's the editor I have to use for WEC 7 development. I must have 7 different device SDKs installed in my laptop. Recommendation - if you have to do multi-target development, I'd install each in their own VM. Anyway...
So I'm trying to fix some things in a source repository. Made a few changes and tried to save the cpp file. It tells me the fail is locked. okay, Save As... send it to src1.cpp.
Exit VS2008. Nope, there is a phantom dialog window open, I cannot leave. Well, FU VS2008, I kill off the process.
Go to the source folder, try to delete src.cpp. This is what I get:
"The action can't be completed because the file is open in Microsoft C/C++ Compiler Driver"
Now this is completely new to me.
Anyone else seen this error? I know how to ultimately make it go away, but I don't want to reboot just yet.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Then execute handle again with the -c and -p options to close it:
handle -c 98C -p 2328
Using Process Explorer (for the friend of mice)
To close the handle using the ProcessExplorer, search for the file name (Ctrl+F or the Find menu), double click on the found item so that it is selected in the main window, right click on the item in the main window to open the context menu, and choose 'Close Handle'.
The usual disclaimer:
Close only files of processes that are no longer working (has been killed or exited upon critical errors)!
I am creating a CListBox manually as part of a auto-complete editbox (CEdit) to display possible choices.
The complete UI is something like:
Subclassed CMFCPropertyGridProperty to use my own CEdit Class, AutoCompleteEditBox (override CreateInPlaceEdit).
I create my listbox in the AutoCompleteEditBox:
if ( !m_ListBox.GetSafeHwnd() )
UINT extendedStyle = WS_EX_CONTROLPARENT | WS_EX_TOOLWINDOW|WS_EX_WINDOWEDGE|WS_EX_TOPMOST;
UINT style = LBS_NOTIFY|WS_POPUP|WS_BORDER|WS_VISIBLE|WS_VSCROLL;
/// I tried setting the parent to different CWnd (The dialog, the CMFCPropertyGridCtrl...)
CWnd* parent = nullptr;
if ( m_ParentWindow )
parent = m_ParentWindow;
BOOL ret = m_ListBox.CreateEx(extendedStyle, _TEXT("LISTBOX"),NULL,style, CRect( 0,0,0,0), parent, 0 , this);
//// At this point the HWND of the list box is 0xFEEEFEEE.
And this gets called
int SuggestionListBox::OnCreate(LPCREATESTRUCT lpCreateStruct)
if (CListBox::OnCreate(lpCreateStruct) == -1)
//// At this point the HWND of the listbox is valid.
m_pEdit = (AutoCompleteEditBox*)lpCreateStruct->lpCreateParams;
For testing purpose, I created the AutoCompleteEditBox as a child of the top level CDialog and everything works as expected.
Any ideas, suggestions or things I might have missed ?
I finally fixed the creation issue.
The Edit box created was using the id AFX_PROPLIST_ID_INPLACE; I thought it was OK to continue use it, I replaced the id with a different one and now all is working nicely (well, it is not finished, but I can continue updating and upgrading the feature).
I am not familiar with the class 'CAutoCompleteEditBox' etc. I still use MFC42. This version does not have anything that fancy, but the nearest would be a CComboBox, with the Edit option set to True. Make sure that the Resource Template has the property 'USER_DRAWN' if you want to add your own options. You add these on an EN_CHANGE message.
The best way to investigate this is to open the Resource file in a Text Editor, and inspect and edit the values for the control.
In MFC42 you would be required to, as a minimum, implement the '(On)DrawItem()' virtual function, The Standard Implementation of (On)DrawItem() Asserts in MFC42!
I have in the mean time derived my own libraries for things like this.
Writing a Dialog Based MFC Program, where staff logs in with name and password. I want to implement automatic logging out, after a period of inactivity. (Mouse Moves or Clicks, Keyboard Activity)
I can handle the Internals of how to implement the Cascade Down upon Time_out
I need to monitor 'Activity' I reckon that the best place to do this in SDK is in the App Main Wnd Procedure, by kicking a Timer on WM_MOUSE_MOVE, WM_KEY_UP, etc Messages.
How do I handle this in MFC. Can I use an old fashioned WndProc() or is there no other way but using the MessageMap, with handlers for each message.
I have not used MFC for a number of years, but I would guess you can do it in the message map macro, by capturing the messages and writing your own switch handler. You can then reset your timer for each message that is caused by user interaction. Take a look at the source of the macros in the MFC libraries.
Good to hear of you after all this time. Yes, the Macro's is a solution I considered, and I suppose I can write One Handler, to tie to several message ID's, (I know how the Macro's work) with a Macro for each, Just in a standard WndProc() you have only One switch, to filter those out you need to use to kick the timer, before calling the Default in any case. Looks more elegant.
Maybe not feasible in MFC.
Hope you have not given up on MFC. It has a lot to offer compared to those 'Synthetic Languages'.
to filter those out you need to use to kick the timer, before calling the Default
I would do it with a simple flag. Each time you handle one of the messages in question, set the flag to true. Each time the timer code gets called set the flag to false. You can then see whether there has been any activity between timer 'ticks'.
Bram van Kampen wrote:
Good to hear from you again,
Thanks for your kind comments, I've not been away.
Last Visit: 31-Dec-99 19:00 Last Update: 27-Jan-21 1:27