Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shortened heading text for unallocated projects with capacity to avoi… #9

Merged
merged 1 commit into from
May 19, 2024

Conversation

nicolasgold
Copy link
Contributor

This is a proposed minor bug-fix arising from something I noticed when informally helping someone install/use this excellent software on Windows.

The execution log (Windows and Linux) reports the following warning (in both test and real scenarios):
...openpyxl/workbook/child.py:99: UserWarning: Title is more than 31 characters. Some applications may not be able to read the file warnings.warn("Title is more than 31 characters. Some applications may not be able to read the file")

Whilst this doesn't cause LibreOffice Calc on Linux any problems (it just opens the result file as-created), when using Excel O365 on Windows and attempting to open the result file, an error dialog is shown:

We found a problem with some content in <file>. Do you want us to try to recover as much as we can? If you trust the source of this workbook, click Yes.

If one clicks "Yes", another dialog appears:

Repairs to<file>: Excel was able to open the file by repairing or removing unreadable content. Repaired Records: Worksheet properties from /xl/workbool.xml part (Workbook).

The resulting Excel sheet is then shown with the worksheet title Unallocated_projects_with_capacity truncated to Unallocated_projects_with_capac.

I have shortened the title in constants.py to less than 31 characters (Unalloc_projects_with_capacity). This eliminates both the execution log warning and the Excel corruption/repair sequence (tested on the ten test scenarios in the package).

Using a lightly-adapted (to allow the differently named worksheets to be compared) version of this xslx diff approach, I have checked that the remainder of the file contents from the revised version match those arising from the current master branch (aside from the run timestamp which differs as expected) in each of the ten test cases.

@RudolfCardinal RudolfCardinal merged commit a1b64b6 into RudolfCardinal:master May 19, 2024
RudolfCardinal added a commit that referenced this pull request May 19, 2024
@RudolfCardinal
Copy link
Owner

Many thanks, Nicolas! I've merged and bumped the version details accordingly.

@nicolasgold nicolasgold deleted the xlfix branch May 19, 2024 22:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants