VB6: Mouse click does not reach underlying control
Troy Donavan
had to move the application to a new development system and I did a regsvr32
to all controls and other resources to get things going on the new
development system. Everything looked good and I was about to ship out an
installer when I noticed that the mouse no longer selected rows in a
FlexGrid. Thankfully, it is at least consistent. It doesn't work on systems
where the application is installed and it doesn't work in the debugger. The
FlexGrid is in a control that I created, but neither the user_control nor the
FlexGrid control in the user control are getting mousedown or click events.
The click events are being processed in the form that contains the control.
What's up with that? !!!
--
Troy Donavan
Ralph
"Troy Donavan" <trdo...@nospam.nospam> wrote in message
news:E64EF6AC-50E0-4207...@microsoft.com...
hard to say.
The usual suspects are
1) The control is sited within a Frame, etc that has been disabled.
2) Or perhaps the original code was forcing the issue by deliberately
disabling the Form and now it is enabled.
3) There may be legacy code for controlling (disable/enable) mouse events
and it somehow got activated. Look for "SetCapture" and "ReleaseCapture" in
the code.
4) Something cute in "SetFocus" went wrong.
5) Does the legacy code have a workaround for allowing Cell Edits? FlexGrid
doesn't provide this ability, so you have to place another control on top of
it with extra code. These work-arounds often depend on a specific sequence
of Events and context, and are easily annoyed by "changes". Check closely.
hth
-ralph
Troy Donavan
Funnier than what I earlier indicated, this application will consistently
work on some computers and will consistently not work on others. Okay, I
only have three data points as yet, but the original development machine
doesn't work (XP Pro SP3) and another XP SP3 machine doesn't work, but a
Windows 2003 Server does work. Plus (and this may trump it all) the
delivered application seems to work for my client.
Here is a common thread for the computers that don't work: they are virtual
machines (VM Server). Does that ring a bell?
--
Troy Donavan
Ralph
"Troy Donavan" <trdo...@nospam.nospam> wrote in message
> Thanks for the response!
>
> Funnier than what I earlier indicated, this application will consistently
> work on some computers and will consistently not work on others. Okay, I
> only have three data points as yet, but the original development machine
> doesn't work (XP Pro SP3) and another XP SP3 machine doesn't work, but a
> Windows 2003 Server does work. Plus (and this may trump it all) the
> delivered application seems to work for my client.
>
> Here is a common thread for the computers that don't work: they are
virtual
> machines (VM Server). Does that ring a bell?
>
lol, that is odd.
Unfortunately I don't have a clue, since fortunately my experience with VMs
has to date demostrated no differences. (Knock on wood.) I could do some
guessing, but likely would only repeat what you have already checked or
considered,. ie, such as getting another desktop (similar to the clients)
and install your software, and then use WinDbg, SysInternals, Spy++, etc. to
investigate what is different. Line by line, message by message, component
by component...
You might rewrite your question including this additional information and
post it to "microsoft.public.vb.general.discussion". That newsgroup attracts
a wide-range of gurus - should improve your chances of getting help.
-ralph