I am using a function for sorting arrays inside my calc document, which is supplied via an extension. However, transferring the file to a different system, where the extension isn't installed, breaks the function. Since the file is designed to be shared with many other users, it is impractical to instruct each of them to install the necessary extension individually.
Is there a way to embed/link the function supplied by the extensions to the .ods-file itself in such a way that the function wont break on file transfer?
When I tried to embed an add-in into a document by modifying manifest.xml, the add-in was ignored. Also, I ran into other limitations of embedding, such as not allowing importing from a pythonpath folder.
The documentation is rather difficult, but these two links perhaps support my conclusion:
https://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Spreadsheet_Add-Ins
https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Deployment_Options_for_Components
So it looks like the possibilities are to either require people to install the extension, or use a user-defined function instead of an add-in. It should be possible to embed a UDF in a document.
Related
I have some data (logins) I want to be ignored from git in my custom TYPO3 extension code.
As AdditionalConfiguration.php is already ignored in my case, it seems a good place to store such data.
It normally contains Data like
$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['dbname']
Now would it make sense to make something like custom globals? Does that exist?
$GLOBALS['CUSTOM_CONF_VARS']['MYEXT']['username']
Should and can I do that or not?
I think you can use your own globals. But I would consider using your own globals as bad programming style.
If you have installation specific data the right way to store the data depends on the kind of data and where you need it:
everything for the Frondend should be stored in typoscript. This can be in a file from a site-extension or in the database (template record)
for BE you could use Page- or User-TSconfig. here you also can use a file from a site-extension or database records (pages/be_user)
if you have FE and BE or anything alse (e.g. scheduler jobs) you can use extension specific global data, you can set in the extension manager. -> docs.
Instead of saving configuration in $GLOBALS try use typoscript. Will be much easier to keep and maintain it.
I'm planning to use Mono.Addins in my C#/.NET project.
For that, I've read the Programming Guide and Reference Manual presented in codeplex.com, downloaded the latest version of source code from github.com, and successfully built all the samples included in the source package. However, whether the online documents or sample projects, all try to demonstrate how to extend an AddinHost by creating new instances of an ExtensionNode. There seems to miss something about how to retrieve and process data from the AddinHost.
For example, say I have a text editor, which processes RTF document, and I want to provide the possibility for addins to find/replace the document with its own way (For example, Regex / Forward / Backward / Whole document / Current Line...), so the addin need to get the content from AddinHost first. This is the question I need an answer for.
Any ideas?
If I understood well you have to maintain a reference to the RTF document, I think that providing it inside an initialization code for your plugin could be a way to obtain it.
Or you can have a sort of "IFindReplaceAddin" with a method, say "FindReplace", that accepts the RTF document as argument and returns the elaborated document.
I am trying to generate an xls file with Spreadsheet::SimpleExcel that calls a function that is defined in a third party add in (Bloomberg, if it matters). The underlying WriteExcel package does not let me write this out because it does not know about this add-in function. I see the giant hash table of built-in functions that the module knows about and could potentially add this function to it, but I don't know the attributes of the function, especially the 'ptg code'.
Is there a way to either determine what the ptg code (I assume this is something like an opcode) of this third-party function, or is there some way to trick the module into letting me write out these functions without it having to know these details? Or some third plan that I haven't thought of?
Spreadsheet::WriteExcelXML and Excel::Writer::XLSX should be able to generate Excel files with third party functions.
Both modules use the same interface as Spreadsheet::WriteExcel although with fewer features.
I think you need to use Win32::OLE and it's a bit messy. Try:
$xls->AddIns->Add( $xll_path );
$xls->RegisterXLL( $xll_file );
where $xll_path is the full path to the xll for Bloomberg and $xll_file is just the xll name.
I'm currently making good use of GWT's ClientBundles in my app. It works fine, but I have a large number of resources and it becomes tedious to manually create Java interfaces for each file:
#ClientBundle.Source("world_war_ii.txt")
public ExternalTextResource worldWarII();
#ClientBundle.Source("spain.txt")
public ExternalTextResource spain();
#ClientBundle.Source("france.txt")
public ExternalTextResource france();
I'd like to be able to (perhaps at compile time) dynamically list every *.txt file in a given directory, and then have run-time access to them, perhaps as an array ExternalTextResource[], rather than having to explicitly list them in my code. There may be hundreds of such resources, and enumerating them manually as code would be very painful and unmaintainable.
The ClientBundle documentation explicitly says that "to provide a file-system abstraction" is a non-goal, so unfortunately this seems to disallow what I'm trying to do.
What's the best way to deal with a large number of external resources that must be available at run-time? Would a generator help?
There's an automatic generator for CssResource - maybe you could look at its code and modify it to your needs?
I ended up following this advice: perform the file operations on the server, and then return a list of the file (meta)data via an RPC call.
This turns out to be fairly simple, and also allows me to return lightweight references (filenames) in the list, which I use to populate a Tree client-side; when the user clicks on a TreeItem the actual text contents are downloaded.
This is a little convoluted, but lets try:
I'm integrating LUA scripting into my game engine, and I've done this in the past on win32 in an elegant way. On win32 all I did was to mark all of the functions I wanted to expose to LUA as export functions. Then, to integrate them into LUA, I'd parse the PE header of the executable, unmangle the names, parse the parameters and such, then register them with my LUA runtime. This allowed me to avoid manually registering every function individually just to expose them to LUA.
Now, flash forward to today where I'm working on the iPhone. I've looked through some Unix stuff and I've gotten very close to taking a similar approach, however I'm not sure it will actually work.
I'm not entirely familiar with Unix, but here is what I have so far on iPhone:
Step 1: Query for the executable path through objective-C and get the path of my app
Step 2: Use dlopen to get a handle to my app using: `dlopen(path, RTLD_NOW)`
Step 3: Use `dlsym( libraryHandle, objectName )` to attempt to get the address of a known symbol.
The above steps won't actually get me to where I want to be, but even that doesn't work. Does anyone have any experience doing this type of thing on Unix? Are there any headers or functions I can google to put me on the right track?
Thanks;)
iPhone does not support dynamic linking after the initital application launch. While what you want to do does not actually require linking in any new application TEXT, it would not shock me to find out that some of the dl* functions do not behave as expected.
You may be able to write some platform specific code, but I recommend using a technique developed by the various BSDs called linker sets. Bascially you annotate the functions you want to do something with (just like you currently mark them for export). Through some preprocessor magic they store the annotations, sometimes in an extra segment in the binary image, then have code that grabs that data and enumerates its. So you simply add all the functions you want into the linker set, then walk through the linker set and register all the functions in it with lua.
I know people have gotten this stuff up and running on Windows and Linux, I have used it on Mac OS X and various *BSDs. I am linking the FreeBSD linker_set implementation, but I have not personally seen the Windows implementation.
You need to pass --export-dynamic to the linker (via -Wl,--export-dynamic).
Note: This is for Linux, but could be a starting point for your search.
References:
http://sourceware.org/binutils/docs/ld/Options.html
If static linking is an option, integrate that into the linker script. Before linking, do "nm" on all object files, extract the global symbols, and generate a C file containing a (preferably sorted/hashed) mapping of all symbol names to symbol values:
struct symbol{ char* name; void * value } symbols = [
{"foo", foo},
{"bar", bar},
...
{0,0}};
If you want to be selective in what you expose, it might be easiest to implement a naming schema, e.g. prefixing all functions/methods with Lua_.
Alternatively, you can create a trivial macro,
#define ForLua(X) X
and then grep the sources for ForLua, to select the symbols that you want to incorporate.
You could just generate a mapfile and use that instead, no?