|
What does "ASCII String Format" mean? I have found ASCII String Format and ASCIIZ searching on the web, and both refer to a simple C String. Here is an example that does that:
// Configuration Property: Character Set should not be set to
// Unicode, where _TCHAR = char
// Or, you can undefine _UNICODE and UNICODE
#include <stdio.h>
#include <tchar.h>
#include "stdafx.h"
#include <vector>
int _tmain(int argc, _TCHAR* argv[])
{
long long h1 = 0x5A30353030LL;
long long h2 = 0x100LL;
long long h3 = h1 + h2;
std::vector<_TCHAR> buffer(256);
int result =
_stprintf_s(&buffer[0], buffer.size(), _T("%I64X\n"), h3);
if (result == - 1)
_tprintf_s(_T("_stprintf_s faiiled.\n"));
else
_tprintf_s(_T("%s"), &buffer[0]);
return 0;
}
Also, is "Z0500" and "Z0510" some kind of command based on the above hex values?
|
|
|
|
|
Hi,
Thanks for the reply, here is what I finally wrote since 5A and 30 are kept constant.
unsigned long int z;
char buf[6];
z = 0x303530; // 5A-303530-30
do
{
buf[0] = 0x5A;
buf[1] = (z & 0xff0000) >> 16;
buf[2] = (z & 0xff00) >> 8;
buf[3] = (z & 0xff);
buf[4] = 0x30;
buf[5] = 0x00;
printf("%s\n", buf);
serial.Write(buf);
z = z + 1;
if ((z & 0xff) > 0x3f)
{
z = (z + 0x100) & 0xffff00;
z = z + 0x30;
if ((z & 0xff00) > 0x3f00)
{
z = (z + 0x10000) & 0xff00ff;
z = z + 0x3000;
if ((z & 0xff0000) > 0x3f0000)
{
z = (z + 0x1000000) & 0x00ffff;
z = z + 0x300000;
}
}
}
Sleep(150);
}
while (z <= 0x353130); // 5A-353130-30
It's HEX addaition of 1 and output to RS232 by cserial, thanks anyway.;)
|
|
|
|
|
|
I'm trying to store around 3000 chars in CString object, by using += operator, and concatenating chars to the end of CString.
The problem: When it around 250 chars in length the concatenation stops to work.
My guess was it's some problem with reallocation (when the buffer gets resized), but I tried with custom class with string of fixed length, and concat stoped at the same point. Now I have no clue what could be the problem.
-- modified at 20:28 Saturday 2nd December, 2006
|
|
|
|
|
Milos Djokovic wrote: Now I have no clue what could be the problem.
It has nothing to do with what you've thus far described. A CString object can hold 231 characters.
Show a code snippet of the problematic code.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Here are some parts of code (complete func is quite long):
BOOL ReadTag(const CString& rTagName, CString& rValBuffer) {
...
LPTSTR chCurrent;
LPTSTR chPrev;
...
while(!tagFound) {
chPrev[0] = chCurrent[0];
this->Read(chCurrent, 1);
...
rValBuffer += chCurrent;
...
}
...
}
The function works fine at first, but then it just stops. It passes over "rValBuffer += chCurrent" statement without executing it.
|
|
|
|
|
Check if chCurrent is zero at the point where the failure occurs.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
One thing that raises alarms are the declarations of chCurrent and chPrev. These aren't unitialized, which means they will point to whatever is on the stack. Since you are reading only one character at a time, I'd suggest declaring them as TCHAR and then passing them as pointers to read.
(As it is, a random string will be concatenated to rValBuffer since there is no terminating zero. Unless, of course, you allocate the buffers somewhere not shown.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Sorry guys, my bad. I just realized that func works fine, but debugger didn't show the whole value!? I did an AfxMessageBox(rValBuffer), and saw that everything is properly read.
As of chCurrent and chPrev declarations, I just haven't posted the init code, but thanx for the advice. When I thought about it I realized that it would be much better to declare buffers as fixed.
Thanks again!
|
|
|
|
|
Milos Djokovic wrote:
while(!tagFound) { chPrev[0] = chCurrent[0]; this->Read(chCurrent, 1); // typeof (this) == CFile* ... rValBuffer += chCurrent; // <- here is the problem ... }
this is very Bad!! as reallocation of Memory in CString is taking place at every iteration!.. you have to come out of some better method! since you reading one char at time you can follow this strategy!
list<TCHAR> listCharacter;
list<TCHAR>::Iterator itList;
while(!tagFound) {
chPrev[0] = chCurrent[0];
this->Read(chCurrent, 1); // typeof (this) == CFile*
...
listCharacter. push_back(*chCurrent);
...
}
CString str(" ",listCharacter.size()+1);
int iCount=0;
for(itList = listCharacter.begin(), ;
itList != listCharacter.end();
itList ++)
{
str.SetAt(iCount++)=*itList ;
}
rValBuffer =str;
<div class='ForumSig'>"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 Support CRY- Child Relief and you </div>
|
|
|
|
|
ThatsAlok wrote: this is very Bad!!
Agreed.
ThatsAlok wrote: as reallocation of Memory in CString is taking place at every iteration!..
Not necessarily. Take a look at the AllocBuffer() method.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Take a look at the AllocBuffer() method.
could find it anywhere! is it associated with CString
"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
Support CRY- Child Relief and you
|
|
|
|
|
ThatsAlok wrote: could find it anywhere! is it associated with CString
Did you look in strcore.cpp?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello,
In my application I have a series of std::sort(begin, end, pr) calls, that lasts about 6 seconds in Release build. However, in Debug build it lasts nearly 20 minutes! I tried setting the non-debug CRT for Debug configuration (I use the multi-threaded CRT DLL), but the linker complained on not finding the CrtDbgReportW function.
It would be neat if I weren't to wait 20 minutes each time I want to debug this application. 
|
|
|
|
|
When I try to get the file handle of an ifstream with _fileno, I receive the compile error
'_file' : is not a member of 'ifstream'
How else can I get the handle of an ifstream?
At the moment I need the handle to get the file length by _filelength.
How else can I get the length of an open file? I want to avoid using CFileFind, as the file is open anyway.
|
|
|
|
|
Vancouver wrote: '_file' : is not a member of 'ifstream'
that's true, since _fileno is available for c-like streams only and you are using c++ streams. Give a look to the following code snippet:
streampos size;
ifstream ifs("foo.txt");
ifs.seekg(0, ios::end);
size = ifs.tellg();
ifs.seekg(0, ios::beg);
size -= ifs.tellg();
hope that helps. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
It is like scratching the right ear with the left hand.
The file length is known and recorded somewhere during open. seekg with ios::end uses exactly that information - but how to get it directly?
I found in several sources, that the length info is not directly available; however, when looking around filebuf, I found the direct solution:
1. rdbuf delivers the pointer to filebuf
2. filebuf has the handle as file description
3. _filelength works with that file description.
I tested it.
Btw, I don't understand, why to substract the position of file beginning; is there any case, when that is not zero?
|
|
|
|
|
Vancouver wrote: It is like scratching the right ear with the left hand.
The file length is known and recorded somewhere during open. seekg with ios::end uses exactly that information - but how to get it directly?
I agree, a lit cumbersome, but your way isn't that cleaner..., moreover I don't like such hacking-like actions with class data members (only matter of style).
Vancouver wrote: Btw, I don't understand, why to substract the position of file beginning; is there any case, when that is not zero?
'cause, AFAIK nowhere (documentation) is stated that tellg() will return 0 at the beginning of the file.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi all,
I have seen this article here:
http://www.codeproject.com/cs/miscctrl/NoScrollingTree.asp
and then found WM_VSCROLL is 276, which is good. But I am not able to scroll right, left, up or bottom using both methods. For instance how can I scroll to 10 pixels down?
Any help is really greatly appreciated.
Thanks all,
Light
|
|
|
|
|
Light2k6 wrote: http://www.codeproject.com/cs/miscctrl/NoScrollingTree.asp
Ask this question this articles discussion board. That author might help you.
|
|
|
|
|
I get an compiler error when I tried to compile the Cylinder Progress Control Demo files.
in "stdafx.h" this is listed but no files are available:
#include "gdiplus.h"
#pragma comment(lib, "gdiplus.lib")
// GDI+ namespace
using namespace Gdiplus;
Can anyone help! I'm using VS 6.0.
A C++ programming language novice, but striving to learn
|
|
|
|
|
|
As has been said, GDI+ came out after VC6, and so, is not included. There's a wrinkle. The PSDK has not supported VC6 for quite some time. You need to find an old copy of the PSDK to have any guarentee of it working. You'd do better to upgrade to a better compiler.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks for the info
A C++ programming language novice, but striving to learn
|
|
|
|
|
The February 2003 PSDK[^] is the last one that supports VC6. It does contain the GDI+ headers.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
