This UNO add-in thing turns out a bit too complex for me. I've managed as far as getting a libpricinglo.so compiled but "make install" doesn't copy it into destination. Also there's no entry of the new add-in in services.rdb, which I think is needed. I've already modified
Repository.mk scaddins/*.mk postprocess/packcomponents/makefile.mk solenv/gbuild/extensions/pre_MergedLibsList.mk but I must be missing something? > Given that Gnumeric already implemented or will implement the functions > I would strictly follow them for interoperability. You can have the > 7 different functions at formula level and still internally have them > call one function with an enum, or however you would like to implement > it. Doing things differently doesn't help users. The only function which is already in Gnumeric and I'm trying to implement here is opt_bs() and I'll keep the parameters the same then. Having 7-9 different functions may be ok if you only have one option pricing function, but my plan is for 4 functions and I'm not going to spam calc with 4*9=36 functions. :) I should say I'm also trying to add two pricing functions (opt_barrier() and opt_touch()) in Gnumeric but I've not reached an agreement with the developers on exactly this issue so it probably will simply be implemented without the "Greek flag" (delta, gamma, vega, etc). > > If there are no strong objections, I'd > > prefer to go with char/string inputs or anything which is more > > intuitive for the user? > > I don't see that specifying a parameter with the name is more intuitive > than using a function with the same name appended. To the contrary, > function names can be localized while string arguments can't. No, that's right, but that would explode the number of functions unnecessarily. If string inputs are a big problem then I'd rather go for char inputs (or even int as a last resort). Cheers, Tino _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
