[libreoffice-users] [calc][pyuno] How to modify borders of cell range via python
Greetings Can someone advise on how to access and modify borders of cell ranges programmatically? I've been attempting this using python macro scripts without success. I also asked at http://ask.libreoffice.org/en/question/38724/how-can-one-set-the-borders-of-a-cell-range-via-python-scripting-framework/ Looking forward to some assistance. Thanks in advance Onyeibo -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Re: Slow Calc Macros
On 06/08/2011, planas jsloz...@gmail.com wrote: Hi, On Sat, 2011-08-06 at 13:31 +, Onyeibo Oku wrote: 1) True but what I'm doing is more computational than relational though the end result will be a material for building a proper database. A spreadsheet is more suited for this ... Trust me on this. Okay, I may be wrong here because I speak as bound by the level of knowledge I have on spreadsheets and database management, My experience in dbase is small compared to spreadsheets. (See comments below for and example of what I'm doing. Maybe someone can advise me better.) I could be a moron after all. I am open to suggestions. -Original Message- From: Andreas Säger ville...@t-online.de Date: Sat, 06 Aug 2011 12:34:13 To: users@global.libreoffice.org Reply-To: users@global.libreoffice.org Subject: [libreoffice-users] Re: Slow Calc Macros General rule of thumb: 99% of all spreadsheet macros are potentially harmful, counter productive, badly implemented and reveal nothing but the author's ignorance against the underlying spreadsheet application. Could it be that a most simple database would solve all your problems without a single line of silly Basic? Depending on the complexity of the calculations you might find Base easier to use. Relational databases support normal arithmetic and simple statistical functions (sum, count, average) because they are implemented in SQL. The more complex functions are not supported by SQL such as trig or log. -- Jay Lozier jsloz...@gmail.com So, let me float this problem. I probably will get a better approach to it by sampling the pros. If you work in an educational facility and want to reel in lots of result sheets from teachers. You are dealing with people who find spreadsheets foreign and databases extra-alien and geeky. These people are the source of data for the main database. On the other hand, you want to consider speed of data generation and data portability. You want to set up a template to allow these people supply this information at little or no cost using existing infrastructure and with minimal training. There is no local network yet, and the internet in the facility is not for result management and you need to start building these data NOW! Another thing to consider is that the results must be presented in a certain way. Forms can do this ... Spreadsheets can also do that. But these forms should be dynamic to spread results across legal size papers depending on number of candidates. This presentation is for printing purposes only and not for the Dbase. Please suggest the best route. My route now is to provide these people with a spreadsheet template that takes care of their usual result analysis and grading. It organises the results into sheets for printing using a pre-designed sheet that it copies as necessary for more sheets. We have to option of submitting the spreadsheet document for use in building institution wide DB or using CSV versions instead. I am doing this as a contribution to an institution that will only accept a movement to IT based management when they see something that works and it has to be done fast and on-the-go without disturbing the programme and the employees much. What do you guys suggest? Base for those teachers' inputs (or should it be Calc?), while the rest can be strictly DB programs. I want this to be done with opensource solutions since I'm already suggesting opensource OS for use in same institution. Thanks -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Slow Calc Macros
On 07/08/2011, Regina Henschel rb.hensc...@t-online.de wrote: Hi, Onyeibo Oku schrieb: I did a python macro that adds sheets, renames them and fills in some formula in select cells. It also has a portion that deletes the sheets. I find that the sheet creation runs faster although there's more lines of code running. Whereas the sheet removal macro is just 2lines and runs 3-5times slower. Both routines use 'FOR' loops (the creating routine even has a nested loop). What could be responsible? Does calc recalculate for each removed sheet? Can that feature be toggled off via macro just before the removal loops ...and toggled back on? If you delete a sheet in the UI, then an undo object is generated. Does this happen in your macro too? Kind regards Regina Yes. You can undo almost everything done with a macro ... So far, I've been able to undo all changed made by my macros. I haven't come across an incomplete redo yet. Regards Onyeibo -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Re: Slow Calc Macros
On 05/08/2011, Andreas Säger ville...@t-online.de wrote: Am 04.08.2011 09:03, Onyeibo Oku wrote: I did a python macro that adds sheets, renames them and fills in some formula in select cells. It also has a portion that deletes the sheets. I find that the sheet creation runs faster although there's more lines of code running. Whereas the sheet removal macro is just 2lines and runs 3-5times slower. Both routines use 'FOR' loops (the creating routine even has a nested loop). What could be responsible? Does calc recalculate for each removed sheet? Can that feature be toggled off via macro just before the removal loops ...and toggled back on? Thanks in advance :) - from twohot@device.mobile :) Removed sheets may have references, a new sheet can not have any references nor is it referenced. bAC = isAutomaticCalculationEnabled() doc.enableAutomaticCalculation(False) do_stuff doc.enableAutomaticCalculation(bAC) Thanks Andreas, I've done that but the problem persists. I also made another observation. One of the reserved sheets have formulas spanning about 10columns by 1750rows (some of them having up to 4-6levels of nested 'IF's with conditional formats). When I remove that sheet, the macro executes instantly. What I don't understand is why Calc still computes that sheet while deleting other sheets. The macro makes no reference to it and it doesn't reference the deleted sheets. The 'culprit' sheet uses named cell refs but all within itself except one cell that references a cache sheet which never gets deleted. More baffling is that it happens with AutomaticCalculation set to False. I wonder if watching the huge range with a listener will produce better performance results. -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
