MouseDown event not reaching control in nested container

I can’t figure out why the MouseDown event isn’t reaching a canvas control in a container when that container is nested in another container. The event reaches the handler if the container nesting doesn’t happen.

Here’s the design:
TimePicker is a derived class from a Canvas; TimePicker has a MouseDown handler, but isn’t receiving the event when the following arrangement is created.

TimePicker1 is placed in a TimeDigitPicker_Container (this container has no MouseDown handler)

TimeDigitPickerContainer1 (an instance of TimeDigitPicker_Container) is placed in ContainerTimePicks container (also has no MouseDown handler)

Observed behavior:

  1. Creating an instance of TimeDigitPicker_Container receives and handles the MouseDown event when the x,y of the mouse is in the TimePicker1 control area.

  2. Creating an instance of ContainerTimePicks doesn’t receive the MouseDown event when the x,y of the mouse is in the TimePicker1 control area (which of course is part of TimeDigitPickerContainer1 instance in ContainerTimePicks).

As far as I can tell all controls, containers are ‘Enabled’ as True.

Hi David,

Could you post a really simple example of this happening in a new test binary project showing how it works and doesn’t on the same window?

You can host the file on somewhere like dropbox and post the link to the file here as you can’t upload binaries.

We can perhaps see where the problem lies and assist you or sometimes the process of making the test project highlights the issue.

This will save us from mocking up the issue you describe above and possibly getting things wrong or missing things that could render any assistance incorrect.

Could you also let us know which xojo version you are using and on which OS and version?


1 Like

Hello, I’m sorry for the delay in responding.

Xojo version: 2023r1.1 on Windows 10

I have prepared a simple example that I will provide via dropbox.


First off, I can’t see the issue you’re seeing, neither canvas controls on my system are triggering the MouseDown event when I placed a break or a system.debuglog(currentmethodname) inside TimerPicker.MouseDown. This should be triggering, this triggers in a new project that is set up in a similar manner.

Secondly, the project seems corrupt, you’ve managed to make a window seem like a container control yet retain properties from the window (TimeDigitPicker_Container) which should not be possible (did you make this project in a older version of xojo?). For example, opening the inspector for TimeDigitPicker_Container shows “Has Close Button” “Has Maximize Button” etc. which shouldn’t be there if this was truly inherited from a DesktopContainer.

Thirdly, the menus aren’t enabling, probably due to the above and could be another indicator as to why the MouseDown events aren’t making it to the canvas controls. Your best bet would be to make a new demo project with brand new controls then copy just the code over from inside the events/methods etc so no corrupt controls make it across. When you have done this, test your new project to see if you have a similar issue. Start simple, you don’t need the majority of code/properties/methods etc, just the bare minimum to test out the MouseDown issue.

Failing all this, you could post this project to a new ticket and see if xojo get back to you with a cause as I would be interested to see what they say about it. I don’t know how long that might take though.

During my testing I encountered a state where my mouse stopped right clicking in navigator in the IDE, then another that would not allow me to copy/paste controls, then another which completely crashed the IDE when I ran the project, so I think something is up with the project in general.

This caught my interest and I’ve been poking around, but it was suggested to me that my previous post wasn’t as helpful as it could have been so I removed it.

I really appreciate your help on this as it has been a real struggle for me!

I have had a similar (playing with my head) experience where I put the control on the window, run it, seem to be handling mouse down events, stop and make some other code change, or just re-run it, and it’s not handling mouse events - what a way to mess with someone’s head :frowning:

I’ve been doing all the work on this in xojo 2023r1.1, but using some prior code likely dating back 5 or more years.

Here’s how I created the project that you received. First, I created a new xojo 2023r1.1 desktop project. Then I copy/pasted the classes/containers from another project that was also created initially in xojo 2023r1.1, BUT that project in turn had the classes/containers (copy/paste) that are the real substance (not any windows specifically though) from a very old project (2015?) that I pulled from github GitHub - mikecotrone/CalendarTimeChooser: Xojo Calendar and Time Chooser Picklist. And yes, the original github project was far out of date/broken for xojo 2023r1.1 so I’ve been updating to API 2 what I have been using out of it.

I am very motivated to get this understood and resolved, so I will try today your suggestion of a new project that recreates the classes using ‘insert’ (etc) and then only copy/paste blocks of code into the methods and event handlers. I’ll report back on where that took me. Thank you for your help!!

Thinking more, but I haven’t yet made the new project with ‘code text only’ copy/paste reuse, you may have hit on the crux of the problem that (and I’m relatively new to xojo but have 30 years of wide programming experience… VB, MFC, etc) that xojo made it seem ‘all-good’ that I could change super class from Canvas to DesktopCanvas or one container class (of old API) to new container class of API2, and then simply follow the compiler in changing event handler interface changes. But there probably was many more subtle xojo meta data under the covers that didn’t follow along. Probably going to be another one of those hard-won experiences that seasons one to a specific environment’s idiosyncrasies.

I will report back after the ‘fresh’ project is done.

You may wish to peruse this and similiar threads.

Thank you for pointing me to that link. I have read some on the API conversion experience since taking on development/maintenance of a large xojo app that started in 2010-11 timeframe and then languished for about 3 years (so it was barely xojo 2019 runnable). I had to become somewhat familiar with the API conversion just to get the app running again with xojo 2023r1.1, and in the process figured out the great idea of dual base classes deep in a class hierarchy being the original and a 2 or similar. But reading your link broadened my understanding of the scope of the perils/struggles with bringing a large xojo API1 app forward.

I can report now on the recreation of the project as advised. @anon20074439 you were on the right trail that something very strange happened on my way to exercising OO ideas with the existing code, primarily with the insertion of a base class in the DesktopContainer class hierarchy.

Xojo let me take an existing class derived directly from DesktopContainer (full disclosure originally from Container then changed to DesktopContainer), and change it’s Super to my new ‘container base class’ that was in turn derived from DesktopContainer.

To be clear on this, here’s what resulted and that I provided in project zip posted earlier:
TimeContainerBase has Super DesktopContainer
TimeDigitPicker_Container has Super TimeContainerBase

Looking at the files that resulted, and comparing them with the files resulting when I recreated the project from ‘scratch’ using the same class names and same ‘super’ choices is the following difference: with ‘fresh’ project on the left (yes that works as it should with the initial problem solved) and the project as I provided to you kind respondents on the right.

Further, once I recreated the project by first creating the TimeContainerBase with Super DesktopContainer, and then the TimeDigitPicker_Container as Super TimeContainerBase, I lost the layout editor expected for a container (no layout editor for TimeDigitPicker_Container specifically, I had a layout editor for TimeContainerBase, not helpful in my design).

Without the layout editor for TimeDigitPicker_Container, I couldn’t add the two controls (TimePicker and Time_Nav) at design time as I’d done in the old version of TimeDigitPicker_Container, really surprised me to face that!

This resulted in a new design for TimeDigitPicker_Container where I had to add and manage (the events) of those two control dynamically! Great info on that here Simplified: Adding User Interface Controls at Runtime

With code in the TimeDigitPicker_Container.Opening event as follows:

mControls.Add New TimePicker(0, 9, 82, 17)
mControls.Add New DesktopUpDownArrows()

Var TimePicker1 As DesktopUIControl = mControls(idxTimePicker1)
AddControl TimePicker1

Var Time_Nav As DesktopUpDownArrows = DesktopUpDownArrows(mControls(idxTime_Nav))

Time_Nav.Left = TimePicker1.Left + TimePicker1.Width
Time_Nav.Width = 12
Time_Nav.Height = 26

AddHandler Time_Nav.DownPressed, AddressOf HandleArrowsDownPressed
AddHandler Time_Nav.UpPressed, AddressOf HandleArrowsUpPressed
AddControl Time_Nav

It sounds like you created two classes then changed the Super on both, what you needed to do was:

  1. Create a class called TimeContainerBase with Super DesktopContainer
  2. Insert>Container, rename it to TimeDigitPicker_Container then change its Super to TimeContainerBase

That would then allow you to visually edit TimeDigitPicker_Container in the IDE.

However if you got it working the way you need, then its all good.

I’ll add a ticket about that corrupt project when I get a moment.

I think you’re right and that was what I must have done.

For some reason it seemed my only option, because insert->container was disabled somehow when I was ready to create the derived container, was to create the ‘base’ container, then when I went to create the ‘derived’ container, I seemed to not be able to create (via IDE cues) another container, and thus my only other option was a class (which then can never regain the IDE visual editing capability)… but I can’t reproduce that now so I’ll own that as my confusion and not the IDE preventing me from doing it the way you explained.

Thanks again for your help as I was quite stuck with the corrupt project!

1 Like