Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 ALT-G Still beeping
 New Topic  Topic Locked
 Printer Friendly
Author Previous Topic Topic Next Topic  

willdean
Tomato Guru

134 Posts

Posted - Feb 05 2004 :  04:19:39 AM  Show Profile

1215 still beeps when you do an ALT-G - though I think it might only be if VA correctly detects that there's only one choice, and goes straight there without a listbox.

I'm seeing it with #defines at the moment, if that helps you find it.

Will

support
Whole Tomato Software

5566 Posts

Posted - Feb 05 2004 :  12:05:20 PM  Show Profile
We keep looking. Clues help a lot. Send more as you find them.

Whole Tomato Software, Inc.
Go to Top of Page

willdean
Tomato Guru

134 Posts

Posted - Feb 05 2004 :  12:17:49 PM  Show Profile
Here's my best suggestion:

Open the VA project.
CTRL-SHIFT-H
Put 'MessageBeep' in the find box.
Empty the replace box.
ALT-A

Accept the warning which comes up about undo.

Actually, more helpfully, I'd run the whole thing in WinDBG and set a breakpoint on MessageBeep. In fact, I might do that now and send you a stack trace. I presume you've kept a PDB file for 1215?

Will

Go to Top of Page

willdean
Tomato Guru

134 Posts

Posted - Feb 05 2004 :  12:39:50 PM  Show Profile
Here you are. This was generated by breaking on MessageBeep, after doing ALT-G to a symbol defined in resource.h. VA correctly realised that there was only one place to go, so it went there and tried to beep. But my breakpoint got in the way.

Obviously I don't have any symbols for VAssistNET.dll, so you'll have to work from the offset.

0:000> kv
ChildEBP RetAddr Args to Child
0012f60c 500e6b36 00000000 0012f708 500c40f6 USER32!MessageBeep+0x2 (FPO: [1,0,0])
0012f694 77d43a50 000401e6 00000112 0000f100 msenv!FnwpPropBar+0x6c4
0012f6c0 77d43b1f 500c40f6 000401e6 00000112 USER32!InternalCallWinProc+0x1b
0012f728 77d45b2c 00000000 500c40f6 000401e6 USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0012f758 77d45f73 ffff03eb 000401e6 00000112 USER32!CallWindowProcAorW+0x96 (FPO: [Non-Fpo])
0012f778 1000e15a ffff03eb 000401e6 00000112 USER32!CallWindowProcA+0x19 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9f0 77d43a50 000401e6 00000112 0000f100 VAssistNET!DllUnregisterServer+0xaf2a
0012fa1c 77d43b1f 1000cf40 000401e6 00000112 USER32!InternalCallWinProc+0x1b
0012fa84 77d43d79 00000000 1000cf40 000401e6 USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0012fae4 77d44374 0012fb08 00000001 500c99f5 USER32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo])
0012faf0 500c99f5 0012fb08 ffffffff 00939d34 USER32!DispatchMessageA+0xb (FPO: [1,0,0])
0012fb24 500c9b9d ffffffff 00d10018 00000103 msenv!ThunderMsgLoop+0x19d
0012fb38 30c19ac6 00939d34 ffffffff 00d3006c msenv!CMsoCMHandler::FPushMessageLoop+0x1f (FPO: [2,0,0])
0012fb64 30c19a1e 00d3006c ffffffff 0000099c MSO!Ordinal43+0x169
30bbd4c8 30b274bb 30b2878a 30c1e820 30e704bb MSO!Ordinal43+0xc1
30bf1214 0c2474ff ff0c408b 8b0c2474 11ff5008 MSO!Ordinal834+0x41
0424448b 00000000 00000000 00000000 00000000 0xc2474ff
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Feb 05 2004 :  3:55:30 PM  Show Profile
Thanks for the detailed instructions, however it wasn't us issuing the MessageBeep, from the callstack above you can see it was msenv issuing the beep. The question is why were they beeping. :)

2 frustrating hours later....

Will be fixed in 1216.

Whole Tomato Software, Inc.
Go to Top of Page

willdean
Tomato Guru

134 Posts

Posted - Feb 05 2004 :  4:35:12 PM  Show Profile

No, I'd noticed that - it's somehow connected with WM_SYSCOMMAND, isn't it?

Go-on, tell us the story - you owe me that for getting the trace. (And sitting through symserv dishing-up all those MSDEV symbols I didn't have before...)

Well done for finding it, though...
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Feb 05 2004 :  5:35:20 PM  Show Profile
Since the vsnet interface does not provide a way to progarmatically assign key bindings in a reliable/consistent manor, we have a hack to intercept key keys and test to see if they are assigned and if not handle them and remove all traced of the keys being pressed so vsnet does not get confused. The trick is in removing all traces. Here some events went down the chain to cause a wm_syscommand to still be issued and they beeped out of confusion.

Whole Tomato Software, Inc.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Topic Locked
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000