kms писал(а) 16. Марта 2007 :: 13:35:Наверняка ты прав, хранение данных и сериализация - это CString.
Скорее, CArchive
. А MXL - это результат сериализации CSheetDoc (или чего-то в этом роде).
kms писал(а) 16. Марта 2007 :: 13:35:Вообще, формат mxl теперь отлично документирован.
Нет, пока не будет полного парсера, так говорить нельзя. И то некоторые детали могут ускользнуть.
kms писал(а) 16. Марта 2007 :: 13:35:Только не очень понятно, для ячейки:
class IMPORT_1C CSheetCell : public CSheetFormat
{
DECLARE_DYNCREATE(CSheetCell)
public:
CString csValue; // 0x24 ; сериализуется, если dwFlags & 0x80000000
CString csDescr; // 0x28 ; сериализуется, если dwFlags & 0x40000000
CString cs_2C; // 0x2C ; сериализуется, если dwFlags & 0x20000000
CByteArray ByteArray_30; // 0x30 ; сериализуется, если dwFlags & 0x00200000 и версия > 3
третий CString и ByteArray для чего могут использоваться?
может, где-то и встречается, но пока что-то не попадалось.
Может, это для таблиц в режиме ввода данных? Вообще, флаги похожи на флаги из MXL. У меня они пока выглядят так:
enum MoxcelCellFlags {
cfValue = 0x40000000,
cfText = 0x80000000,
cfPattern = 0x00010000,
cfPatternColor = 0x00020000,
cfControl = 0x00040000,
cfType = 0x00080000,
cfProtect = 0x00100000,
cfBorderBottom = 0x00000100,
cfPicturePrint = 0x00000100,
cfBorderColor = 0x00000200,
cfColumnPagePosition = 0x00000400,
cfColumnWidth = 0x00000800,
cfRowHeight = 0x00000400,
cfAlignH = 0x00001000,
cfAlignV = 0x00002000,
cfFontColor = 0x00004000,
cfBackground = 0x00008000,
cfFontName = 0x00000001,
cfFontSize = 0x00000002,
cfFontBold = 0x00000004,
cfFontItalic = 0x00000008,
cfFontUnderline = 0x00000010,
cfBorderLeft = 0x00000020,
cfPictureBorderStyle = 0x00000020,
cfBorderTop = 0x00000040,
cfPictureBorderWidth = 0x00000040,
cfBorderRight = 0x00000080,
cfPictureBorderColor = 0x00000080 // ??
};
Используются еще не все. Очевидно, здесь есть большие пробелы
kms писал(а) 17. Марта 2007 :: 11:52:По поводу торможения мокселя на объемных таблицах.
В реализации встречаются алгоритмы характера О(n) (надеюсь, что не хуже).
К примеру, хранение мержлиста (соответствий объединенных ячеек) реализовано через CList<RECT>.
При этом интересно, что общее хранение информации весьма неплохо сделано.
Незанятые ячейки памяти не занимают, а для хранения строк и ячеек применены алгоритмы характера O(log2(n)).
Так что рекомендация простая: поменьше объединений и побольше пустых строк и ячеек У меня для объединений тоже список используется. Только не CList, а std::list
. Вот только для ячеек у меня есть поле - ссылка на объединение, к которому ячейка принадлежит. Поэтому отрисовка листа с объединениями очень быстрая получилась - просто обходим строки видимых ячеек и попутно составляем список видимых объединений. Потом отрисовываем только видимые объединения. БОльший расход памяти (не такой уж большой), но зато независимость скорости отрисовки фрагмента листа от объема всего листа.
Хранение данных ячеек у меня аналогично
Используется вектор указателей. Если ячейка не определена, то указатель, естественно, NULL
Правда, у такого подхода недостаток - не очень высокая скорость вставки большого количества ячеек. В случае вектора не указателей, а вектора ячеек, выделение памяти происходило бы только один раз при вставке, например, 1000 ячеек. А так придется для каждой ячейки отдельно выделять память. (Но, в принципе, это можно будет обойти, если это станет узким местом.)