|
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.
|
|
|
|
|
Blake Miller wrote:
1. I could not see that the WH_FOREGROUNDIDLE would directly apply to the screensaver.
My bad.
Blake Miller wrote:
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.
When a screen saver starts, it posts a WM_SYSCOMMAND message to the foreground window with wParam equal to SC_SCREENSAVE.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I saw this article in the MSDN, hope it helps.
HOWTO: Know When Your Screen Saver Starts
ID: Q238882
|
|
|
|
|
If you set a system wide hook for mouse and keyboard when you detect the screen saver has started you'll be able tell when the screen saver has stopped as it is mouse and keyboard activity that they respond to.
Remember that for a system wide keyboard/mouse hook the hook functions need to be in a dll.
|
|
|
|
|
Thanks. I already hook the low level mouse handler, I can just add a low level keyboard hook to that same DLL.
|
|
|
|
|
 Now all I have to do is hope that EVERY possible application that has the foreground focus will post the SAME message to all other top level windows, and then we can all be notified when the screen saver starts. It still does not seem like a sure thing for every window...
|
|
|
|
|
Hi.
I'm tearing my hair out here. 
I am trying to debug a .exe on a remote PC. I have done everything mentioned in article "Remote Debugging in MSVC++ 6.0" and in the MSDN help, but get the following when I try to debug...
"Unable to start debugging, access is denied. Verify that you are an administrator or debugger user". I am logged on the remote PC as an administrator, but with a different logon name to the one on my local PC (where I'm also an administrator). Surely this shouldn't matter?????
Also, when it says "verify that YOU are an administrator..." what does it mean by "YOU" who's it looking for????
Any help much appreciated!
Thanks!!
JC.
|
|
|
|
|
Sounds like the user is the problem. I think you need to add the user you are logging on to the development machine as to the administrator or debugger group on the target machine
|
|
|
|
|
you can use the following command in the command prompt window:
net use \\remotePC /user:remotePC\user_with_admin_rigths *
That should be done before any connection to that remotePC.
The subsequent connections will use user_with_admin_rigths credentials.
WBR
Henry
|
|
|
|
|
Thanks guys!
I've got it working now. I just needed to type -tcpip and -anyuser after the msvcmon.exe in the command prompt on the remote PC. It seems to default to using pipes.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
