|
peterchen wrote:
I would call trunc()
Don't you mean modf()?
If I have seen further it is by standing on the shoulders of Giants. - Isaac Newton 1676
|
|
|
|
|
|
double result = floor((x+0.005)*100.0)/100.0; This should do the job, including rounding. If you don't need rounding, remove the +0.005 bit.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
double result = floor((x+0.005)*100.0)/100.0;
This won't work if x is negative. Usually when I am need to such a thing, I need to do it more than once so I just call one of my own functions to do this : eg
double RoundDecPlace( double dNumberIn, int nDecPlace )<br />
{<br />
double dMultiplier = 10 ^ nDecPlace;<br />
double dDiff = 0.5 / dMultiplier;<br />
double dSign = ( dNumberIn >= 0.0 ) ? +1.0 : -1.0;<br />
<br />
return dSign * floor( ( dSign * dNumberIn + dDiff ) * dMultiplier ) / dMultiplier;<br />
}<br />
|
|
|
|
|
Anonymous wrote:
This won't work if x is negative.
Good point. Your solution won't work as written because 10 ^ nDecPlace is actually 10 XOR nDecPlace, not 10-to-the-power-of-nDecPlace. You'd have to use pow(10, nDecPlace). Other than that, your solution is good 
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
Your solution won't work as written because 10 ^ nDecPlace is actually 10 XOR nDecPlace, not 10-to-the-power-of-nDecPlace. You'd have to use pow(10, nDecPlace).
Yes, you are correct. I had a brain dump when I entered the text. Thanks.
|
|
|
|
|
Why not just write a simple, generic rounding routine that will round to any decimal place (to the right OR left of the decimal point). EX:
double Round(double dVal, short iPlaces)
{
double dRetval;
double dMod = 0.0000001;
if (dVal < 0)
dMod = -0.0000001;
dRetval = dVal;
dRetval += (5/pow(10,iPlaces+1));
dRetval *= pow(10,iPlaces);
dRetval = floor(dRetval+dMod);
dRetval /= pow(10,iPlaces);
return (dRetval);
}
onwards and upwards...
|
|
|
|
|
If the text file have UNIX format (i.e. \n instead of \r\n) then CStdioFile::GetPosition() always returns maximum value for 64 bit int, i.e. 2**64 AFTER a call to CStdioFile::ReadString().
If there was not any previous call to ReadString then all works fine.
In the original docs the no any clear information about this.
What you think about this?
<br />
CStdioFile file("C:\\file.ext", CFile::modeRead);<br />
file.ReadString(szBuf, 255);<br />
ULONGLONG dwPos = file.GetPosition();<br />
TRACE("dwPos=%I64u\n", dwPos);
file.Close();<br />
|
|
|
|
|
CFile::GetPosition() returns a DWORD, not a ULONGLONG. Plus, the MFC source code asserts if it returns (DWORD)-1, so if you're not asserting, then that is probably not being returned.
The error is probably in using a 64-bit variable to hold a 32-bit result. Try changing the ULONGLONG to a DWORD and printing using a %u instead of %I64 and see what happens.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
From the MSDN:
MFC Library Reference CFile::GetPositionSee AlsoCFile Overview | Class Members | Hierarchy ChartObtains the current value of the file pointer, which can be used in subsequent calls to Seek.virtual ULONGLONG GetPosition( ) const;Return ValueThe file pointer as a 32-bit doubleword.Example
I tried with DWORD and %u before my first post. And I tried again right now:
<br />
char szBuf[255];<br />
CStdioFile file("unix.file", CFile::modeRead);<br />
file.ReadString(szBuf, 255);<br />
DWORD dwPos = (DWORD)file.GetPosition();<br />
TRACE("dwPos=%u\n", dwPos);
file.SeekToBegin();<br />
file.Close();<br />
As I shown before the problems come only if CStdioFile object is reading a text file with UNIX's new lines (i.e. no \r).
But such file is read actualy correct. In while(file.ReadString(szBuf, 255) loop it reads line by line not all the file context as one line.
If there is the assertion you are talking about but why it asserts only with unix text files?
Seems like a usual Micro$oft's dirty trick.
Just try to compile this little code and you'll see what I'm talkig about.
My box is Win2000 Server with VS 7.0.
|
|
|
|
|
I only have VS6, so GetPosition() only returns a DWORD. I have come across a similar situation when I was using a ULONGLONG. Obviously the situation is different on VS7.
Have a look at the source. It might help explain the situation.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
check the handle "file".. NULL?
|
|
|
|
|
wheregone wrote:
check the handle "file".. NULL?
No, if file is null I cannot call ReadString().
As I have told already ReadString works fine and gets line by line in while() loop.
|
|
|
|
|
I have tried.. it does not work too..
SO I think you'd better change the file format to DOS format at first.
|
|
|
|
|
I did it first time I have beed sure about the bug is exactly a bug.
So... I'm sure this is just a dirty Microsoft's trick.
|
|
|
|
|
for data file "00000000h: 31 31 31 31 31 31 3D 0A ..."
my function returns "111111="
for the second time, it returns "", I think I should increase g_fPosition.
But the GetPosition is OK anyway.
/////////////////////////////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////////////////////////////
char gchOneLineNews[1024];
FILETIME g_ftWrite = { 0, 0 };
ULONGLONG g_fPosition = 0;
char * GetOneLineNews(char * pFile);
/////////////////////////////////////////////////////////////////////////////////////////////
// Get One Line News from the File, (read next line, check the write time)
/////////////////////////////////////////////////////////////////////////////////////////////
char * GetOneLineNews(char * pFile)
{
#if 1
FILETIME ftWrite;
UINT rt = 0;
CStdioFile file;
CFileException ex;
if (file.Open(pFile, CFile::modeRead, &ex))
{
if (GetFileTime(file, NULL, NULL, &ftWrite))
{
if(0 != CompareFileTime( &ftWrite, &g_ftWrite )) // not same
{
g_fPosition = 0;
g_ftWrite.dwLowDateTime = ftWrite.dwLowDateTime;
g_ftWrite.dwHighDateTime = ftWrite.dwHighDateTime;
}
file.Seek( g_fPosition, CFile::begin );
if ( NULL == file.ReadString( gchOneLineNews, 1023 ))
{
g_fPosition = 0;
file.Seek( g_fPosition, CFile::begin );
file.ReadString( gchOneLineNews, 1023 );
}
g_fPosition = file.GetPosition();
}
else
{
rt = -2;
}
file.Close();
}
else
{
rt = -1;
}
|
|
|
|
|
Hi, all.
I wrote a code to execute file with shellexecute function.
Since I wanna find the executable program of specific file, I use FindExecutable function.
However, I wanna make sure that the result of FindExecutable fuction is really executable program name.
I found PathIsExe function in MSDN Library, but it can't be run in Win 95 or Win 98 according to MSDN Library.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp
I can't remember the function name that does the same work as PathIsExe.
Could you please help me to find API or other function that does determine whether a file is an executable by examining the file extension?
Thanx in advance. 
|
|
|
|
|
"FindExecutable retrieves the name of and handle to the executable (.exe) file associated with the specified file name." (MSDN). Calling PathIsExe after FindExecutable seems redundant to me. Maybe I am not understanding your question properly.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
First of all, Thanks for reply.
Actually, I wrote a code just with FindExecutable and Shellexecute.
However, FindExecutable sometimes doesn't return properly executable program name and path.
So I want to check whether the result that FindExecutable returns is properly executable program name (i.e. by examining the extension)
And I found "PathIsExe" function, but it only supports Win2000 ir higher.
As a result, I'm looking for API or some kinds of function that does the same work as PathIsExe.
Sorry for ambiguous question.
|
|
|
|
|
You are welcome. Sorry but I can't really help you because I have never used PathIsExe.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
There's little magic behind PathIsExe, the docs say that it
returns TRUE if the file extension is .cmd, .bat, .pif, .scf, .exe, .com, or .scr. Returns FALSE otherwise.
So, you shouldn't have any problem with writing your home-made version of PathIsExe.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi,
I used RasDial function for dial up connection.
It’s works fine in win2000, winXP and some of the win98.
My problem is, some of the win98 machine it doesn’t work.
Could you tall me, why didn't work in win98.
Here is my code:
DWORD dwRet = RasDial(NULL, NULL, &rdParams, 0L, RasDialFunc, &g_hRasConn );
|
|
|
|
|
Which value has dwRet upon error?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thank you for reply.
error is: "Cannot find the phone book entry."
this error is only occur in win98.
if you know the solution then please reply.
|
|
|
|
|
I've got a hunch. There's a well known bug n Win95 (maybe it has survived in 98) that causes RasDial to fail with this error code when:- No entry name is specified
- and no dial-up connection is set up in the system.
The only solution I can come up with would involve creating a dummy entry (with RasSetEntryProperties) even if you don't use it later on. Please report back if you try this.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
