In a MonthView, to help the end user distinguish between "all day" events and intra day events, all day events get that as their full background. They appear as a solid block of their data-defined colour.
Non all-day events have their icon colour set to their data-defined colour and have no background-color (unless its the active event - then its set to a solid bar)
So this scheme actually conveys extra information to the end user at a glance.
You can change the background-color of non all day events using CSS:
This will leave the all day ones using their data-defined colour as their background-color.
To override this extra UI information that is being imparted via this difference, you could use !important on that, and also override the arrow colours on those all day events, so
thanks for your quick reply, @mats @Animal. now I am experiencing the trial expired issue, already raised a post:viewtopic.php?f=54&t=19295 will continue do testing after that.
Thanks for the extended action. @mats. for the color issue, I just realized maybe this is different scenario. the color is automatically changed to white when the event is clicked, as follow:
The style you apply in the eventRenderer is applied to the event bar outer element. And the DOM structure contains of multiple DOM nodes that might have style rules attached. So best to investigate the DOM node that specifies that white color and create a more specific CSS rule that does what you need.
Attachments
Screenshot 2021-10-30 at 10.23.50.png (164.79 KiB) Viewed 1032 times
So what you are planning to end up with is all events as a pale yellow bar regardless of whether they're all day events or not.
And no difference to identify the currently active event - the one that you just navigated to (Not everybody will be using a mouse to click to activate an event)
On both of these counts, an accessibility audit might bring up some points.