Enhancements (Full Version)

All Forums >> [Product Forums] >> [Productivity Software] >> Calendar Creator (2016 Release)


ChuckWhite -> Enhancements (4/23/2017 10:54:05 AM)

Jason Carver, I have started a new thread to handle your request for enhancements to bring back many of the features we grew to know and love in v12. VTMangum69 and I have already touched on one but I'll try to expand on it a little.

Bring back the ability to format a category and have it apply to all events within that category. For example, I want all my US Holidays to have a red font and be left-justified. Currently, I have to go into each US Holiday event and change the font to red and left-justified. In v12, I only had to edit and format the category once and all of the associated events were changed. I would suggest enabling a right-click of the category and the current format screen be made available. Any changes made would apply to all events within that category; both existing and new.

Further, I would like to be able to go into each individual event and override the general formatting I have applied. Using my previous example, I would like to be able to format the Independence Day event to be in a red font and left-justified (from my general formatting) and include a picture of the American flag (from my specific formatting). The picture would only apply to that one, specific event.


ChuckWhite -> RE: Enhancements (4/23/2017 11:15:46 AM)

Another enhancement I would like to see (or at least I haven't been able to find) is what I will call a generic calendar template without regard to a specific date or date range. In v12, I was able to create a "generic" daily calendar. When I open that "generic" daily calendar today, it would populate and display all the attributes and events associate with today. If I opened the same "generic" calendar tomorrow, it would populate and display all the attributes and events associated with tomorrow. The same holds true with all the other calendar types (weekly, monthly, etc.) The default date is the system date. Currently, I am only able to create a calendar for a specific date or date range and if I open it tomorrow or next week, it only shows the events associated with that specific date for which the calendar was initially created. At least, that is all I have been able to find.

Additionally, on the menu bar in v12 are buttons to allow the date to be moved forward, backward, or to a specific date. The right arrow moves the date forward one time period (daily if a daily calendar is displayed, weekly if a weekly calendar is displayed, etc.) The left arrow moves the date backward one time period. A calendar icon brings up a calendar on which you can specify a particular date. The displayed calendar is then populated with the associated events for that date or date range.

Using v12, I currently create one "generic" weekly calendar and then use it to print 52 individual, specific, weekly calendars for my appointment book. As I add, change, or delete events, I print the appropriate weekly calendar (which could be several weeks in advance); all using my one "generic" weekly calendar. In the new, 2016 version, I have to create 52 individual, specific calendars to accomplish the same thing.


JasonC -> RE: Enhancements (4/23/2017 1:52:04 PM)

Great feedback, It's very detailed and will give our developers a good idea of what our CC users want. I appreciate you taking the time to let us know what you think and will make sure that it gets submitted.

ChuckWhite -> RE: Enhancements (4/23/2017 3:09:59 PM)

Thanks, Jason. The program just crashed and I can't get it working. I've reported it to Tech Support and I'm awaiting their reply. As I've just started using the new version yesterday, I'm sure I'll be running into more "enhancements" (I know of at least one dealing with printing) but that will have to wait until I am able to get back into the program.


JasonC -> RE: Enhancements (4/23/2017 9:17:24 PM)

I sent you an email through the email function on the forums with some additional information. Please check when you have a chance. Thank you [:)]

TVMangum69 -> RE: Enhancements (4/23/2017 9:45:36 PM)

I agree with everything that ChuckWhite has to say on enhancements. "If it ain't broke, don't fix it."

brianholland -> RE: Enhancements (4/27/2017 1:12:43 PM)

I have not used the previous versions and am coming from a different product. The documentation was limited, so either I missed stuff or the features do not currently exist. If I missed something that is already there whether it was obvious and I missed it or there is some undocumented way, I would be glad to know. I am looking at this to replace the previous program my wife was using that was Windows only. Her next upgrade may be a Mac. She makes calendars every year for Christmas presents with personalized photos and dates per person. I apologize if these are currently supported and I missed how to do them.

The following features would be useful, if they do not already exist:

1) Event dates that ignore year. - Birthdays, anniversaries, and such do not care about year. While the program allowed a repeating event, it wanted an end date as far as I could tell. It would only repeat until then. When exporting the events, it has one entry per year. I tried altering an event line to remove the date by hand, tried 0000 as the year, and tried '*' as the year. None of those worked when importing. This would be a nice feature to have where some events would go into every year. Without it, it requires either multiple entries (one per year) or modifying the events every year. Global search and replace is tricky as only certain dates are yearly. I guess I could use priority or another field to indicate that they are year agnostic and then do more complicated replace. There is already support for ignoring time.

2) "Create a basic calendar" would be nice to allow a year to be specified. -- At least I saw no way to put in next year's date. Yes, once creating a calendar that has dates for this year, you can go to each month and alter the year, but it would be nice to pick a year to entered when picking a "Month Calendar # Landscape" calendar. That would really make the creation of next year's calendar easier.

Both of these seem reasonably simple to implement, if not already present.

Brian Holland

ellengard -> RE: Enhancements (4/27/2017 8:54:52 PM)


ORIGINAL: brianholland
...She makes calendars every year for Christmas presents with personalized photos and dates per person.

CC2016 is very well suited for this purpose.


While the program allowed a repeating event, it wanted an end date as far as I could tell. It would only repeat until then.

This is the way it is supposed to work. Put an end date 30 years in the future. You probably will replace your computer several times before you need to "update" a birthday or anniversary.

brianholland -> RE: Enhancements (4/27/2017 10:36:49 PM)


ORIGINAL: ellengard


ORIGINAL: brianholland
...She makes calendars every year for Christmas presents with personalized photos and dates per person.

CC2016 is very well suited for this purpose.

It is similar to what she used before, so it seemed fine for what she did. I played with it enough to see that it seems to do most of what we want and everything that we really have to have.



While the program allowed a repeating event, it wanted an end date as far as I could tell. It would only repeat until then.

This is the way it is supposed to work. Put an end date 30 years in the future. You probably will replace your computer several times before you need to "update" a birthday or anniversary.

I figured that is how it was expected to support it as some computer event calendars have the same model of having to state the number of times to repeat. It just is not as clean as I would like. Yeah, 30 years is more than enough, but I like to deal with the CSV files and the multiple lines just makes it messy to see on one screen all of the events that are included. Without looking at the events carefully, it may not be obvious that the end date was not extended enough when first creating the event until someday it gets noticed that it isn't on a calendar. The suggestion above just makes those files cleaner and there are several different types of programs that have a notation to support it simpler. (E.g., cron from UNIX/LINUX) Personally, I will just likely write a script if we use this program to generate each event file for a person with the year from templates for the every year events for each person and then merge in ones for year specific dates. She is already going to have an event file for each person's calendar for yearly events. ANWAYS, THIS IS A MINOR ISSUE FOR ME AND NOT ONE THAT WOULD LIKELY MAKE US STAY WITH THE PREVIOUS PROGRAM. It was just a suggestion to make it cleaner.


The workaround I mentioned on the other suggestion of changing the year for each month by hand is fine too. The suggestion was also just to make it simpler. In fact, for us only a couple of her calendars (the late ones) are done in the year that they are for. Most are done in the previous year prior to the holidays. That one would save more time than the birthday one.

Neither was major, just "nice to haves" and not necessary. I just figured that I would suggest them as sometimes some of the simple improvements just add up in users' experiences.

Thanks for the reply,

JasonC -> RE: Enhancements (5/1/2017 12:10:28 PM)

These are all great suggestions that I will make sure gets passed on.

brianholland -> RE: Enhancements (5/10/2017 2:14:58 PM)

I finally got a chance to play with the program again. I am trying to replicate things that my wife does when making her calendar gifts. I hope to satisfy her that this program will do everything she is used to doing.

I noticed a couple issues. I will enter in separate messages. They all have to do with export/import of calendar events. The first, I would categorize as a but as it breaks stuff. It wasn't clear where to put possible bugs, but there are enhancements that could fix it.

The program allows adding line breaks in events. (My wife used this feature to leave room for some clip art in her old program)

The issue is that when you export events where there is at least one with a user-entered line break in the title, the file errors on importing. At that point, the exported calendar events are useless without editing by hand to clean it up.

I suspected that the code is reading a line and therefore only seeing part of an entry. I did check commas in the title and those worked fine. They were done inside quotes and still on the same physical line. While the line break was in quotes, it was on two lines, so points to likely reading a line expecting a whole entry.

Some possible ways to address:

- Replace new lines with space on export (won't preserve the original event perfectly, but import would work)
- Disallow user to enter line breaks in text (if users are using this, they won't be happy)
- More complex reading and parsing.
- Do some escaping of the line break on export. Undo the escape on import. (Oh, and of course escape the escape character if the user can enter that too)

The last may be easiest without affecting the user depending on what the code looks like.

Brian Holland

brianholland -> RE: Enhancements (5/10/2017 2:24:10 PM)

Event attributes do not survive an export/import. (E.g., color). This requires users to go and adjust them after importing. I don't know if the event format is a standard used by other programs. If so, there may not be a way to encode it.

Suggestions to support it:

- Add optional columns with the appropriate information.
- Encode in existing column (possibly notes), if this format is to interface with other programs.
- Allow additional export format that records all the even information such that it can restore them fully.

Brian Holland

brianholland -> RE: Enhancements (5/10/2017 2:56:47 PM)

In playing with the program, I noticed the event macros '&birthday' and such. [:)] That is a really nice feature. Some of the two dozen plus calendar gifts my wife makes includes the birthday number. I tried it out and it did require me to use the repeated entry. (The sample one of hers that I looked at was at 70th birthday for 2017). I made a repeated event to test this out and for a few years to come and it worked great.

However, export and import of the events for that person's calendar did not work so great. As expected, it put out 70+ lines in the CSV file. Ignoring my distaste for those repeats, I did the import. They are now 70+ individual events in the program. Each with only ONE date. That meant that the starting date is the date it is set for (E.g., 2017 for this year). When it goes to calculate the number of the birthday, it returns 'Day of Birth' instead of the "70th Birthday" that it did prior to export.

Suggestion would be to support preservation of the effect of these macros over export/import.

Some possible ways:
- Expand macros to text on export (At least text would be correct, but no way to simply adjust the end year or change the name (E.g., marriage) in a single entry. Plus, the multiple entries on import really makes scrolling through entries to find one a pain.)
- Encode the repeating information in existing or new field as previous suggestion.
- Have alternate export format to keep this event as a single entry with all the dates as entered so that the import results in the entry as entered.

The last two should cause an import to replicate the entry as it was entered. If this is done for all event fields, then this would address the font attributes also.

If the import / export keeps a event with repeats as a single entry in the export file and after importing again, the 'end year' seems perfectly reasonable to me and easy to manage external to Calendar Creator.

Brian Holland

DEJenc3 -> RE: Enhancements (5/10/2017 8:54:48 PM)


You raised some good concerns about importing calendar data. Without going into how imports work specifically with Calendar Creator 2016, I can tell you that the behaviors you describe are all, or nearly all, the same as in importing data into Calendar Creator 12.1 and earlier. These sound like typical data exchange roadblocks and limitations in many software programs.

Birthdays must be set up as repeating events, as you've found. Entering an end date many years in advance is the correct way to manage birthdays and anniversary-type dates. There is no universal code to manage the many possible complex repeat scenarios, and exporting repeat events will treat each occurrence as a unique event. Likewise, importing these will import only the events that were exported, and will not create a new "repeat" event. You'll have to manage that after the import.

Similarly, formatting code doesn't carry over on imports, since the exported data almost always consists only of text fields. It's possible that you can deal with some formatting using Categories after the import. Import and export features are normally designed to exchange basic information exported from various software programs or sources created in table form. It's very common to have to tweak data before and/or after a planned export or import.

I can't say that the specifics you're suggesting are impossible, but merely that most are not likely to move data comfortably from the earlier Calendar Creator programs, or from any other program, into Calendar Creator 2016. Mostly you'll need to make do with the basic date and event information to be imported, and this is probably going to be true with any calendar program, standalone or online.

When planning, pay attention to data consistency. That may be a problem with your fields with more than one line feed.. Normally those should be cleaned up before importing.

My comments may or may not help with your concerns, but are observations from having worked with databases and Calendar Creator 12.1.

Thank you for your posts, since I know your issues have been or will be concerns for other users, and some of the users may respond with their experience and possibly workaround options.

brianholland -> RE: Enhancements (5/10/2017 11:31:32 PM)

Thanks for confirming that the current output format is for exchanging data with other programs. I figured that was likely, but was not totally sure. That invalidates my suggestions of adding addition information to the current file whether in existing fields or in extra fields.

I recognize that the current output format is limited and that the import is limited, but at least the two cases below should be considered bugs. It is likely that the two cases below were not looked at when first creating and testing the export/import code. I find them buggy as CC is incompatible with itself. (I understand there will be multiple entries when re-importing with the current CSV format, but the text should at least be accurate and the import should succeed.

There are two parts of this:

a) REALLY SHOULD BE DONE : The two issues below should be addressed (potential approach mentioned) so that the text is intact and the import will succeed when importing back into CC.
b) SUGGESTED NEW FEATURE: Support a 2nd CC-specific format for events. This would only be useful for importing back into CC when juggling multiple different event sets. Have it retain raw event data and recreate the events.

Here are the two that I believe should be considered a bug and addressed when exporting using the current CSV format.

1) Exporting a title that contains line break creates a CSV file that CC cannot properly import. In my tests, this stopped any of my events from being imported back into CC, even ones with no line breaks that were in the same export. I did not try all combinations so I don't know if it was the whole file that was ignored or only events once the first entry with an embedded line break was encountered. Replacing line breaks with spaces during export would make the text correct and allow it to be imported back into CC. If entries with embedded line breaks are actually legal in that format, then CC is not reading it correctly. No program should create an export file that it cannot import itself. There may be incompatibilities with other programs that do not meet the standard, but a program should be consistent with itself. CC currently creates exports that it cannot import.

2) Having "Joe Smith 70th Birthday" before export (setting the start day as day born and repeating yearly) turn into "Joe Smith Day of Birth" after re-import. This should be considered a bug. Losing style information is one thing, but a program should at least be able to import data that it exported to be useful, even if not in the same internal format. The one option I gave was to do the macro substitution as each individual output event is made for the CSV file. That would result in the entries in the file at least being accurate for display if imported back into CC or imported into another program. Currently, the data to do the calculations is lost on creation of the current CSV file, so it needs to be handled during output. I am glad I tested this out as my wife would have been unhappy with me if she entered all the events and found out that when doing the next year's calendar that they all changed to "Day of Birth" . So the whole repeating event was not useful when doing exports (whether for CC or another program to use) because each of the 80 resulting entries had "Joe Smith &birthday", which after importing resulted in into CC end up being 80 entries of "Joe Smith Day of Birth" rather than "Joe Smith 1st Birthday" through "Joe Smith 80th Birthday". That same data imported into any other program would show as "Joe Smith &birthday" as they would not understand CC's macro. For any data to be exported for intended exchange to other programs, all program-specific data such as CC's macros should be replaces with real text to be displayed and not the CC-specific macros.

The above two changes would at least allow the data to be re-imported into CC in a meaningful way (even if not in a nice single entry) AND also allow the data to be useful when imported to other programs.

I can generate the exported dump files (for #1 and #2) and post them on GitHub or such if I am not explaining it clearly, so that the issues with the resulting imports can be seen.

Our use case may be atypical, but I suspect some could make use of the suggested feature of a CC-specific dump format IN ADDITION TO the current one being used for exchanging data. We don't expect to export to other programs or import from other programs. We want to save sets of events generated in CC for later use in CC. That is why a 2nd raw dump format would meet our needs. If it contained all the fields in the entered event, it would also address the saving of style information. Without that capability, she will likely not use the event mechanism and just paste text and image blocks on days as they are specific per gift.

Note: For me, I might just have to write the script that I mentioned before to generate a CVS file per person per year to be imported from other input files (format that I would create). Without that or supporting real dumps of events, I doubt that I can convince her to use the events when they are potentially so powerful.

Brian Holland

DEJenc3 -> RE: Enhancements (5/11/2017 12:41:23 AM)

I have no issue with the desirability of your suggestions, and I'd like to see some of these implemented. A few comments:


1) Exporting a title that contains line break creates a CSV file that CC cannot properly import...

Once a field creates an issue that the importing program can't resolve, it may terminate the entire import. This could be the multiple line feeds, or an empty field in a critical location such as the first record to be imported. You clearly know your way around data import, and could experiment with a small sample file, completely filled, to import to see when vacant or unusually-formatted fields cause it to fail. Unfortunately, trouble-shooting imports is tedious, at least in my experience.


2) Having "Joe Smith 70th Birthday" before export....

I don't know how practical it would be to implement this, although I can see where the basic data (&birthday) is separate from what the program does with the data when creating or printing a calendar. Exporting it in an output format, like database reports that can process data manipulation, would be a new level of export for Calendar Creator, but your suggestion deserves to be considered.


b) SUGGESTED NEW FEATURE: Support a 2nd CC-specific format for events....

I like this: An export in a CC-specific format for events is also a good one to the extent that it's practical. However, it may already exist in another manner via saving a Calendar Creator project, and importing the project into another one. This exists in Calendar Creator 12.1, and may also exist in 2016 (I can't check for now).

brianholland -> RE: Enhancements (5/11/2017 3:16:53 PM)

Sorry for mixing discussion of bugs with requested features (even if related). Is there a better place to discuss issues or would these be considered enhancements in the CSV export/import?


However, it may already exist in another manner via saving a Calendar Creator project, and importing the project into another one. This exists in Calendar Creator 12.1, and may also exist in 2016 (I can't check for now).

Thanks for the idea. I just tried and it did not work for me. Here is what I did:

Added some events.
Saved the calendar.
Closed the project.
Cleared the events.
Opened the calendar.

The result was that the old events no longer existed. Well, it was a bit weird. The side panel showing the page previews showed what appeared to be events on the following pages, but when I clicked to them, they were not there and the tiny text for the event in the preview panel disappeared for that month. It is like it used a preview that was saved for the project, but when displaying the full month re-published the page and updated the preview panel. After Opening the calendar, I did checked the "Show event listing" icon and none of the events that were present when I saved the calendar were there, so it looked like those are not exported with the project. I was hopeful at least. If there is a different way to restore it I will try that too.

Note: Test above may be invalid due to state of my system. The tests yesterday may have messed up the database. I created a month landscape basic calendar and tried to enter events like I did yesterday, they properly showed up in the event listing, but did not display on January 2017. But, ones for other months showed up fine. I did get them to show for January 2017 by double clicking the January calendar to show the "Calendar Properties" popup and hit "OK" without changing anything. It then showed them properly. I closed out and tried again with the same results. I uninstalled and reinstalled trying to clear everything, but got the same results. In fact, I had added a category of "Bob" yesterday and it was there after I reinstalled, so some data file or registry keys persisted. I did not check the whole system. The only directory that I noticed CC storing stuff in so far was "Documents/Calendar Creator" and that was where calendar projects were saved. Any idea where CC stores additional data such as events and such so I can clear that out?


You clearly know your way around data import, and could experiment with a small sample file, completely filled, to import to see when vacant or unusually-formatted fields cause it to fail.

I have been coding and using computers since 1973 so have seen a lot of these things. So far, for the issues that I described, I have only entered data in the event popup and exported to get the file that I would then import after clearing the event list. I could tweak the output files to help determine the exact conditions that cause the import to fail if I get my program state back to like it was before yesterday if it would be useful. But, if line breaks should not be there, best to filter them out when creating the CSV file or other programs are likely to have a similar import issue. CC import could be made more robust in case other programs output similar issues to the line break one that CC currently exports. For CSV, that can be done by just ignoring lines that are not valid and reading the next line. (If so, it would be good to report to the user the number of lines that were ignored.)


DEJenc3 -> RE: Enhancements (5/11/2017 10:47:55 PM)

I have no idea what could have caused the contents of your calendar project to disappear, but it has to have been some kind of glitch.

As far as I know, Calendar Creator stores its event data for a project entirely within the calendar project file (*.scc). Categories and other features that could apply to any project may be another matter.

I checked my installation of Calendar Creator 2016, and it appears to me that it does NOT allow importing from another CC 2016 project in the way CC12 did from other CC12 projects, so that invalidates the suggestion I offered earlier. In my test, it can only import from standard exported data such as .csv and .txt. I suppose this could be considered an enhancement request.

If you plan to uninstall Calendar Creator for the purposes of reinstalling, you'll want to follow the full uninstall directions provided on the Encore support site. I THINK that would eliminate the reappearance of the custom Category you created, but I'm never surprised at what ends up buried in the Windows Registry, and it may still reappear.


Is there a better place to discuss issues or would these be considered enhancements in the CSV export/import?

For now, you might continue to post your issues in this thread to the extent that they relate in some way to improvements or enhancements to the program. In time, Encore may add feature-related forums as they have for the longer-established programs.

brianholland -> RE: Enhancements (5/15/2017 2:09:26 PM)

I got a chance to do some more black-box testing on event handling. I did a new install on my Mac laptop to avoid the one issue that started happening on my wife's PC install after some of the failed imports. From the testing it looks as if events are being handled in a way that many will like, but is not what is useful for my wife and her multiple sets of dates. Opening a calendar did not result in events that existed at the time the calendar was saved from being added or merged to what the program already has.

The program appears to have a single internal set of events, it ignored any events that were saved in the calendar. This is great for those who add new events and then bring up one of their other calendars and expect the date to be there too. They don't have to enter it multiple times.

I had hope that the events came from the saved calendars because, with no calendar up the Event List icon is not useable. But, when creating a new calendar (or opening an existing calendar) I ended up with whatever events were last present when the program was closed (whether anything was intentionally saved or not).


1) Create a new calendar, add an event on Jan 1 and save as cal1.
2) Close program and reopen (to be as really clean).
3) Create a new calendar. It has the Jan 1 event as soon as created. Add one for Jan 2 and save as cal2.
4) Close program and reopen.
5) Open up cal1. It now has both the one that existed when it was saved and also the one that was added for cal2.
6) Close program and reopen.
7) Create new calendar, it has both events. Delete both events. Close program WITHOUT saving.
8) Open program and open cal1. It now has no events (on calendar or in event list).

If #8 had both what was last in the program and what was saved in the calendar (merged), then we could have used this to save a set and then wipe out all internal events to open a saved calendar and get its events as a starting point for that person's calendar for the next year.

So the event list seems to be internal. You can edit or import a CSV file to add to it. But, it appears to be the only thing used when editing a calendar.

So unless there is some way I am missing to bring in the calendar such that stored events come in with it, we cannot use a saved calendar to store a set of events.

So, I am still hoping that some way to save event sets (all raw data including repeat info and styling) is added at some point in the future.


Page: [1]

Valid CSS!

Forum Software © ASPPlayground.NET Advanced Edition 2.4