Mouse events not firing for constituent controls?
|
|
Thread rating:  |
Andy - 29 Jun 2007 12:56 GMT I've been busy changing an application to make use of UserControls. Previously I had code repeated across many forms, and with the help of people on this newsgroup, I've figured out how to economize on code, and as a bonus I only have to maintain one block of code (on a UC) instead of several identical blocks, where the functionality previously was repeated on many forms.
But I have a problem. One of my new UCs has a PictureBox as a constituent control, and I need it to respond to MouseDown, MouseUp, MouseMove, DragDrop and DragOver. I've got the event handlers in place (as part of the UC code - previously it was part of the forms' code), but they never fire. I don't understand why this might be. The UC also contains a couple of scrollbars, and they respond OK when the mouse is clicked over them. So what do I have to do to get my PictureBox to respond to mouse events?
Lance Wynn - 29 Jun 2007 15:26 GMT hmm, I've never seen anything like this before. How are you determining the events are not firing? If you are consuming the event in the parent form , you need to actually expose the event from the user control using the "Public Event eventname()", and "RaiseEvent eventname()" statements. Otherwise, the events will be handled by the userControl. Which is fine if that is what you want...
> I've been busy changing an application to make use of UserControls. > Previously I had code repeated across many forms, and with the help of [quoted text clipped - 16 lines] > have > to do to get my PictureBox to respond to mouse events? Andy - 29 Jun 2007 15:40 GMT > hmm, I've never seen anything like this before. > How are you determining the events are not firing? By putting a breakpoint at he start of the event handlers.
> If you are consuming the > event in the parent form , you need to actually expose the event from the > user control using the "Public Event eventname()", and "RaiseEvent > eventname()" statements. Otherwise, the events will be handled by the > userControl. Which is fine if that is what you want... The latter is exactly what I want. The parent form needn't be concerned by what happens in the UC, which handles the events raised by its constituent controls. (Or at least, that's what I intended would happen.)
Lance Wynn - 29 Jun 2007 15:46 GMT ok, What code do you currently have in the onClick event of the PictureBox? Also, double check that the name of the event matches the name of the component on the UC. If you have changed the name of the control, you will also need to change the event handler's name.
Lance
>> hmm, I've never seen anything like this before. >> How are you determining the events are not firing? [quoted text clipped - 9 lines] > what happens in the UC, which handles the events raised by its constituent > controls. (Or at least, that's what I intended would happen.) Andy - 29 Jun 2007 16:02 GMT > What code do you currently have in the onClick event of the PictureBox? Do you mean the Click event? I'm not concerned with the Click event - only the events I listed in my OP. (MouseDown, MouseMove, MouseUp, DragOver, DragDrop.)
> Also, double check that the name of the event matches the name of the > component on the UC. If you have changed the name of the control, you will > also need to change the event handler's name. Double-checked OK.
One more point which may or may not be relevant; the PictureBox is in fact contained inside another PictureBox. Its Left and Top properties (within the containing PictureBox) are set in response to moving the two scrollbars I spoke about before. I expect that is not relevant - since it's the way things were when these controls were hosted by a form rather than a PictureBox. Besides, the inner PictureBox's events are visible in the UC's code window, so clearly VB knows what I'm intending.
Lance Wynn - 29 Jun 2007 16:10 GMT My mistake, Post the code for the events you are interested in. I tested this scenario, and it worked just fine, so I assume there is something else at work here.
>> What code do you currently have in the onClick event of the PictureBox? > Do you mean the Click event? I'm not concerned with the Click event - [quoted text clipped - 18 lines] > UC's > code window, so clearly VB knows what I'm intending. Andy - 29 Jun 2007 16:26 GMT > Post the code for the events you are interested in. If I do that, it just isn't going to work on your machine without a fair bit of work (configuring a database in SQL Server, installing some middleware, and a fair few other modules from the UI of this application). A couple of days work, I would say.
Is the code really relevant? I start the app. with Ctrl+F5, and VB would tell me if there's anything wrong with the code. The problem here is certainly associated with the property settings of the UC and its constituent controls, rather than the code. I already ascertained that VB doesn't even attempt to run the code, therefore the controls aren't seeing the mouse events.
By the way - the UC is sited on its host form dynamically at run-time. I wouldn't think that's the cause of the problem, though. As I said earlier, the scrollbars are responding OK. What's different about a PictureBox? (OK, there's a lot different - including the fact that it has the 3 Mouse events which a scrollbar doesn't.)
Lance Wynn - 29 Jun 2007 16:55 GMT Then what you will need to do is create a new project, and work to get the event to fire. Once you can get the event firing in a clean project, then you can work backward and find out what is different between the good project, and the bad project. Without seeing some code, there is nothing I can say other then "it works on my machine, and I can't duplicate the symptoms you are seeing.
>> Post the code for the events you are interested in. > If I do that, it just isn't going to work on your machine without a fair [quoted text clipped - 21 lines] > events > which a scrollbar doesn't.) Andy - 29 Jun 2007 17:12 GMT > Then what you will need to do is create a new project, and work to get the > event to fire. Perhaps I have no choice but to follow this advice.
> Once you can get the event firing in a clean project, then > you can work backward and find out what is different between the good > project, and the bad project. Without seeing some code, there is nothing I > can say other then "it works on my machine, and I can't duplicate the > symptoms you are seeing. I really don't see why it is necessary to see code. VB is more than just code - the successful implementation of an application depends on correct control properties as well. As I said before - mine is not even getting to the point where it tries to execute the event handlers, so what's the point in seeing the code I've put into them?
Karl E. Peterson - 29 Jun 2007 18:38 GMT > I really don't see why it is necessary to see code. VB is more than just > code - the successful implementation of an application depends on correct > control properties as well. As I said before - mine is not even getting to > the point where it tries to execute the event handlers, so what's the point > in seeing the code I've put into them? I understand what you're saying, but... There _are_ interactions that are not always obvious or intuitive. Lots of us have been bitten so hard so many times, that we now know to suspect "something odd" when we hear of a situation like this. On the surface, what you describe *should* work. No argument. So why isn't it? No way to know, really, without a good repro case. Your task, then, is to build the *simplest* repro you can. At that point, it becomes diagnosable. Otherwise, "works here" is probably the best you can hope to hear.
Sorry...
 Signature .NET: It's About Trust! http://vfred.mvps.org
Lance Wynn - 29 Jun 2007 19:16 GMT One thing you might try also, is to set a break point in the initialize event of the user control. Upon hitting the break point, press f8 until it exits the sub. This will cause the IDE to break on the next event that is triggered. Then click on the picture box and see where/if the code breaks. I'm just grasping at straws, without more information, it's hard to say what is happening.
>> Then what you will need to do is create a new project, and work to get >> the [quoted text clipped - 14 lines] > point > in seeing the code I've put into them?
|
|
|