|
Since vector s have random access iterators[^] something like this will do the trick:
m_vTlr.erase(m_vTlr.begin()+6)
Note this code assumes the vector contains at least 7 elements: you'll get undefined behaviour if it doesn't!
Steve
|
|
|
|
|
As for searching I'd:
1. Add an operator== for CMyTrailer :
class CMyTrailer
{
public:
CString m_csItem;
CString m_csMFG;
CString m_csID;
CMyTrailer();
~CMyTrailer();
};
inline bool operator==(const CMyTrailer &lhs, const CMyTrailer &rhs)
{
return lhs.m_csID==rhs.m_csID;
}
2. Now search as follows:
vector<CMyTrailer>::iterator i = std::find(m_vTlr.begin(), m_vTlr.end(), CString("FindMe"));
if (i!=m_vTlr.end())
{
}
The above code assumes you've included algorithm .
Steve
modified on Monday, December 03, 2007 10:06:57 PM
|
|
|
|
|
What about erase? When I find the element in the vector I want to erase it from the vector WITHOUT leaving a blank spot in the vector.
Thanks for using my code names; it sure makes it easier to understand what someone is telling me nwhen they use my code names to explain things. Thanks.
I get this error message when I included the inline function - I included it inside the class declaration - Right?
error: error C2804: binary 'operator ==' has too many parameters
#include <algorithm>
class CMyTrailer {
public:
// Varables
CString m_csItem;
CString m_csMFG;
CString m_csID;
CMyTrailer();
~CMyTrailer();
inline bool operator==(const CMyTrailer &lhs, const CMyTrailer &rhs)
{
return lhs.m_csID==rhs.m_csID;
}
};
#endif
<div class="ForumSig">A C++ programming language novice, but striving to learn</div>
<div class="ForumMod">modified on Tuesday, December 04, 2007 12:54:42 PM</div>
|
|
|
|
|
Larry Mills Sr wrote: What about erase?
if (i != m_vTlr.end())
{
m_vTlr.erase(i, i);
} Larry Mills Sr wrote: When I find the element in the vector I want to erase it from the vector WITHOUT leaving a blank spot in the vector.
Have you considered a list ?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
No I haven't. I was told a vector would be the right choice for my database. I know even less about a "list". I just know I don't want to use any of MFC's containers!
A C++ programming language novice, but striving to learn
|
|
|
|
|
You can use the CList in Simon Huges and my own article, just to see how it works (key word to search: Smart list)
But you can anyways use a list in C++ without MFC , the principies should be similar. I dont now remember if it is in the STL, stl::list
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
I'll stick with the vector for now. I still need a answer as to how to envolk the "erase" function to elimate the element I've found; and I need to resolve why the inline function supplied gives a compiler error.
<div class="ForumSig">A C++ programming language novice, but striving to learn</div>
|
|
|
|
|
I need an example with a dialog box containing a STATIC text that can be changed before showing the dialog box. Maybe the title to be also changed.
Please...
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
This changes the dialog title caption from within the dialog class:
CString windowCaption;<br />
windowCaption.Format("%s", SomeString);<br />
this->SetWindowText(windowCaption);
|
|
|
|
|
Thanks!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Override the CDialog::OnInitDialog .
BOOL CMyDlg::OnInitDialog() <br />
{<br />
GetDlgItem(IDC_STATIC)->SetWindowText(_T("New Text"));<br />
<br />
return TRUE;<br />
}
See here[^] for more information in SetWindowText .
Regards,
Paresh.
|
|
|
|
|
Thanks! a lot
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
I need an example with a dialog box containing a STATIC text that can be changed before showing the dialog box. Maybe the title to be also changed.
Please...
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
MFC or straight Win32?
Do you have a basic understanding of how Windows UI works
or do you just need code?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
MFC
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
For change a text you can use of <code>SetWindowText</code> but I dont understand before showing the dialog box.
|
|
|
|
|
I'll try to use the other answers that I received.
Thanks!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Very good. 
|
|
|
|
|
The Title of the DialogBox and the Static as well can be written with SetWindowText, but the thing is that in the Static, it will be better if you use a member variable to have access to it.
In case you have problems with the static. You can always use a CEdit, disabling the rand (the square around text), making it flat and activating the write-protection. The aspect will be the same as the Static and you will have it easier.
A third possibility, is just not using the Static and just use pDC->TextOut (...). To avoid the blank square behind the letters you can use pDC->SetBkMode (TRANSPARENT);
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
The question is into the title
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
No. A programmer with sufficient skill, time and effort can always disassemble your application and understand it. I've done it myself with a vendor's library for controlling their hardware, which had a race condition in - by decompiling their (native code) library I was able to understand the base API that had been used to control the hardware and bypass the buggy library.
The main thing that's difficult is keeping track of what information is stored where - particularly a problem with a large number of processor registers, where a given variable might at any time be stored in one or more registers and stack locations - and in reconstructing the control structure of the program. Native assembly languages rarely directly implement loops, switch statements or even if/else statements, instead only having controlled jumps. Sometimes you might get an explicit comparison statement but often the jump is controlled only through the flags set by some other operation, so you need to know exactly how the flags are manipulated by all the instructions.
The code I was working with was coded for Pocket PC using the ARM instruction set, which is a little easier due to conditional execution - some small if/else statements are implemented directly by conditioning the instructions - and that setting the condition flags is not automatic, you have to ask for it to be done, making conditional operations not using the CMP instruction easier to spot. x86 is a fair bit harder.
You may find Wikipedia's article on decompilers[^] interesting.
DoEvents : Generating unexpected recursion since 1991
|
|
|
|
|
I'll try to study more and clarify my mind
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
The question is in the title
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
RomTibi wrote: The question is in the title
Maybe so, but even if it were in the body, it still makes no sense. What exactly are you asking?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Maybe I can't understand myself
Thanks anyway
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|