![]() |
CXTPControl Tooltip |
Post Reply ![]() |
Author | |
lion ![]() Groupie ![]() Joined: 04 March 2008 Status: Offline Points: 22 |
![]() ![]() ![]() ![]() ![]() Posted: 25 March 2009 at 5:59am |
Hi,
I would appreciate some help with a very strange problem: We are using CXTPControls for our toolbars and we also are setting some tooltips. We also use winsock to communicate with other apps. Here we also use 'WSAAsyncSelect' to map socket event to window events. Now we found out that some messages sent to our app are getting lost when pressing toolbarbuttons without waiting for the tooltip to be displayed beforehand... This is what is happening: 1. pressing the button 2. our app sends a message over winsock 3. immediatly receiving an answer over winsock when waiting for the tooltip to be displayed completely in step 1 before pressing the button we get an windowevent receiving the answer in step 3. when pressing the button immediatly, e.g. NOT waiting for the tooltip in step 1, we DON'T get the event. when not setting the tooltip for that control everything works fine as expected. Why could that be the case ? Where can I find out more about this subject? Thanx for your help. Cheers B |
|
![]() |
|
rdhd ![]() Senior Member ![]() ![]() Joined: 13 August 2007 Location: United States Status: Offline Points: 921 |
![]() ![]() ![]() ![]() ![]() |
Are you using RegisterWindowMessage or just making up a user message value? Perhaps you are using some message value that the tip happens to use too? Also, I don't know if this matters but we found that at least with context menus, CJ does a SendMessage instead of a PostMessage when the user clicked the control (I think on mouse down the message is sent but it might be on mouse up). That caused us some unexpected issues as the stack doesn't unwind like it does with PostMessage (used by MFC context menus, toolbar buttons etc). So we had to stop CJ from sending the message and then post it ourself. For example, we had a command that showed a shortcut/context menu and the user picked a "Delete" entry that deleted our document, which killed the command that was tracking the popup menu. Our system deleted the command and as the stack unwound back to the command code - kaboom - since all the instance data was deleted and the command did not expect that to occur.
If all else fails, if you have Visual Studio, use Spy++ to trace your messages (Spyxx.exe). It will show you user defined messages as well as Microsoft defined. Be aware that besides Windows defined messages (like WM_MOUSEMOVE), MFC also reserves a set of message values you should not use so RegisterWindowMessage is the only safe way to go if you have your own custom values.
|
|
![]() |
Post Reply ![]() |
|
Tweet
|
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |