|
I'm afraid i still can't say what is wrong, sorry, unless you are willing to share the project (or some extract of it), maybe it would help if i could look around it a bit, see variables and such.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Code-o-mat wrote: ...maybe it would help if i could look around it a bit, see variables and such.
It's extremely easy to duplicate.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
David,
It looks like this is happening within the MFC framework. Double click on this line:
DavidCrow wrote: mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0073dce8) Line 241 + 0x8 bytes C++
The memory address 0x0073dce8 is a MSG struct[^]. Please try to find the value of MSG.message so we know what window message is being processed by the MFC framework. Your debugger should be able to show you this. It would be nice to know what window message we are dealing with.
The debug string you posted implies that the assertion occured at:
ASSERT(::IsWindow(m_hWnd));
Which means the m_hWnd member of the CWnd/CTempWnd object that is returned by GetTopLevelParent() is apparently not a valid window.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Please try to find the value of MSG.message so we know what window message is being processed by the MFC framework. Your debugger should be able to show you this. It would be nice to know what window message we are dealing with.
The message is 512 (WM_MOUSEFIRST).
Randor wrote: The debug string you posted implies that the assertion occured at:
ASSERT(::IsWindow(m_hWnd)); Which means the m_hWnd member of the CWnd/CTempWnd object that is returned by GetTopLevelParent() is apparently not a valid window.
It's as though a second tooltip window is being requested (i.e., a tooltip for a tooltip?) before the first one is completely destroyed.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hey David,
DavidCrow wrote: The message is 512 (WM_MOUSEFIRST).
Well the WM_MOUSEFIRST definition is not a window message it was defined to make it easier to find the range of mouse message with WM_MOUSEFIRST/WM_MOUSELAST. However WM_MOUSEFIRST is equal to WM_MOUSEMOVE. It is actually the WM_MOUSEMOVE message being processed.
DavidCrow wrote: It's as though a second tooltip window is being requested (i.e., a tooltip for a
tooltip?) before the first one is completely destroyed.
My guess:
I would guess that it might have something to do with the way your creating or passing the CWnd that owns the tooltip. The MFC framework probably expects the handle to the owner CWnd to be in the permanent handle map. I suspect that what is happening... is that a CTempWnd object owns the tooltip... and the MFC framework is deleting the temporary CTempWnd object. When you move your mouse over the tooltip the memory address at m_hWnd may be invalid because the CTempWnd was deleted. This is the only thing I can think of that would cause what you decribe.
Are you using the GetDlgItem function anywhere? Because when GetDlgItem cannot find a permanent object in the MFC CHandleMap it will return a pointer to a temporary CTempWnd object. You should never pass the HWND returned from GetDlgItem to other functions...
Could you tell me more about the window that owns the tooltip?
Also... please call CWnd::FromHandlePermanent()[^] to check if the tooltips owner CWnd is in the MFC permanent handle map. If it returns NULL then this is most likely your problem and we can fix it.
Best Wishes,
-David Delaune
|
|
|
|
|
The only thing I did was copy the code in CFrameWnd::OnToolTipText() to my dialog, and then call EnableToolTips(TRUE) from within OnInitDialog().
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
|
Jochen Arndt wrote: I'm using the method described in the MSDN article Handling TTN_NEEDTEXT Notification for Tool Tips[^] and never had problems.
With VS2008?
Jochen Arndt wrote: However, this requires that every control has its tool tip text in a string resource with the same ID as the control.
Yes, that part was assumed.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
With VS 2003. I supplied the link for 2005. But you may selcet other versions on top of the page. Providing the text by a buffer or by ID should make no difference. But all the MSDN examples did not call SetWindowPos().
|
|
|
|
|
Jochen Arndt wrote: With VS 2003. I supplied the link for 2005. But you may selcet other versions on top of the page.
I realize that. The point I was trying to make is that MFC may have changed from one version to the next. This same code I've been using worked fine in VS6.
Jochen Arndt wrote: But all the MSDN examples did not call SetWindowPos().
See my reply here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Sorry, the thread is quite long.
But there is another difference between your code and the MSDN examples:
You are always returning TRUE indicating that the message has been handled. The examples (and my code) only return TRUE when the TTF_IDISHWND flag is set and the control's ID can be determined from the HWND.
|
|
|
|
|
DavidCrow wrote: The only thing I did was copy the code in
CFrameWnd::OnToolTipText() to my dialog, and then call
EnableToolTips(TRUE) from within OnInitDialog().
The tooltip related code you pasted is perfectly fine. You never answered any of my questions about the window hierarchy so I have to make further guesses. I am guessing that the tooltip being shown is for a dynamically created window. There is probably no member variable associated with the window. Read my previous statements regarding CTempWnd objects.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You never answered any of my questions about the window hierarchy so I have to make further guesses.
I guess I don't understand. Other than calling EnableToolTips(), adding to the message map, and providing a notification handler, I don't do anything regarding creating temp windows, adding to maps, or calling GetDlgItem().
Randor wrote: There is probably no member variable associated with the window.
Actually there is. That's what I use to set/get values from the controls.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hi David,
Could you answer each of these questions?
1.) Are you saying that the assertion occurs when the mouse moves over ALL tooltips belonging to child windows of the dialog? Or does the assertion occur for only one of them.
2.) If it is just 1 window that causes tooltip asserts... Does the assertion occur on a window that is dynamically created such as the CListCtrl you were working on last week[^]?
I apologize for all the questions... but if you would have been very detailed in your initial description we could have avoided the guessing. Considering that you have been a member here for nearly a decade I would expect your questions to be a long narrative. Maybe even with diagrams, debugger stack frames and sprinkled with source snippets. 
Thanks,
-David Delaune
|
|
|
|
|
Randor wrote: 1.) Are you saying that the assertion occurs when the mouse moves over ALL tooltips belonging to child windows of the dialog? Or does the assertion occur for only one of them.
All tooltips. Do you have VS2008 on your end?
Randor wrote: 2.) If it is just 1 window that causes tooltip asserts... Does the assertion occur on a window that is dynamically created such as the CListCtrl you were working on last week[^]?
Same project  , but this particular dialog has only controls created at design time.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
David,
DavidCrow wrote: All tooltips.
That changes everything. It implies that CWnd::FilterToolTipMessage[^] is not being called to handle the tooltip messages... (This is why you should be very detailed in the initial question)
Do you have a WindowProc function? It is possible to call FilterToolTipMessage from there... but we should find out why the framework is not filtering tooltip messages. I assume that you called EnableToolTips. Is this an ActiveX control?
DavidCrow wrote: Do you have VS2008 on your end?
Absolutely. I have VC6, 2005,2008,2010 installed on my workstation.
|
|
|
|
|
Randor wrote: Do you have a WindowProc function?
No.
Randor wrote: I assume that you called EnableToolTips.
Yes, otherwise the tooltip would not be displayed at all.
Randor wrote: Is this an ActiveX control?
No, just a plain ol' dialog box with an edit control.
Randor wrote: Absolutely. I have VC6, 2005,2008,2010 installed on my workstation.
Can you reproduce this?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hi David,
DavidCrow wrote: Can you reproduce this?
No, the tooltip code you posted looks perfect and there is absolutely nothing wrong with it.
There is something fundamentaly wrong... but I have to keep guessing because I cannot see your project and debugger output. At this point the only other thing I can think of would be an invalid AFX_MODULE_STATE. Are you mixing static linked MFC based libraries with dynamic?
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Are you mixing static linked MFC based libraries with dynamic?
Linking with MFC libraries dynamically.
When I get back to the office on Friday, I can zip the project up and email it to you if you'd like.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
David,
DavidCrow wrote: When I get back to the office on Friday, I can zip the project up and email it to you if you'd like.
That would probably be the best way to avoid a half dozen more questions. 
As you probably already know... you can click 'Email' at the bottom of this post and I will recieve the message.
Best Wishes,
-David Delaune
|
|
|
|
|
I know that need send 25 frames per second, but how to keep time span between two frames as 40 ms?
modified 2-Apr-12 12:43pm.
|
|
|
|
|
Well, you can always have a transfer thread that sleeps between transfers.
while(1){
transfer();
Sleep(40);
}
Or, you can always make the packets bigger and transfer at a slower rate, the slower rate should give you more flex room for accuracy.
while(1){
transfer(25_frames);
Sleep(1000);
}
Or... why not transfer data as fast as possible, and throttle it on the receiving end? This has the benefit of building a buffer so that the processing flow is not interrupted.
|
|
|
|
|
Not completely sure i understand what you are trying to do, but -as far as i know- what DirectShow[^] does is to give each frame a (kind of) time stamp and the renderer will use the time stamp to display a frame when it is time to display it and until that time comes, it buffers the frames.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
You could use a multimedia timer. Check out the following API calls:
timeGetDevCaps()
timeBeginPeriod()
timeSetEvent()
You can set up an accurate timer using these.
|
|
|
|
|
Thanks.
Now, the solution is that the low level return a struct that includes the start time of current frame and the duration of current frame.
The Application uses these two value to control time span.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
