[sc-issues] [Issue 105608] F9 doesn't recalculate ce lls with custom OOo Basic functions

2009-10-17 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105608





--- Additional comments from s...@openoffice.org Sat Oct 17 13:37:34 + 
2009 ---
Ok, thanks... (still, I don't see the advantage of having F9 *not* do this...)

Also, why is there no entry for this in the Tools  Cell Contents menu (where
the 'normal' Recalculate action is listed)? How are you supposed to discover
this functionality without someone telling you about it?

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 105986] Provide a way to specify recalculate hints for OOo Basic functions used in spreadsheet formulas

2009-10-17 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105986
 Issue #|105986
 Summary|Provide a way to specify recalculate hints for OOo Bas
|ic functions used in spreadsheet formulas
   Component|Spreadsheet
 Version|DEV300m55
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|DEFECT
Priority|P3
Subcomponent|programming
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Sat Oct 17 13:52:26 + 
2009 ---
I have a multi-sheet OOo Calc file in which the first sheet presents a dynamic
overview of information gathered from string, date and number data in the other
sheets in rather complex ways.

Because of certain limitations in the built-in Calc formula functions (most
notably, SEARCH() not providing a way to check *whether* the specified string
was found (see‪ issue 66590), and LOOKUP() not supporting string keys) I had to
write several custom Basic functions to accomplish my task (all in all, over 150
cells in the overview sheet now call at least one of those Basic functions).

The trouble is: the whole thing is horribly slow now!

Whenever I make *any* change to that overview sheet now - and be it only
changing the contents of one single (unrelated) cell, clicking the bold
toolbar button with any cell selected, or even only resizing a column - the
whole interface locks down for about three (!!) seconds while Calc seems to
recalculate all formulas on that sheet (you see a progress bar at the bottom of
the window during those three seconds).

To remedy this situation, I propose allowing certain recalculate hints to be
specified for Basic functions in order to limit the number of occasions on which
a function will be re-evaluated when it is used inside a spreadsheet formula.

The easiest solution would probably be to allow the hints to be specified as a
comment in Basic code right before the function definition - maybe something
like this:

Rem FunctionRecalculateTriggers cell_contents_only,
cells_accessed_on_last_evaluation_only
Function MyReallyTimeConsumingCustomLookupFunction(...)
...
End Function

The recalculate hints would cause the results of this Basic function to be
cached for each instance (by that I mean: each cell from which it is called
from + parameters given combination) and from then on only recalculated under
specific conditions.

The recalculate hints I propose are:

   1) no_recalculate
-- Never recalculate the function instance (once it has been evaluated 
once)

   1) cell_contents_only
-- Never recalculate the function instance when no actual cell content has
been changed in the spreadsheet (e.g., only formatting or column width changes
have occured)

   2) cells_accessed_on_last_evaluation_only
   -- Never recalculate the function instance when none of the cells that were
read from during the last evaluation of the function instance have changed

There might be other hints that one could add, but for purposes like the complex
overview sheet described above, those three recalculate hints would already be
totally sufficient.
Functions should still be re-evaluated no matter what when the documents is
loaded, when [ctrl]+[shift]+F9 is pressed, when their function code has changed
or when the parameters passed to them have changed.

I'd like to but special emphasis on the proposed
cells_accessed_on_last_evaluation_only hint. This is not as arbitrary as it
might sound - in fact, I suppose that almost all functions that don't make use
of the current time, or outside data, etc. might greatly benefit from it.
Think about it... (look at the built in spreadsheet functions to see that this
really makes sense for a lot of functions...):
For example, image a sheet where A2 holds the number 2 and some cell holds the
formula =OFFSET(A1; 0; A2):
1) What parts of the spreadsheet are then read (internally) during the
initial evaluation of the formula?
- Only the contents of the cells A2 and C1.
2) From then on, can the the outcome of the formula change as long as
neither the value of A2 nor the value of C1 changes?
- No.
Therefore, if OFFSET() were implemented as a (slow) Basic function, the
cells_accessed_on_last_evaluation_only recalculate hint would provide vast
performance improvements for spreadsheets that use the function in many cells
(and it would still make sure that the function *is* reevaluated whenever
actually necessary).

The same also holds true for all the custom Basic functions involved in my
complex dynamic spreadsheet mentioned above... In fact, I guess that being able
to set this recalculate hint might actually reduce

[sc-issues] [Issue 105986] Provide a way to specify recalculate hints for OOo Basic functions used in spreadsheet formulas

2009-10-17 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105986


User smls changed the following:

What|Old value |New value

  Issue type|DEFECT|FEATURE





--- Additional comments from s...@openoffice.org Sat Oct 17 14:04:26 + 
2009 ---
(incorrectly marked as defect, sorry)

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 105608] F9 doesn't recalculate ce lls with custom OOo Basic functions

2009-10-05 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105608
 Issue #|105608
 Summary|F9 doesn't recalculate cells with custom OOo Basic fun
|ctions
   Component|Spreadsheet
 Version|OOO300m5
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|DEFECT
Priority|P3
Subcomponent|editing
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Mon Oct  5 11:31:24 + 
2009 ---
Caching those results makes sense I guess, but a manual recalculate command
being issued is one case where you *would* expect everything to be actually
re-evaluated.
Or is there any reason one might want to press F9, but wouldn't wan't custom
functions re-evaluated?

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 105609] make applying new colors less cumbersome

2009-10-05 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105609
 Issue #|105609
 Summary|make applying new colors less cumbersome
   Component|Spreadsheet
 Version|DEV300m55
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|FEATURE
Priority|P3
Subcomponent|formatting
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Mon Oct  5 11:33:54 + 
2009 ---
I work a lot with Writer, Calc and Presenter and I work a lot with colors. Over
the course of the last year I must have wasted, when added together, probably
several *hours* of my time just creating new colors for use in those OOo apps.
I mean, seriously - having to spend a minute or two in the application
preferences dialog every time you wish to try a new color? Who ever thought of 
that?
Please, please, please add a quick, comfortable  interactive way for choosing
and applying colors that aren't in the current palette. Just like any other
rich-text capable application in the world has.
Pretty please.
This is a serious deficiency in this otherwise very useful and mature office
suite, and also the main reason I'm not sure I can recommend OpenOffice to
others yet as a replacement for Microsoft's proprietary office suite.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[graphics-issues] [Issue 105610] Interactive crop in Prese nter

2009-10-05 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105610
 Issue #|105610
 Summary|Interactive crop in Presenter
   Component|Presentation
 Version|OOO300m5
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|FEATURE
Priority|P3
Subcomponent|editing
 Assigned to|graphicsneedsconfirm
 Reported by|smls





--- Additional comments from s...@openoffice.org Mon Oct  5 11:35:30 + 
2009 ---
It would be nice to be able to interactively crop images that have been inserted
into a presantation by selecting crop from the image toolbar and then dragging
the image's edges in or out, instead of having to painstakingly enter manual
values in the crop dialog that is currently offered.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org
For additional commands, e-mail: issues-h...@graphics.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 105611] If 'search_text' is not f ound, let FIND() and SEARCH() return 0 instead of a #VALUE error

2009-10-05 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105611
 Issue #|105611
 Summary|If 'search_text' is not found, let FIND() and SEARCH()
| return 0 instead of a #VALUE error
   Component|Spreadsheet
 Version|DEV300m55
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|FEATURE
Priority|P3
Subcomponent|editing
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Mon Oct  5 11:37:20 + 
2009 ---
Feature request title should be self-explanatory.
1) Avoid annoying error values in dynamic spreadsheets, 2) make it possible to
write IF(SEARCH(.. , ..)) and similar. That should be benefit enough.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 105612] Provide a RICHTEXT() func tion for dynamic text formatting of formula ou tput in cells

2009-10-05 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105612
 Issue #|105612
 Summary|Provide a RICHTEXT() function for dynamic text formatt
|ing of formula output in cells
   Component|Spreadsheet
 Version|DEV300m55
Platform|Unknown
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|FEATURE
Priority|P3
Subcomponent|editing
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Mon Oct  5 11:38:19 + 
2009 ---
Provide a function called 'RICHTEXT()' for use in cell formulas in OOo Calc ,
that will take one string argument possibly containing html-like tags, and
return the plain text stripped of all the tags  --  and, when used as a
top-level function in a cell formula, will cause the returned text to be
formatted inside the cell according to those HTML-like tags. For example, a cell
with the following cell formula would then show the text Title (subtitle) with
nice bold/italic formatting:
=RICHTEXT(bTitle/b (isubtitle/i))
The internal value of the cell, for example when referenced by another formula,
would however just be the plain string Title (subtitle).
At a minimum, the tags b, i, u, color and size (or however you wish to
name them) should be supported.
This would allow for much much greater flexibility and convenience for designing
visually pleasing dynamic spreadsheets, compared to the rather limited and
really cumbersome to use 'STYLE()' function and 'conditional formatting' 
feature.
(Note: Maybe it would then make sense to also introduce a 'MASK()' function,
that will augment a given string in such a way that 'RICHTEXT()' won't interpret
any part of it as formatting tags -- for example, by making the replacements
  --  amp;
  --  lt;
  --  gt;
which 'RICHTEXT()' would then convert back to the original characters in it's
plain text output. This would then allow to safely write, for example:
=RICHTEXT(bFor bold text use the tag:/b   MASK(b)
which would display the string For bold text use the tag: b inside the cell,
with partially bold formatting of course.)

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org



[sc-issues] [Issue 104761] CURRENT() does not seem t o work inside nested functions

2009-09-03 Thread smls
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=104761
 Issue #|104761
 Summary|CURRENT() does not seem to work inside nested function
|s
   Component|Spreadsheet
 Version|OOO310m18
Platform|PC
 URL|
  OS/Version|Linux
  Status|UNCONFIRMED
   Status whiteboard|
Keywords|
  Resolution|
  Issue type|DEFECT
Priority|P3
Subcomponent|editing
 Assigned to|spreadsheet
 Reported by|smls





--- Additional comments from s...@openoffice.org Thu Sep  3 14:31:19 + 
2009 ---
The OOCalc formula function CURRENT() does work when it is used as an argument
for another function, but not when that function is itself an argument for a
third function.

For example, the following two formulae produce exactly the same output, as one
should expect (with B1 holding a number, and A1:A5 a list of five numbers sorted
in ascending order):

=  MATCH( B1;A1:A5 )
= B1 + MATCH( CURRENT(); A1:A5 ) - B1

Similarly, one should also expect the following two formulae to produce the same
output as each other:

=  INDEX( A1:A5; MATCH( B1;A1:A5 ))
= B1 + INDEX( A1:A5; MATCH( CURRENT(); A1:A5 )) - B1

However, while the first one returns the proper value from the list A1:A5, the
second one causes a #VALUE! error.

The simple example given is of course rather useless, but I do have a
spreadsheet where I would like to set conditional STYLE() values depending on
rather complex value lookups based on the CURRENT() cell value, which this bug
seems to unfortunately make impossible.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org