|
I've been trying for about an hour or so and I'm royally stuck.
Basically I've got a class CShapePt. The program is like a mini paint utility. Whenever the user clicks on the client area it takes the point clicked. Then the next time he/she clicks it draws a line between the two places. The Array it was using was in the MainFrame Header file. I'm not exactally sure how to put the CShapePt object into the MainFrame header file so that the device context can access it. How do you do those code highlighter things? If you need some code to help you see what I'm having trouble explaining I'll be glad to put some snippets on here. Thanks.
-CDudd
|
|
|
|
|
Ditto on the STL stuff.
I might have some strong reservations about many of the STL features, but the containers are GOLDEN...
droooool...
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?
|
|
|
|
|
I am handling the WM_GETMINMAXINFO message in my MFC app in the PreTranslateMessage function. When I resize my dialog this message is never sent. Do I have to go about this a different way with MFC or something?
|
|
|
|
|
In MFC, providing you're using a CWnd derived class, you should just be able to define a member function like:
afx_msg void OnGetMinMaxInfo(MINMAXINFO *pMMI);
and add:
ON_WM_GETMINMAXINFO()
to your message map. Probably easier than the PreTranslateMessage stuff. I'm not sure why you're not getting the message, though.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
That worked.. Kinda weird that it didn't work in PreTranslateMessage. Thanks for your help.
-Zack
|
|
|
|
|
Actually, no, it isn't strange.
PreTranslateMessage is only invoked as part of the normal message pump. Or at least that is what the docs say. I am sure there are a few other instances it is called.
However, my bet is that WM_GETMINMAXINFO is being sent to your window via SendMessage thus the message loop never sees the message. (There are some instances where a SendMessage goes through a message loop, but that is of no concern for 99% of all windows programmers.)
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?
|
|
|
|
|
I'm trying to do something that I think is very simple in VC++ 6.0 in the new VC++ in the Visual Studio.NET. I'm getting strange results. It looks like creating a dialog is creating some HTML code as well as the recource (.rc) and DoModal() seems to be using both of them.
Here are the steps I'm using.
I am creating a VC++ project selecting an MFC Application.
I'm changing these defaults:
Application type = Single Document
Database Support = Header Files Only
ODBC (instead of OLE DB)
In the last step I'm chaning the CView to a CFormView.
The wizard pops a message about no printing support - but I think that's ok.
Now I add a resource, it's a dialog - leave the defaults for this test. Make a class from this resource - DIALOG1.
On my CFormView I add a button [Do It]... add the #include for my DIALOG1.h and add a message handler for this [Do It] button with this simple code:
DIALOG1 d;
d.DoModal();
It runs... but the buttons seem to have shadows and there is a 'TODO: Place controls here' text on my dialog. Hey! That message is not on my dialog resource! Hey! In the HTML folder there is a IDR_HTML_DILAOG1 html file.... that's got buttons and the message that are not on my resource, but are displayed when my dialog 'runs'.
If you move the buttons on the resource you can see that the 'shadows' are really copies of the [OK] and [CANCEL] buttons that are on my dialog.
What's up with this? Is anyone else seeing this stuff?
Rick Crone
|
|
|
|
|
When the wizard creates a dialog, it includes 3 controls in it:
OK Button
Cancel button
Static containing the text 'TODO: Place controls here'
I don't know why you aren't seeing it with the resource editor. It apparently is there, or you wouldn't see it at run time.
I've never seen it create HTML code when inserting a dialog.
Good Luck,
Bill
|
|
|
|
|
I agree that is how it worked in VC++ 6.0.
You have built a VC++ 7.0 MFC application and added a dialog to it and you don't see the html?
I have the buttons on the resource, but not the TODO message. I have the buttons and the TODO message on the html code.
|
|
|
|
|
I haven't used VC7 yet. Sorry, I guess I thought you had a question.
|
|
|
|
|
Well, I guess I'm the only one trying to use VC++ 7.0 in .NET.
At least it looks that way from the responses my question got.
Unless:
1.) My version is just different from eveyone elses.
2.) There is something about how I'm setting up my application up.
3.) There is something new about creating dialogs.
I don't see how anyone could be using this product.
You are the only one who even answered.
|
|
|
|
|
I guess I'm still having trouble understanding the question.
Are you trying to get a different behaviour out of the wizard? (Not likely)
Are you trying to modify the HTML?
Are you trying to get rid of the html control on the dialog?
|
|
|
|
|
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]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
