I have created this datastructure:
class Event
{
public:
Event(EVENT_TYPE type, void* pSender = 0, int content1 = 0,
int content2 = 0, int content3 = 0, int content4 = 0);
~Event(void);
// ... some functions
protected:
EVENT_TYPE itsType;
void* itsPointerToSender;
int itsContent_1;
int itsContent_2;
int itsContent_3;
int itsContent_4;
int numStacked;
};
whose constructor is simply
Event::Event(EVENT_TYPE type, void* pSender, int content1, int content2, int content3, int content4)
: itsType(type),
itsPointerToSender(pSender),
itsContent_1(content1),
itsContent_2(content2),
itsContent_3(content3),
itsContent_4(content4),
numStacked(0)
{
}
For some strange reason I can't understand, the VS debugger cannot and will not show me whatever is contained in itsContent_4. If I put a watch on the variable, itsContent_4 gives me a symbol "itsContent_4" not found while doing the same thing with itsContent_3 works perfectly. I'm not sure the variable even exists as far as the compiler is concerned!
Am I missing something here?
Edit: Now it seems (even stranger) that changing the order of the variables in the declaration creates an even bigger mess! I tried placing itsContent_4 before itsContent_1 and now itsContent_1 is being initialized with the value intended for itsContent_4! What is going on here? I'm suspecting something to do with naming, so I'll try renaming them all and see what happens.
Edit 2: Yes, apparently changing the variable names to itsContent_a instead of itsContent_1 and so forth works perfectly. Is there some restriction as to using numbers in a variable name?
Sounds to me like the debugger is using the wrong .pdb file. Tools + Options, Debugging, General, ensure that "Require source files to exactly match the original version" is checked.
While debugging with a breakpoint active, use Debug + Windows + Modules and right-click your executable in the list. Click "Symbol Load Information" to find out where the debugger found the .pdb file.
Another possible mishap is that this class is defined in a separately compiled executable, like a DLL, which was compiled with incompatible settings. So that the layout of the object no longer matches. That's not that likely in this case.
Check that you're not trying to debug a release build. In a release build the optimiser can remove unused variabled and change the order in which statements are executed. This can be confusing when debugging.
Related
I want to delete all the object that is not used now.
I used Visual Studio 2019.
When I search Object Browser, It gets to me some strange struct or class that I modified of name.
For example, first I define a structure as
typedef struct stOutput
{
double dDirtyPrice_CumInt;
double dDM;
//...
double dYield;
} stOutput
Later I changed this definition to
typedef struct stOutput_New
{
double dAI;
//...
long lObservStartDate;
} stOutput_New
However, the object browser shows to me just
stOutput.
There is no stOutput_New.
Also I put my cursor on 'stOutput_New' and push 'F12' then it locates my view some strange area.
There are even no 'stOutput_New'
Now, below picture is describing my real situation
This is 'Class View'
Actually I just use One stOutput, but there are so many stOutput that has same file path
Also below picture is my 'Object Browser'
As you can see the two stOutput have different member variables.
And I changed the name from stOutput to stOutput_new the latter.
But it seems my object browser didn't reflect it.
I tried
Project Unload and Reload it
Organize the code of Solution and Project
Re-Build Solution.
But everything doesn't work.
Please help me
In vs2019, I defined the structure exactly like yours according to your description, and then changed the structure according to your description. My object browser did not have the problem you described. If you are sure that your code does not repeat the definition of structure and other problems, I suggest you reinstall or repair VS.
enter image description here
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
I want to define a custom set of rules to be checked at compile time. But it seems not to work.
Example:
I choose one rule directly and I'll get the expected warning.
But when I instead create a custom ruleset containing the exact same rule then I won't get the expected warning.
What could be wrong?
Edit:
void f(std::string& i) {
std::string s = i;
cout << s;
}
int main()
{
std::string s ("abc");
f(s);
}
This gives me the expected warning Warnung C26460 The reference argument 'i' for function 'f' can be marked as const (con.3). in the first case.
Even if I create a custom ruleset including all available rules, I won't get any warnings.
Here you see me selecting the custom ruleset:
Edit: The ruleset action must change one time to enable it.
When I create a new ruleset containing only the const-checks then I will get a .ruleset that does not work and look like this:
In the ruleset editor it looks like this:
When I then change its action from Warning to Error:
Then the .ruleset gets additional lines for each test case:
When I change the action back to warning it looks like this:
Now it is working as expected.
I've been able to reproduce your error with Visual Studio 2017. I don't know exactly what I changed (or if I changed anything at all), but I am able to see the code analysis warning you expect with a custom rule set.
Things I would try:
Double check the Error List window is visible and not hiding somewhere.
Open the rule set file, change the Action to Error and then back to Warning and save it. I wouldn't expect this to be the problem but it's one of the things I did and after which I started seeing the Error List window.
Actually here i am tring to invoke some user defined function from 1 function. But i couldnt step-in in to that function, i dont know what could be the reason.
below is the code snippet for calling function
if (!m_pCSock->ConnectTo(aszTWinServerName, m_szServicePort, false))
and below is the defination for the above call
int CSocketClient::ConnectTo(const char *szSuppliedHostname, const char *Suppliedport, bool ShowErrors)
{
if (m_Connected)
{
return m_Connected;
}
char szHostname[128] = "";
char port[128] = "";
The above 2 instances are in different projects and different files.
I tried a lot, I coudn't invoke into this function.
While debugging, when I try to invoke the below line
if (!m_pCSock->ConnectTo(aszTWinServerName, m_szServicePort, false))
it is not moving inside this, it is just moving to next statement.
I am suspecting here it might be some setting issue, I am actually to Windows.
Please help me. Thanks in advance.
maybe the file that contains the function is not built in "debug" mode.
If you perform a "clean and build" operation over the library or proyect, forces the file to be compiled with debug symbols and then debugger can visit that code.
I'm debugging an application (C++), and I've found a point in the code where I want to change a value (via the debugger). So right now, I've got a breakpoint set, whereupon I do:
Debugger reaches breakpoint
I modify the variable I want to change
I hit F5 to continue running
lather, rinse, repeat
It's hitting this breakpoint a lot, so I would like to automate this. I would like to set the Breakpoint to run a macro, and continue execution.
However, I have no experience writing VisualStudio macros, so I don't know the commands for modifying a variable of the executing program. I've looked around, but haven't found anything helpful online so far.
I found how to do this with a macro. Initially, I tried using Ctrl-Shift-R to record a macro of keystrokes, but it stopped recording when I did Ctrl-Alt-Q. But I was able to edit the macro to get it to work. So here's what I did, in case anyone else wants to do something similar.
Tools -> Macros -> Macro Explorer
Right Click -> New macro
Public Module RecordingModule
Sub setvalue()
DTE.Debugger.ExecuteStatement("variable_name=0")
End Sub
End Module
This macro will execute the assignment statement, setting my variable (in this case, making it a NULL pointer).
Right Click on a BreakPoint -> When Hit...
Check "Run a macro"
Select Macros.MyMacros.RecordingModule.setvalue
Check "Continue execution"
Click OK
Then, I was able to run my program, automatically adjusting a pointer to NULL as it went. This was very useful for testing, and did not require recompiling.
Looking for similar today and found that you can also use the 'Print a message:' option instead of a macro. Values from code can be printed by placing them inside {}. The key is that VS will also evaluate the content as an expression - so {variable_name=0} should achieve the same as the macro example.
If you are think of a macro in the same way as Microsoft excel, then you're out of luck. It doesn't quite work that way.
In C++, a macro refers to a small inline function created with #define. It is a preprocessor, so a macro is like using a replace on all its references with its body.
For example:
#define add(a,b) ((a)+(b))
int main() {
int a=3, b=4, c=5, d=6, e, f;
d = add(a,b);
e = add(c,d);
}
Would like to the c++ compiler as:
int main() {
int a=3, b=4, c=5, ...;
d = ((a)+(b));
e = ((c)+(d));
}
Now, back to your question. If the variable is within scope at this breakpoint, just set it from within your code:
myVar = myValue;
If it is not, but it is guaranteed to exist, you may need a little hack. Say that this variable is an int, make a global int pointer. If this variable is static, make sure to set it to its address, and back to NULL inside it's scope. If it is dynamic, you may need some extra work. Here is an example:
int* globalIntPointer;
void func() {
*globalIntPointer = 3;
//...
}
int main() {
int a = 5;
globalIntPointer = &a;
func();
//...
globalIntPointer = NULL; // for safety sake
return 0;
}
You can execute a VS macro when a breakpoint is hit (open the breakpoints window, right click on the breakpoint in question, and select "When Hit..." off the popup menu). I'm less certain about writing a macro that modifies a variable of the program under debug though -- I've never done that, and a quick try with attempting to record a macro to do it doesn't seem to work (all it records is activating the right window, not changing the value).
Select "Condition..." and write an assignment for the variable in question in the "Condition:" textbox. This will naturally resolve to "true" with it not being an actual conditional test. Therefore, the breakpoint is never hit, and your variable has been set accordingly.