|
toxcct wrote:
you'd like to see how your own code is generate (not in asm), this would be an easy way to do that...
Yeah I know that  ......
And what about the Article!, we are already One month late!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
ThatsAlok wrote:
And what about the Article!, we are already One month late!
yes, i'm sorry, but it seems that we can't synchronize 
are my mails losts ?
as i requested you before you went off, you told me you'd provide an HTML template for me for me to write the article.
can't you still connect to msn ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
toxcct wrote:
i requested you before you went off, you told me you'd provide an HTML template for me for me to write the article.
Check you mail!
toxcct wrote:
can't you still connect to msn ?
nope, still yahoo only!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I do this in windows forms app with multiline textbox
String *s;
s = "helo";
TraceBox->Lines->Add(s);
and it results:
An unhandled exception of type 'System.NotSupportedException' occurred in mscorlib.dll
Additional information: Collection was of a fixed size.
Why?
9ine
|
|
|
|
|
If I were to guess I'd say the Lines in the TraceBox are a fixed-size collection, so you aren't allowed to call Add on it. But I can't say for sure, because I don't know what is the type of TraceBox...
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
TraceBox is just a name of the Text Box:
private: System::Windows::Forms::TextBox *TraceBox;
and its MaxLenght variable set to pretty large size.
It is like EditBox in VC++.
9ine
|
|
|
|
|
9ine wrote:
TraceBox is just a name of the Text Box
Oops! Sorry, I missed it in the title of your post.
I don't think you can add lines in that way. In the help for the Lines property there's a note that says: "By default, the collection of lines is a read-only copy of the lines in the TextBox. To get a writable collection of lines, use code similar to the following: textBox1.Lines = new string[] { "abcd" };"
But adding lines to a copy of the collection isn't the same as adding lines to the textbox, either. Why don't you simply use something like this:
String *s;
s = "\nhelo";
TraceBox->AppendText(s);
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Yes it works, thanks
9ine
|
|
|
|
|
Hi
I have developed an application using the CBannerStatic class. For this I have used example given at : http://www.codeproject.com/staticctrl/bannerstatic2.asp
I What I want is when I create EXE and run it, it should show the scrolling text. And I am statically adding the text at InitDialogue() function.
Now the problem is I want to remove the form border and want to show only the Backcolour and text when I run it.
Is there any way to remove the form border, hide form etc....Any help plz
Regards
Amarelia Maehsh
Gujarat
India
|
|
|
|
|
Try removing the border style in the dialog's template using the dialog editor, and making your control fill all the space in the dialog.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Im using boZoi library to implement Elliptic curve cryptography to my VC project.The functions output r in the format of hexadecimal and OCTETSTR(octant string) now if i want to show the output in the edit box control of a dialog box...its not working.
OCTETSTR str;
HexEncoder hex(str);
CEdit* poEdit = static_cast<cedit*>(GetDlgItem(IDC_EDIT3));
poEdit->SetWindowText(hex);
hex cant b converted to CString or LPCTSTR...it gives type casting errors.
|
|
|
|
|
titi@yahoo.com wrote:
OCTETSTR(octant string)
How many Byte One character take in OCTETSTR?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
What on earth is an OCTETSTR ? It's obviously a different format entirely, and so needs some sort of conversion class.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
HexEncoder doesn't provide a direct conversion to char* or CString. It only offers the possibility to output its content to an std::ostream. You could use an stringstream for that and then extract the string from it.
On the other hand, OCTETSTR is just a typedef for std::vector<unsigned char>, so you could iterate through each element and convert it to hexadecimal notation using sprintf like this:
void OctetStrToHexString(const OCTETSTR& v, CString& sResult)
{
LPTSTR p = sResult.GetBuffer(v.size()*2);
for (OCTETSTR::size_type i = 0; i < v.size(); i++)
p += _stprintf(p, _T("%02X"), (int)v[i]);
*p = _T('\0');
sResult.ReleaseBuffer(v.size()*2);
}
Then your code could be written as follows:
OCTETSTR str;
CString sBuffer;
OctetStrToHexString(str, sBuffer);
poEdit->SetWindowText(sBuffer);
Note I haven't actually compiled nor tested the code shown above, so it may contain errors.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Ive used this code but the compiler gives v as undeclared identifier.whas v??
Thanx for ur help
|
|
|
|
|
Oops! v was meant to be the OCTETSTR parm, sorry. Change the function header to this:
void OctetStrToHexString(OCTETSTR v, CString& sResult)
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I'm trying to rewrite a console application with more efficiency and I am getting nailed by memory assertions. The biggest difference is that I'm deriving my own objects from CObject and my own list from CObList but that's not where I'm having a problem. I wrote my own iterator but something is calling it's destructor and goes down in flames. I have this now:
<br />
Iterator * iterator = new Iterator();<br />
<br />
for (iterator->Clear(); (!(iterator->MaximumValueReached())); (*iterator)++) {<br />
... does work ...<br />
}<br />
The iterator code works fine in the previous version of the code and I didn't touch it since then. Execution happens once through then goes back up to the for, it iterates fine, exits to the above for loop and immediately enters the destructor. The only time I delete this iterator (on purpose) is in the destructor of the class member this code is in and that's much later.
Also, in the iterator I have a pointer to a struct. The struct exists by using 'new' and it crashes when I 'delete' it.
To note: I was having problems by an assertion being thrown because _CrtCheckMemory returns false which I found out means that there is some counter that counts my mallocs and when it hits 1023, it throws the assertion. This problem mentioned at the beginning of this message started occuring before this assertion so I don't have access to that problem but the two might be related. I might start by changing my old malloc/free statements to new/delete.
Any help to this would be much appreciated. I don't know why I'm getting memory issues just by a couple class derivation rewrites, hopefully you can help me.
|
|
|
|
|
Why are you reinventing the wheel like this ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Well,
1. I used to use a 64-bit integer to do this earlier but that would limit me not only by size but by portability.
2. I also wanted to try out overloading operators because I've never done that.
3. Lastly, I need it to do a lot more than a simple single variable does and placing all the extra functionality with the iterator is very convenient for me.
|
|
|
|
|
Some suggestions:
- Set a breakpoint at the Iterator destructor and check the call stack to see why and from where it's being destructed. If the debugger breaks too often because you have many other iterators, which also get destructed, you may qualify the breakpoint with a condition (e.g.: this==[iterator of interest]) so that the debugger will only break when that particular Iterator is being destructed.
- Just a hunch, but check if somewhere in your code (in particular, in the body of that for loop), you aren't unintentionally assigning the iterator to another pointer on which you later call delete. For example, if you write something like if (anotherIterator = iterator) instead of if (anotherIterator == iterator).
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
- I did set a breakpoint and the call stack is going from the line and file of the for loop I mentioned and directly to the destructor.
- That iterator is never touched anywhere else except through a single function called Test which simply reports a sequence of bitwise AND operations with the iterator data and another smaller for loop index variable.
Thanks for your reply. I do have a feeling the problem is with something dumb I did but I keep saying to myself "there is no way this code is wrong".
|
|
|
|
|
Is the for loop exactly like the one you posted? Or did you post a simplified version? If so, post the actual code, and maybe the entire function in which it's enclosed (unless it's very big). Someone may have more luck at spotting a problem.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
That loop is exactly as you see it (minus changing the increment from pre-increment to post-increment), but the entire function is too big to post it all.
|
|
|
|
|
LighthouseJ wrote:
(!(iterator->MaximumValueReached()));
Ahhh! Go back to studying the basics of C++. I've never seen any body allocate an iterator before (makes no since). Also, what guarantees that the iterator is still valid (at the above point).
All I see in your example, is code that is guaranteed to crash.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
This class is more of just an iterator embedded in a class with members in it. That function, MaximumValueReached() does work in my earlier project. About those guarantees, I did some checking and found out when it finishes the iterator, the data in it gets corrupted. I have a pre-increment and post-increment operator and here's the code that did it:
Iterator& Iterator::operator++ () {<br />
... does iteration here ...<br />
return *this;<br />
}<br />
<br />
Iterator Iterator::operator++ (int) {<br />
Iterator temp = *this;<br />
++(*this);<br />
return temp;<br />
}
In my for loop, I was calling the post-increment operator which in turn calls the pre-increment operator. I think VC knows how to shape the machine code to increment before or after. What was happening is that the code would get to '++(*this);' and go into the pre-increment and work fine then exit back to the post-increment operator. Before the 'return temp;' statement, the iterator is fine, but after it ran the return statement, it's corrupted and I don't know how it became corrupted or deleted since it's running it's own destructor.
I did switch the for statement to the pre-increment iterator and it works until I hit the debug assertion
_ASSERTE(_CrtCheckMemory()); which I said in my first post that I was receiving before. I've read on some sites like MSDN that says it "Confirms the integrity of the memory blocks allocated in the debug heap (debug version only).". I also read that every time you malloc, it adds one to a counter and when that counter is 1 less than 1024 it asserts. I read what this assertion does but it (and web sites) offer no solution to fix it that I can find.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
