Using the following file with version d6607c512cf8c1083a9b5ec1efd7e1ccfb1832c8 I get a broken Excel file. How can I write multiple rows?

package main

import (
    "fmt"
    "github.com/tealeg/xlsx"
)

func main() {
    var file *xlsx.File
    var sheet *xlsx.Sheet
    var row *xlsx.Row
    var cell *xlsx.Cell
    var err error

    file = xlsx.NewFile()
    sheet = file.AddSheet("Sheet1")
    row = sheet.AddRow()
    cell = row.AddCell()
    cell.Value = "I am a cell!"

    row = sheet.AddRow()
    cell = row.AddCell()
    cell.Value = "I am a cell!"

    err = file.Save("MyXLSXFile.xlsx")

    if err != nil {
        fmt.Printf(err.Error())
    }
}

Excel 2013 is prone to give this warning: "We found a problem with some content in [generated file name.xlsx. Do you want us to try to recover as much as we can ?" But nothing appears to be broken - the generated data had made its way into the file.

I suspect this issue is due to the incomplete style information exported currently.

We originally had both custom column width and merge cell borders in this patch, but coincidentally someone else did a custom column width patch, so we had to deal with that conflict.

Problem

Reading structs from a row which has a well-known structure is a bit repetitive, because you will have to iter over the cells, check for the desired type to be obtained, checking for errors and filling the struct.

Current approach

If you want to read a whole file (or a single sheet) and convert it to a slice of structs, you have to take any of these two paths:

• Use FileToSlice iter over the slices and handle the type-casting for yourself
• Iter over the Sheets of the file, then over the rows and filling the structs by yourself

Proposal

Currently we have a method in *Row to Write a struct , so maybe we can define a symmetric method like (*Row).ReadStruct(interface{}) error that receives a struct pointer to be filled.

To know the relation column <-> field we can use struct tags that defines the index of the cell to be dumped in the field, like so:

type structTest struct {
	IntVal     int     `xlsx:"0"`
	StringVal  string  `xlsx:"1"`
	FloatVal   float64 `xlsx:"2"`
	IgnoredVal int     `xlsx:"-"`
	BoolVal    bool    `xlsx:"4"`
}

I'm wondering if would be better to use a name for the column, but I sincerely don't know how this would work.

I have a very simple implementation of the proposal using the tags in a forked repo:

Implementation commit

Comments are welcome!

This is not the issue by itself, the issue is that I HAVE to call Save() to properly close a file while I could be willing to discard it upon program interruption, for example with defer file.Close(). We need a proper function on the File struct to close it without saving.

https://github.com/tealeg/xlsx/commit/27f0f707d42799573616e9166c4be707dd4d2621 introduced a fix for merged cells AFAIK but introduced a regression which created borders styles with attribute empty string, which is not definition compliant. Value must be one of {'double', 'mediumDashDot', 'mediumDashDotDot', 'hair', 'dashDot', 'slantDashDot', 'medium', 'thick', 'mediumDashed', 'dashDotDot', 'thin', 'dotted', 'dashed'}

package main

import (
    "fmt"
    "github.com/tealeg/xlsx"
)

func main() {
    var file *xlsx.File
    var err error

    file, err = xlsx.OpenFile("/path/to/file.xlsx")
    err = file.Save("/path/to/anotherFile.xlsx")
    if err != nil {
        fmt.Printf(err.Error())
    }
}

The above code compiles and runs fine. It creates anotherFile.xlsx but when opening this file Excel application crashes.

Hi, I'm using the XLSX style, e.g Fill style in a Cell, I set cell.SetStyle(style) where style is fill := NewFill("solid", "#12CDD3", "#FFFFFF"); style.Fill = *fill, but it does not show any fill color in the generated XLSX file, Am I using the style the right way, what I was missing here? I set ApplyFill to true by the way. ;-) Thanks

The last release 1.0.3 was released in 2017, is there any plan to release a new version, like 1.0.4 or 1.1.0? There is a lot of commits merged to master since 2017.

my sheet is simple and based on the Write example. I only use those 4 or 5 methods. Absolutely nothing fancy. The Sheets can be opened with Excel, however, not consistently with Google Docs. Sorry Google does not provide an explanation.

I use Mac Office 2013 to generator a xlsx,and Use following code to edit xlsx file and open test2.xlsx, it tell me this file need repair.

func main() {
    file, err := xlsx.OpenFile("test.xlsx")
    if err != nil {
        log.Fatal(err)
    }

    sheet := file.Sheets[0]
    row := sheet.AddRow()
    row.AddCell().SetValue("12313131")
    err = file.Save("test2.xlsx")
    if err != nil {
        log.Fatal(err)
    }
}

CodeSee is a code visibility platform.

This change updates the CodeSee workflow file to the latest version for security, maintenance, and support improvements (see changelog below).

That workflow file:

• runs CodeSee's code analysis on every PR push and merge
• uploads that analysis to CodeSee.
• It does not transmit your code.

The code analysis is used to generate maps and insights about this codebase.

CodeSee workflow changelog:

• Improved security: Updates permission to be read-only.
• Improved future maintenance: Replaces the body of the workflow with a single github action: codesee-action. This makes it significantly easier for CodeSee to introduce future improvements and fixes without requiring another PR like this.
• Improved Python support: The action now properly supports Python 3.11, and will continue to support new Python versions as they are released.

1、rc, err := worksheetRelsFile.Open() in the makeHyperlinkTable function does not close the RC handle. As a result, resource leakage occurs. 2、In the readSheetsFromZipFile function, rc, err = f.Open() does not close the rc handle, causing resource leakage. 3、In the readSharedStringsFromZipFile function, rc, err = f.Open() does not close the rc handle, causing resource leakage. 4、In the readStylesFromZipFile function, rc, err = f.Open() does not close the rc handle, causing resource leakage. 5、In the readThemeFromZipFile function, rc, err = f.Open() does not close the rc handle, causing resource leakage. 6、In the readWorkbookRelationsFromZipFile function, rc, err = workbookRels.Open() does not close the rc handle, causing resource leakage.

In func (f *File) Save(path string) (err error), target.Close() must be after os.Create and before f.Write. Otherwise, resource leakage may occur if f.Write(target) fails to be closed.

The functions OpenReaderAt and OpenFile are added to prevent bomb attack (limiting the total number of files). The restrictions on the number of sheets, size of a single file, and size of the total file are added to prevent security attacks caused by opening files with high compression ratios.

I got a strange xlsx file from one of my clients. Content of some cells in this file cannot be accessed correctly. Instead, empty strings were returned.

However, v1 works corretly on this file. You can remove comments to see the difference.

Here's my testing code.

package main

import (
	"fmt"
	"github.com/tealeg/xlsx"
	xlsx_v3 "github.com/tealeg/xlsx/v3"
)

func GetRowCell(m map[string]int, row *xlsx.Row, index string) string {
	val, ok := m[index]
	if !ok {
		return ""
	}
	return row.Cells[val].Value
}

func GetRowCellV3(m map[string]int, row *xlsx_v3.Row, index string) string {
	val, ok := m[index]
	if !ok {
		return ""
	}
	return row.GetCell(val).Value
}

func main() {
	//file, err := xlsx.OpenFile("/path/to/issue.xlsx")
	file, err := xlsx_v3.OpenFile("/path/to/issue.xlsx")

	if err != nil {
		fmt.Println(err)
		return
	}

	sheet := file.Sheets[0]
	maxRow := sheet.MaxRow
	nameCol := map[string]int{"品牌名称": 8, "备案品名": 14}

	for i := 0; i < maxRow; i++ {
		//row := sheet.Row(i)
		//brandName := GetRowCell(nameCol, row, "品牌名称")
		//recordName := GetRowCell(nameCol, row, "备案品名")

		row, _ := sheet.Row(i)
		brandName := GetRowCellV3(nameCol, row, "品牌名称")
		recordName := GetRowCellV3(nameCol, row, "备案品名")

		fmt.Printf("BrandName：%v RecordName：%v\n", brandName, recordName)
	}
}

module version

• V1: v1.0.5
• V3: v3.2.3

issue file issue.xlsx