|
vasanth1004 wrote:
void CRichedDoc::Serialize(CArchive& ar)
{
CString buf;
ar.ReadString(buf);
CRichEditDoc::m_bRTF = FALSE;
CRichEditDoc::Serialize(ar);
}
Shouldn't this be:
void CRichedDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
ar << m_buf;
else
ar >> m_buf;
}I've not ever used CRichEditDoc or m_bRTF so I may be way off.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
What I had originally works, but it removes the string from the archive. I also tried creating a new archive by getting the filename from the passed archive, but it didn't make a difference.
Thanks
|
|
|
|
|
vasanth1004 wrote:
What I had originally works...
So what did you do that made it stop working?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
So what did you do that made it stop working?
Sorry, I was wrong. It didn't work the way I wanted to: it reads it but also removes the string from the Archive.
Basically I just want to read the contents of the current document into a String without removing what I read from the Archive. How do I do that?
|
|
|
|
|
Put them into two separate variables and than concatenate them.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
|
Yes.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hi,
i have a question regarding OpenGL and double buffering.
The drawing routine has the following commands:
wglMakeCurrent(m_hDC, m_hRC);
DrawScene();
SwapBuffers(m_hDC);
wglMakeCurrent(0, 0);
The problem is that SwapBuffer seems to clear the screen before actually copying the backbuffer in. This seems quite strange to me. The content to draw consists of approx. 50000 single points drawn using the GL_POINTS directive. It seems that the problem only occurs with a high number of points (or it is only visible there). Can anyone give me hints what could be wrong?
Of course double buffering is enabled in the Pixelformat:
...
pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
...
Thanks in advance,
Ingo
|
|
|
|
|
1) Handle WM_ERASEBKGND. Do nothing in the message handler (return TRUE), overriding the default behavior. This will prevent the window from being repainted between WM_PAINT messages. This may be all that's required; if not, then ...
2) 50,000 points is a bit much, if you expect a high frame rate. The reason the flicker seems to increase w/ the number of points is because your frame rate is dropping.
|
|
|
|
|
I don't think the problem is with SwapBuffer.
The whole point of double buffereing is that SwapBuffer updates the front buffer for the next screen refresh - if you are actually using a double buffered pixel format then this will not cause flickering.
Your problem is somewhere else.
e.g.
- WM_ERASEBACKGROUND not being handled
- window being created with a non-NULL background brush
- you aren't actually using a pixel format that supports double buffering
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Anybody know how to draw lines in RichEditView? I am using the following code but the line is not being drawn.
// Get Window size
CRect rcClient;
GetClientRect(&rcClient);
// Construct the pen
CRichEditCtrl &RichCtrl = GetRichEditCtrl();
CDC* pDC = RichCtrl.GetDC();
CPen MyPen(PS_SOLID, 10, pDC->GetTextColor());
CPen *pOldPen = NULL;
pOldPen = pDC->SelectObject(&MyPen);
// Draw the line
pDC->MoveTo(rcClient.left + 2, rcClient.bottom - rcClient.top);
pDC->LineTo(rcClient.right - 2, rcClient.bottom - rcClient.top);
// Return to original pen
pDC->SelectObject(pOldPen);
Since I am using RichEditView, I am not able to use the OnDraw Method. I believe the problem is getting the device context. I have also used "CDC* pDC = this->GetDC();" with the same results. Any ideas?
|
|
|
|
|
I'm trying to handle the WM_SIZING message in my dialog, but for some reason, it's simply not firing when I resize the dialog. I added handlers for OnSize() and OnWindowPosChanging() as a sanity check, they both work fine, but for some reason OnSizing() is just never being called. I'm probably missing something really simple, but I just can't see what else there is to handling the message besides using the wizard to add the OnSizing function and ON_WM_SIZING() to the message map.
Any ideas about why it isn't working?
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
Have you used Spy++ to verify that the WM_SIZING message is actually being sent?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Unfortunately, use of Spy++ causes my system to come to screeching halt. I even tried setting it up so that it would only capture the possible WM_SIZING message to that dialog to the same result. I use the finder tool to get my dialog, in the messages tab I select only WM_SIZING (though no matter what my settings are here the result is the same), and use the default output options ... immediately after hitting OK on this dialog, every open window stops responding except for a random couple - sometimes it is the spy tool, sometimes an explorer window, sometimes the MSDN library that stays active ... and I've even had the task manager window stop responding. This is with WinXP Pro.
Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
Vineas wrote:
Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something.
That's rather disturbing... Is this just when trying to spy on your app, or does it happen with any app?
You must be careful in the forest
Broken glass and rusty nails
If you're to bring back something for us
I have bullets for sale...
|
|
|
|
|
Haven't tried anything else ... I suppose that might be interesting in itself. I'll have to try that tomorrow and drop a note in here as to the results.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
Works on other apps, and found that it even works with this app if I'm not running in the debugger. So it only happens if I'm running in the debugger and try to spy it. This didn't happen at my last project, I've always done this with the app running in the debugger without problems.
Anyway, on a related note, now that I've actually been able to Spy the dialog, the WM_SIZING message never does get sent, only the other ones that have handlers that work.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
If the style of your dialog window is not set up correctly, then Windows will not send you the message - Windows will not interpret your window as being capable of resizing. A typical dialog frame does not allow resizing.
|
|
|
|
|
It is setup with the "resizing" border style in the dialog properties window. It also resizes fine, and the WM_SIZE message comes through as expected, but the WM_SIZING message just never seems to happen.
I dug around a bit more in the dialog and it's base classes, and found that the sizing isn't done entirely through the framework like I though it was. The sizing actually happens inside of a mouse move event which calls "SetWindowPos" when the left mouse is also down. I don't know exactly why this was done (it was done ages ago, long before I started working on it and the developer who did it is no longer here).
Is this the likely culprit? Will a call to SetWindowPos to resize a frame cause the WM_SIZE and WM_WINDOWPOSCHANGING messages to come through as I'm seeing, but not WM_SIZING? That doesn't make much sense ... if WM_SIZE fires, WM_SIZING should as well.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
All I can think is that calling the SetWindowPos is more of a 'final' event than 'resizing' a window is, so there is no 'sizing' message only the 'here is the new size' message. If the mouse movement was cpatured for a different reason and the window's position was adjusted by Windows, instead of by the handler of the dialog itself, you would probably get all the messages you are expecting.
|
|
|
|
|
Yeah, as soon as I saw that, I was afraid that was the case. I'll have to see what I can do about removing this current way of sizing. From what I can tell of the code so far, the only reason it was done this way is so that the code can put a limit on how large the dialog gets ... which is perfectly handled in OnSizing (once I can get that event to happen anyway).
Thanks.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
You should also see if you can receive the WM_MINMAXINFO message, which is where you are supposed to constrain the minimum and maximum size your window can get.
|
|
|
|
|
What do you do in your top level window to be notified that the screensaver has become active? I want to respond to this and temporarily disable a periodic event.
Likewise, what notification is received once the screensaver has been deactivated and your window is now 'visible' again, even though your window might not be the one that is the 'active' window?
|
|
|
|
|
How about SetWindowsHookEx(WH_FOREGROUNDIDLE, ...) or SystemParametersInfo(SPI_GETSCREENSAVERRUNNING, ...)?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
1. I could not see that the WH_FOREGROUNDIDLE would directly apply to the screensaver. I suppose if this event is detected, I could create a different timer to check the SystemParametersInfo every 30 seconds or so to see if the screensaver had become active.
2. This requires polling and is not a notification. I am looking for something sent to all 'top level windows' when the screensaver becomes active.
I did find this one, WlxScreenSaverNotify, but I don't want to replace the GINA DLL.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
