|
How would I be able to use fprintf to write this to a file?
for (int a=0; a<10; a++)
{
for (int aa=0; aa<10; aa++)
fprintf(outClientFile,a,aa)endl;
}
|
|
|
|
|
In case you want it - here's the CElapsed timer. I use it for high-resolution timing. It typically has a an overhead of around 2uS, depending on CPU, so it can usually time to within 10uS.
#ifndef _CELAPSED_H
#define _CELAPSED_H
#else
#error repeated include of this file
#endif
class CElapsed
{
private :
double m_Period;
int m_Initialized;
__int64 m_Frequency;
public :
CElapsed()
{
m_Initialized = QueryPerformanceFrequency( (LARGE_INTEGER *)&m_Frequency );
if( ! m_Initialized )
m_Period = 0.0;
else
m_Period = 1.0 / (double)m_Frequency;
}
double Elapsed( double begin=0.0 )
{
__int64 endtime;
QueryPerformanceCounter( (LARGE_INTEGER *)&endtime );
double endsecs = endtime * m_Period;
return endsecs - begin;
}
BOOL Initialized()
{ return m_Initialized; }
__int64 GetFreq()
{ return m_Frequency; }
double FromMilliSecs( UINT millisecs )
{ return 0.001 * millisecs; }
void Delay( double amount )
{
double delta;
double delaytime;
double start = Elapsed( 0.0 );
while( true )
{
delaytime = Elapsed( start );
delta = amount - delaytime;
if( delta <= 0.0 )
break;
if( delta > 0.0012 )
Sleep( 1 );
}
}
};
|
|
|
|
|
Hi,
I have created a Comboboxex and it doesn't send message for WM_MOUSEMVOE. So i can't add a tooptip control above it. I tried but it still doesn't work. Here is my code for creating Comboboxex:
hWndFontCombo = CreateWindowEx (
0, // extended styles
"ComboBoxEx32", // extended combo box – will
str, // default text
WS_VISIBLE | WS_CHILD | WS_TABSTOP |
WS_VSCROLL | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | CCS_NORESIZE |
CBS_AUTOHSCROLL | CBS_DROPDOWN,
rect.right,0, // x, y
MIN_COMBOCX-8, // width
2* cy * NUM_FONT_TYPE, // height
hWndParent, // parent window
(HMENU)ID_COMBO, // ID
hInst, // current instance
NULL ); // no class data
Can anyone tell me how I can display the tooltip for this comboboxex? Thanks a lot.
|
|
|
|
|
Why are you creating the control at runtime rather than at design time? In any case, has EnableToolTips() been called? Are you handling the TTN_NEEDTEXTA and TTN_NEEDTEXTW notifications?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
How to call EnableToolTips for Win32 based code (not MFC code). Thanks.
|
|
|
|
|
I think you might need to call InitCommonControlsEx() instead. To create the tooltip window, use CreateWindowEx() with TOOLTIPS_CLASS as the second parameter. See here for more.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I'm trying to read whatever is stored in my document inside the Serialize method
But, whenever I read into a string from the archive, it takes out that string from the archive. Thus, when I call the Baseclass serialize, the outputted Document is missing the string that was read. Is there a way to read such that the string is not taken out from the archive? I tried reading the string after I called the base class serialize, but I get only an empty string.
Thanks, (code is below).
void CRichedDoc::Serialize(CArchive& ar)
{
CString buf;
ar.ReadString(buf);
CRichEditDoc::m_bRTF = FALSE;
CRichEditDoc::Serialize(ar);
}
|
|
|
|
|
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.
|
|
|
|