test - name calc inside writer.odt (17.3 KB)
Hello, in the attached file I tried to insert as LO Calc OLE object inside Writer File, everything was good except the filename field added in the OLE object.
Expected result: Filename field in CALC OLE should show Writer File name and probably same problem for all macros inside CALC OLE.
Obtained result: a string “?” character.
Then, is there any method to do this expected result?
=CELL("filename";$A$1) cannot return a filename (URL) because the property is empty for the sheet model. TextField objects except URL fields (which in turn don’t exist in Writer texts).TextField in the Writer text where your OLE sheets is embedded, You can copy it, but pasting that into a cell of the sheet as an object won’t work. You can paste plain text there using Shift+Ctrl+V. This will, of course, insert the FileName of the Writer doc..StringValue of that model which was for your example (on my computer and after “unencoding” and …)C:\Users\MyUserName\Downloads\test - name calc inside writer.odt\Object 1\
See also attachment
test - name calc inside writerRe.odt (21.6 KB)
BTW: Better use names without spaces and special characters.
To get a relevant answer, you must ask a good question. Yours lacks elementary information like OS name and LO version. Many many questions on AskLO qualify for bad question because looks for a fix against a wrong track they followed. See as an illustration the famous cartoon about software development (the tree and the swing: what debugging produced).
Instead you should clearly describe in broad terms what you want to get finally instead of requesting a fix for a solution you implemented within the limits of your background and of what you thought possible with LO. Usually, solutions start on too complex an idea instead of splitting the problem into smaller problems. In your case, perhaps not all data should go into the Calc spreadsheet.
Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-PE (es_PE); UI: en-US
Calc: threaded
In this special case the additionally given informtion doesn’t change the game.
My answer given as a comment above is correct and sufficiently complete.
(I will edit it concerning 2 minor details nonetheless.)
I tried everything in this post and other post but no solution, someone could sent a file sample?
Create a new Calc file and place the formula in cell A1:
=CELL("filename")
Result of the formula:
''#$Sheet1
The same result is in the embedded Calc object.
I don’t see a problem.
To suggest a solution, we need to understand the problem.
Why do you want to store Writer information into a Calc spreadsheet to reimport this data into Writer through an OLE object?
Wouldn’t it be simpler to insert Writer data directly with a field? The spreadsheet would then only contain numeric computations which are not very sophisticated in a Writer table.
A filename is a textual data. Consequently, you won’t be able to do any calculation with it. So, it looks to me pointless to insert it into a Calc spreadsheet. So explain why you deem this data so important that you need it in the spreadsheet.
Why do you want to store Writer information into a Calc spreadsheet to reimport this data into Writer through an OLE object?
Is a different dynamic workflow to work with OLE objects, but this is very limited, I mean, if you work with multiple OLE objects you can simulate an all-in-one Libreoffice.
Wouldn’t it be simpler to insert Writer data directly with a field? The spreadsheet would then only contain numeric computations which are not very sophisticated in a Writer table.
field inside OLE are need to create new type of templates dynamics, this is not possible in MS OFFICE or other, I just explore Libreoffice as a new user.
A filename is a textual data. Consequently, you won’t be able to do any calculation with it. So, it looks to me pointless to insert it into a Calc spreadsheet. So explain why you deem this data so important that you need it in the spreadsheet.
if this problem is solved, then the next step is use macro inside OLE objects.
… all this is basically to simulate octave, mathcad or smath, this workflow is created for engineering because Libreoffice have potential.
EDIT: If any libreoffice read this, please add support for dxf-bim for libreoffice-Draw
NO! This would be contrary to the philosophy of Draw: a simple program to create simple diagrams.
And don’t think trying to develop a DXF or BIM module through a set of macros. Youl’ll stumble on two pitfalls:
Not speaking of the poor performance.
Drop the idea of implementing a CAD layer over Draw. I understand why you want a Calc spreadsheet. That’s part of parametric CAD models, but interfacing Calc with your macros will be a nightmare.
If you want to experiment with a parametric CAD program, I suggest FreeCAD. It provides a spreadsheet module but they great advantage is this spreadsheet module “understands” linear dimensions, areas and volumes. It also handles automatic conversions from SI (metric) units to/from Imperial units. Experiment because feeling at ease with FreeCAD is not obvious. (I talk by experience)
What’s an all-in-one Libreoffice?
The example I already attached demonstrates a simple case of a UDF contained in the OLE sheets. A new example here also demonstrates how the OLE object and the Parent it is embedded in may cooperate. Lots of open questions!!
textDocWithCalcOLE.odt (25.8 KB)
*What I would welcome as a significant advance, and presumably as a unique feature of LibreOffice, would be a variant (EMV: EmbeddedModelView) of the old OLE, where a Model (in API speak), say a SpreadsheetModel or a DrawModel is embedded once but represented in any number of different views in different places (like in simultaneously opened windows). The embedded objects would have to implement and apply the capabilities of a Frame with the respective view controller (CurrentController) outside the model.
If some developers implement such a feature this would be GREAT, imo.
(Too phantastic?)
For what reason would you simulate existing software? Did you study its complexity and the required amount opf development?
I mean, now libreoffice have some errors like ms office, for example, you can not edit a file create in Libreoffice Draw in Libreoffice Writer easily, what I mean with a all-in-one Libreoffice is for example
an universal format for draw / writer / calc / etc, like a paper, and just use draw / writer / calc / etc like tool tabs, something like this:
in the image we have only a paper A4, then should be possible to edit each element in their different tool, there is not motive to have separate workflow like in the 1900.
why?
… actually exist notion, BIM, python 3, visual programming, etc, and now the strongest player is the AI GPT ; MS office and Libreoffice are becoming obsolete.
This is your opinion and allow me to disagree.
Consider odd jobs in your house. You can use an all-in-one tool like high-end Swiss Army knife. I personally prefer to have separate screwdrivers, cutters, saws, wrenches and … hammers (which you can’t obviously have in SAknife). These individual tools are better optimised for their tasks. Of course, you can’t carry them in your pocket.
Don’t misunderstand me. I don’t pretend one set of tools is superior to the other. It depends on the task at hand and the degree of “professionalism” or “polish-ness” you want to achieve.
Going back to LO, specifications for documents are very different from those for spreadsheets. ODF succeeds in describing both in a single format (though you can consider the specifications as “separate chapters” with a lot of different “paragraphs” outside a common frame) but managing and handling documents and spreadsheets are done by separate “functions” addressing different requirements (for example there is no text-flow-over-pages in Calc and even less in Impress where your “horizon” is limited to a slide).
I mean native objects in a space / sheet, not OLE, for example, use calc’s formulas inside writer’s tables.
This sounds more like a specification for a DTP application like Scribus or Quark XPress (though you can’t insert directly a spreadsheet into them). DTP apps consider pages as primitive objects. M$ Word and LO Writer handle text flows. Therefore, pages are only “contingencies” to cope with because a printer, the primary target of both suites, is limited to sheets and the flow must be sliced to fit sheets.
