|
I found out a bit more.
In VC++ 7.0 when you create a dialog from a dialog resource the default class in NOT CDialog! It's CHTMLDialog.
I don't know all about this (yet)... but if you want a dialog based on a dialog resource (like it was in VC++ 6.0) when you create the class you need to change it from CHTMLDialog to CDialog.
Maybe we should be using CHTMLDialog for our dialogs in VC++ 7.0, but I haven't found the tools for editing the html like the tools we have for editing a dialog resource. The html code just comes up in text editor like view.
Again, thanks for your interest in trying to help me with this.
|
|
|
|
|
You've definitely convinced me not to upgrade!!
Thanks for the help,
Bill
|
|
|
|
|
I urgently need a LL(1) parser. If someone has it then plz email to me as soon as possible. Thank you
|
|
|
|
|
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?
|
|
|
|
|