Client is running Dayback 9.65. Old version, but it is what it is.

At some point we hid the Calendar selector in the web viewer popover. Now they need it back.

Hunted through the CSS for the code that is supposed to hide it but was unable to find it.

Is there someplace else that the Calendar selector is toggled in the older version?

Hi dzakary,

The CSS code that you are looking for should be: .panel-selector[name=calendar] {display: none;}

If you have not made any other major modifications to the CSS, it may also be worthwhile to restore the built-in themes, and see if that cleans it up for you.

Let us know if this works for you!

Ann

alksmokey wrote:Hi dzakary,

The CSS code that you are looking for should be: .panel-selector[name=calendar] {display: none;}

If you have not made any other major modifications to the CSS, it may also be worthwhile to restore the built-in themes, and see if that cleans it up for you.

Let us know if this works for you!

Ann

That's what I had looked for in the CSS and it wasn't found. I tried restoring the built-in theme and while it brought back a couple of other things I had disabled, the Calendar picker wasn't one of them. Was wondering if its due to the older version of DayBack.

Is it possible to add that in manually? If so, what's the syntax for the CSS to add?

I copied the theme CSS from DayBack and have attached it.

Thanks.

Dave Zakary

Thanks Dave. We'll take a look at this early next week for you, and get an answer for you! Have a great weekend.

Ann

alksmokey wrote:Thanks Dave. We'll take a look at this early next week for you, and get an answer for you! Have a great weekend.

Ann

Thanks. You too.

Hi Dave,

When you mention the calendar selector in the popover, are you referring to the "Start" or "End" times in the event popover, or the minical date selector in the sidebar?

The minical date selector in the sidebar should show under an icon of a house in the top left of the sidebar. I've verified that your CSS shouldn't be hiding this.

If you're referring to the start and end date/time options in the event popover, these items are hidden in the "Load Source Settings at Startup..." script under the section commented "# Hide popover items?". We're setting the variable $$sc_HidePopoverItems to a list of items to hide. You can remove "start" or "end" from that list to restore them to your popover.

Let me know if that helps!

Thanks,

KC

kcembrey wrote:Hi Dave,

When you mention the calendar selector in the popover, are you referring to the "Start" or "End" times in the event popover, or the minical date selector in the sidebar?

The minical date selector in the sidebar should show under an icon of a house in the top left of the sidebar. I've verified that your CSS shouldn't be hiding this.

If you're referring to the start and end date/time options in the event popover, these items are hidden in the "Load Source Settings at Startup..." script under the section commented "# Hide popover items?". We're setting the variable $$sc_HidePopoverItems to a list of items to hide. You can remove "start" or "end" from that list to restore them to your popover.

Let me know if that helps!

Thanks,

KC

Neither of those. We're adding an additional calendar to the system and want to be able to select which calendar the event goes in to. From the documentaiton it said that certain parts could be hidden via the Load Source script (which I've used for a couple things) and others via the CSS.

Thanks for the clarification, Dave.

The feature to change the source that the event is assigned to was added in build 9.74. With older versions of the calendar, the only way to create a new event on a specific source is to have that source be the first (or only) active source in the sidebar.

Now might be a great time to get your client's DayBack solution up to date. We've added a ton of new features since then, and we recently updated the way our in-app updates extensions work. Before, purchasing an extension would extend your in-app expiration date 1-year past your original expiration date, which many customers found confusing.

Extensions are now yearly subscriptions, so as soon as you sign-up, you'll be eligible for updates for a year from the current date. You can cancel the subscription at any time. In-App updates subscriptions can be purchased at this link: https://www.seedcode.com/extend-in-app-updates/

You'll still need to find some time to apply the in-app updates, then apply any required script updates, in order, as specified in our version history page here: https://www.seedcode.com/pmwiki/index.p ... ionHistory

You'll also have the option of starting over and re-integrating the calendar from scratch if you'd find that easier.

I hope that helps!

Regards,

KC

kcembrey wrote:Thanks for the clarification, Dave.

The feature to change the source that the event is assigned to was added in build 9.74. With older versions of the calendar, the only way to create a new event on a specific source is to have that source be the first (or only) active source in the sidebar.

Now might be a great time to get your client's DayBack solution up to date. We've added a ton of new features since then, and we recently updated the way our in-app updates extensions work. Before, purchasing an extension would extend your in-app expiration date 1-year past your original expiration date, which many customers found confusing.

Extensions are now yearly subscriptions, so as soon as you sign-up, you'll be eligible for updates for a year from the current date. You can cancel the subscription at any time. In-App updates subscriptions can be purchased at this link: https://www.seedcode.com/extend-in-app-updates/

You'll still need to find some time to apply the in-app updates, then apply any required script updates, in order, as specified in our version history page here: https://www.seedcode.com/pmwiki/index.p ... ionHistory

You'll also have the option of starting over and re-integrating the calendar from scratch if you'd find that easier.

I hope that helps!

Regards,

KC

One more question - If I try to do all of the updates, some are automatic and there are a lot of script updates to be done manually. When I click the Check for Updates button DayBack wants to go straight to 10.24. Is that going to be safe to do?

Can I go straight to 10.24 and then go back and start making my way through the script updates? Will that many updates start to step on each other while the manual changes are being made? DayBack has been integrated into this system. I'm not sure which way would be less painful - starting over or trying to update everything.

Hi Dave,

Correct, that's how the process is meant to work. The in-app updates will upgrade the core DayBack code to the latest version, then you'll need to apply all the necessary script updates. Since the required script updates won't be in there after you run the in-app updates, the calendar won't function correctly until you finish applying them.

If you've embedded DayBack into the main solution, you'll need to find a time when you can make sure the users aren't in the DayBack interface while you apply the script updates.

If you've just linked the calendar as a separate file, you can work on this in an offline copy, then replace the live DayBack file with your updated one.

Depending on how much customization you've done to DayBack, if you're able to replicate those customizations, it might be easier to start over with the integration process.

Let me know if that helps.

Thanks,

KC