|
Got an app. It's claiming that the function tapiGetLocationInfoA does not exist in TAPI32.DLL under win95. On all other versions of windows, the program works fine.
If I compile the same code set (absolutely NO changes since the last compile on the other machine) on another machine, the resulting EXE file works fine - even on win95.
Anybody got a clue as to why this might be happening?
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Could be a dependancy in a mismatched DLL sitting between your app and TAPI32.
|
|
|
|
|
A short in the dark,
What version of Win 95? A lot of the earlier versions had a crap version of TAPI. There is a download on Microsft's site somewhere for the proper version of TAPI 2.1 to be installed on 9x machines.
If I had a penny for every TAPI/WIN95 problem I've come across...
Michael 
|
|
|
|
|
Well, I would really like to think this was the case, but the problem goes away if I build the same app on a different machine. I think it's a SDK problem.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Is it Win 95 OSR2?
If not, then most of the other stuff dont work too.
Nish
My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold
www.busterboy.org
|
|
|
|
|
It is osr2.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I need to send a page eject to the Windows default printer. This is all the program needs to do.
What function or code snippet in Visual C++ do I need to use.
Thanks
|
|
|
|
|
There's a really nice CPage class for printing here
All you would need is to call it's StartDoc();StartPage();EndPage();EndDoc() functions, after grabbing the printer info (you can hide the dialog -- you'll see what I mean). It works transparently - so local or network is not an issue
|
|
|
|
|
I have a simple WTL dialog-based app that uses a single thread to service a number of named pipe clients using overlapped (async) notification reads. When it receives a message from a connected client, the text is output to a RichEdit textbox (it's a sort of trace appy).
What I do is call PeekNamedPipe() to get the number of bytes queued in the pipe, then allocate a TCHAR of that size and use it as a buffer for ReadFile(). It works fine except for the fact that I always get trailing garbage chars on the buffer, even when I know that the message received, the number of bytes written to the pipe and the size of the read buffer are all exactly the same (I have a Unicode build that does the same thing). For the life of me I can't figure out what I'm doing wrong:
::PeekNamedPipe(thisPipe.hPipe,NULL,0,NULL,&dwBytesToRead, NULL);
if (dwBytesToRead !=0)
{
try {
pData = new TCHAR[dwBytesToRead];
memset((void*)pData,0,sizeof(TCHAR) * dwBytesToRead);
dwBytesRead = 0;
} catch(...) { return -1; }
}
fSuccess = ::ReadFile(thisPipe.hPipe,(LPVOID)pData,dwBytesToRead,&dwBytesRead,&thisPipe.ov);
if (fSuccess && (dwBytesRead != 0))
{
pdlg->outputPipeWrite(pData);
}
This is somewhat simplified code. The buffer is correctly delete[]'d after each receive. Basically, I can see the buffer being allocated and zeroed. When ReadFile() returns, I see the garbage chars at the end. I get no heap violations or anything like that, and I'm not leaking memory. It's bugging the heck out of me
The code that puts the text in the textbox is just a simple CRichEditCtrl::AppendText() call.
Thanks for any insight.
___________
Klaus
[www.vbbox.com]
|
|
|
|
|
Duh. I guess talking about a problem makes us approach it in different ways.
I solved it using a CString:
CString sMessage;
fSuccess = ::ReadFile(thisPipe.hPipe,
(LPVOID)(LPTSTR)sMessage.GetBufferSetLength(dwBytesToRead),
dwBytesToRead,
&dwBytesRead,
&thisPipe.ov);
pdlg->outputPipeWrite((LPCTSTR)sMessage);
sMessage.ReleaseBuffer();
I'd still like to know why the TCHAR buffer was doing that weird thing. Sigh.
___________
Klaus
[www.vbbox.com]
|
|
|
|
|
TCHAR isn't doing anything weird, you are.
[edit] (God I am sounding grumpy lately. Edit to make it not sound so bad.)
To fix the problem, prior to calling outputPipeWrite, add the line...
pData [dwBytesRead] = 0;
But, you will also have to account for the extra character, so you need to change your allocate.
try {
pData = new TCHAR[dwBytesToRead + 1];
dwBytesRead = 0;
} catch(...) { return -1; }
The memset is pointless.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim,
Tim Smith wrote:
TCHAR isn't doing anything weird, you are.
I absolutely see your point, and FWIW I did try this at one time. Perhaps in my desperation I did something else wrong, dunno. Other than the sample you posted I also tried allocating by +1 and doing an lstrcat(pData, '\0') deal, didn't work either (obviously)
And yes, I know the memset is pointless - it also got into the code in the middle of my desperation 
I've been working too hard and I think I'm coming down with something so I wasn't thinking clearly, I guess. Don't write code while on medication! 
Anyhoo, thanks for replying. I appreciate it. Even though you did sound a bit grumpy there
___________
Klaus
[www.vbbox.com]
|
|
|
|
|
Hello!
I just installed Microsoft Visual Studio Service Pack 5, I had Visual C++ 6.0 Standard Edition on my computer already. I opened up one of my programs and ran the program under debug mode and I got an assertion errors saying:
Debug Assertion Failed!
File: olelink.cpp
Line: 85
Upon inspection, line 84-86 of olelink.cpp look like this:
// attach the document to the server
ASSERT(m_pFactory == NULL || m_pFactory == pFactory);
m_pFactory = pFactory;
Part of the "Register" function which I think registers an OLE document.
"Okay" I'm thinking, maybe just another strange error for which I have to recompile the project because of a service pack. So I recompile the whole project run it again under debug mode, same assertion. I run it under release mode, same error. I restart my computer, run it under debug mode then release mode, same error every single time. So I go into a debug session and step through the code until I hit the assertion where its failing. I check to make sure why its asserting and apparently m_pFactory = 0xffffff, and the program asserts.
I have no possible clue WHY it asserts, 0xfffffff is obviously an invalid address, but maybe the program doesn't think its null. I searched everywhere on codeproject, codeguru, microsoft support, nothing on this problem. Does anyone have any idea here? Can you give me a clue or a lead? I would be most grateful, otherwise its looking like I'm going to have to reinstall visual c++ standard edition and avoid service packs for the rest of my life (I don't know why I didn't avoid this one).
By the way, I'm running on Windows XP, and my version is Visual C++ 6.0 Standard Edition, and the program I tested was working before I installed service pack 5.
Thanks a bunch in advance for anyone who can help me!
Sincerely,
Alexander Wiseman
Est melior esse quam videri
It is better to be than to seem
Et tu, Microsoft?
|
|
|
|
|
0xfffffff is not NULL. 0x0 is NULL. That is why the assert is firing.
How it got to that state, is an entirely different question. You could try to trace it back and see where it gets this value, you will probably find it happens in one of the dlls that were replaced by the service pack. Is it possible that one of the XP dlls got reverted to an earlier version when the SP 5 was installed?
I use VC 6 with SP5 on my XP Home edition. I haven't seen this problem, but I haven't used it much in that environment yet.
Good Luck,
Bill
|
|
|
|
|
Bill,
Thanks for your response. I know 0xfffffff is not NULL, but I'm wondering why the stupid variable wasn't initialized to NULL to satisfy the ASSERTION condition. I believe that you are correct in saying that one of the XP dlls got changed by the service pack, but I fail to see why Microsoft did not say anything about it in their report of the fixes.
Anyway, if someone else comes up with this problem I'll look into again, I uninstalled then reinstalled Microsoft Visual C++ Standard Edition to start from square one, didn't take too long and everything is back to normal now, so I'm in business.
But I definitely want to know what the heck happened...
Thanks for your help!
Sincerely,
Alexander Wiseman
Est melior esse quam videri
It is better to be than to seem
|
|
|
|
|
I'm trying to create a static window and be able to draw lines inside that window.
|
|
|
|
|
Handle OnPaint to draw in the window.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
A static window...like
HWND hwnd = ::CreateWindow("STATIC", "Example text", WS_CHILD |WS_VISIBLE....);
The way I see it you have a few options:
1) Subclass your STATIC control and use it's own WM_PAINT to draw on the control.
2) Use it's returned handle (hwnd) and retrieve it's HDC using GetDC() In it's parent's OnPaint() (WM_PAINT) also draw to this DC
2) Make it ownerdrawn WS_ONWERDRAW handle the drawing in a subclassed WndProc() or in the parents OnDrawItem.
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
This question is actually just about C++. I'm writing a program and I have this huge set of calculations, for which I need a lot of accuracy. I'm using doubles because they are the most accurate as far as I know. But they still aren't accurate enough, my results are still messing up, due to lack of accuracy. Is there any way to get more accuracy than a double? And I mean, a lot more accuracy (like even triple the number of decimal places if thats possible).
|
|
|
|
|
Check GNU MP library out.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If you can convert your stored results to integers (necessary to reduce round off errors, anyway), you might find this link useful.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Why do you need that many digits?
The reason I ask is that in many cases people think they need that many digits when they really don't. Errors can accumulate with float point computations. Things can be done to improve accuracy without adding more digits.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Currency comes to mind, although I've never used them from C++ other than for the occasional LARGE_INTEGER hack.
___________
Klaus
[www.vbbox.com]
|
|
|
|
|
Hi,
Just installed VS.NET, and i've been recompiling my apps in VC++7. I'm getting a lot of compiler warnings about conversion from ULONGLONG to various other data types.
I'm guessing that ULONGLONG is a new data type. What does it correspond to? I can't find much in MSDN about it, just something to do with performance monitor which is hardly relevant.
Some MFC member functions seem to return it, such as CFile::GetLength(). Please tell me more about it! and why is there virtually nothing in MSDN about it?
thanks
Jon
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
unsigned 64 bit integer. Some MFC routine have been modified to return this value. If found this information in MSDN.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
