Unable to use more than 1 instance of calendar with mouse event handlers on the same page

[talkonadmin]

I am initiating several calendar instances (QCalendarDay and QCalendarAgenda) on different components.
It seems that mouse event handlers defined in 1 component overrun those of the others, making this usage scenario not usable.
I debugged this issue and examined the code and noticed that useMouse composable included a global $listeners variable that is getting overrun by each initiation of a calendar instance. This is the reason why event handlers stopped working on one of my calendar instances. After disabling all but 1, mouse event handlers started to work.

[mfcarneiro]

Hey! I'm facing the same problem for months.

Any tips on how you have disabled? I have two instances of the QCalendarDay that I need to work with (the main calendar and the filter)

Whenever the filter containing the QCalendarDay, in mini-mode opens, the click-time just died and I need to reload or change the current route, to have the events available again on my main Calendar component

[talkonadmin]

In my case I needed only 1 calendar at a time so I used v-if condition to render only 1 (before it was using css display). it will not work in your case since you need both at the same time.

[mfcarneiro]

yea, since then I've discovered this issue, I'm trying to figure out how to get both working together

(after opening my filter (QCalendar), inside of a QDialog, closing and selecting another time in the main Calendar component)

[talkonadmin]

I would use a different component for the filter e.g qdate

[FCardeira]

I've also faced this problem recently. Any solutions? I'm using QCalendarMonth as a date picker and using QDate or any other similar component wouldn't be a wise solution in my case, especially because I like what I can do with QCalendar to make a fully custom date picker.

[mfcarneiro]

@FCardeira Nope, I'm considering other Calendar solution like SyncFusion (waiting them migrate to Vue 3).
This solution to use QDate does not fit to my needs too, unfortunately.

[danielwillms]

I am stumbling over this same issue right now.
I also use the QCalendarMonth as a date picker (like this), but trying to create an example on codepen made me notice, that this isn't a problem in the UMD version.
Using the same layout with the npm version doesn't work though. All click-listeners on the first rendered calendar (month) are now completely ignored.
When removing the second calendar everything works as expected!

[Jens2]

Does anyone know whether this may ever be resolved? I actually have to use two separate QCalendars next to each other, each with their own data, so I actually need to be able to distinguish editing events in one or the other on the same page.
If this won't be resolved, I'll have to figure out another way.

[flowt-au]

+1

[Jens2]

Does anyone know whether this may ever be resolved? I actually have to use two separate QCalendars next to each other, each with their own data, so I actually need to be able to distinguish editing events in one or the other on the same page. If this won't be resolved, I'll have to figure out another way.

I came up with a workaround, since the events did fire from both calendars, they just both came from the component that contained the calendar which was last to render. So, say I wanted to add an event in the left calendar and clicked there, the event fired with the correct time and date from the component that contained the correct calendar, but it was being handled by the component that contained the wrong calendar.

My solution was to give both calendars different id's (for ex. id="left" and id="right"), then I can use the MouseEvent that fired to recursively iterate through the .target attributes, whilst checking for which id eventually came up as the correct parent element. I hope this may help someone with similar issues!

[danielwillms]

For everyone with the same problem:
I created a PR, which resolves this problem (in the next branch atleast).
Problem was, that the composable for the mouse events was using global variables for emits/listeners, which were overwritten when a new calendar was created.

#442