Uhm... Right
I have the following situation
a1 has text and a number
b1 has a number
I'd like to have c1 calculate the numbers from a1 and b1. Is there a way to do this without removing the text from a1?
[Solved] Text and values
[Solved] Text and values
Last edited by Tryryke on Sat Jul 22, 2017 9:37 am, edited 1 time in total.
OpenOffice 4.1.3 on Windows 7
Re: Text and values
There may be a way to do this but we need to know more about the content of cell A1.Is there any pattern to A1? Does the text always have the same length and position? For example, is it always three characters to the left of the numeric characters?
OpenOffice 4.1 on Windows 10 and Linux Mint
If your question is answered, please go to your first post, select the Edit button, and add [Solved] to the beginning of the title.
If your question is answered, please go to your first post, select the Edit button, and add [Solved] to the beginning of the title.
Re: Text and values
ATM it looks pretty much like this
A1:Strenght (S): 16
The only variable here is the number
A1:Strenght (S): 16
The only variable here is the number
OpenOffice 4.1.3 on Windows 7
Re: Text and values
you can use this =RIGHT(A1;2)*B1
and like FJCC says the text with formula must always be the same
hope this will help
and like FJCC says the text with formula must always be the same
hope this will help
Libre Office 6.1 dev homebuild Open Office 4.1.5 on Slackware64 current
Re: [Solved] Text and values
(This is a somehow "academic" contribution. Simple cases should well be solved in a simple way based on specifics that can be assured.)
In a similar but more general (less specialised) situation it may be of interset how syntactically acceptable numbers can be extracted from a text under the sole condition that they are properly delimited. The assured delimiter may be a space or a semicolon or any string (chain of characters) not conflicting with the syntax of numbers given in a textual representation accepted by the software.
The solution is based on "macro" functions for general purposes included with the attached demo as user functions coded in OpenOffice BASIC.
As always in such contexts: Changing localisations may cause problems. Unfortunately there is no mandatory syntax for numbers applicable worldwide. In addition localisations offer "thousands separators" or even more of such hokum - and software is expected to accept this despite the fact that their usage is explicitly deprecated by international standards. Trying to get a substitute for the missing specification - even complications accepted - aiming at being able to "recognise" numbers independent of locale and stubbornness of users would surely end up in a mess (as we already have it for dates).
For the current task I accepted the judgement the standard function VALUE() establishes. This does not mean at all that I agree with it. Anyway I have to accept dependence on the locale.
Also see https://docs.oracle.com/cd/E19455-01/80 ... index.html e.g. (The pattern given for Germany there looks funny to me, however. Suppose a "typo".) Concerning the thousands separator only the small space is endorsed internationally by ISO 31-0 (in a weak sense) but rarely used and not accepted by LibO locales I know. In addition the standard itself is ambiguous/unclear with this respect since Unicode doesn't define a "small space" but some space characters that might be assumed to be the meant by the term.
In a similar but more general (less specialised) situation it may be of interset how syntactically acceptable numbers can be extracted from a text under the sole condition that they are properly delimited. The assured delimiter may be a space or a semicolon or any string (chain of characters) not conflicting with the syntax of numbers given in a textual representation accepted by the software.
The solution is based on "macro" functions for general purposes included with the attached demo as user functions coded in OpenOffice BASIC.
As always in such contexts: Changing localisations may cause problems. Unfortunately there is no mandatory syntax for numbers applicable worldwide. In addition localisations offer "thousands separators" or even more of such hokum - and software is expected to accept this despite the fact that their usage is explicitly deprecated by international standards. Trying to get a substitute for the missing specification - even complications accepted - aiming at being able to "recognise" numbers independent of locale and stubbornness of users would surely end up in a mess (as we already have it for dates).
For the current task I accepted the judgement the standard function VALUE() establishes. This does not mean at all that I agree with it. Anyway I have to accept dependence on the locale.
Also see https://docs.oracle.com/cd/E19455-01/80 ... index.html e.g. (The pattern given for Germany there looks funny to me, however. Suppose a "typo".) Concerning the thousands separator only the small space is endorsed internationally by ISO 31-0 (in a weak sense) but rarely used and not accepted by LibO locales I know. In addition the standard itself is ambiguous/unclear with this respect since Unicode doesn't define a "small space" but some space characters that might be assumed to be the meant by the term.
- Attachments
-
- ExtractNumbersFromText_Was_aoo89632.ods
- (23.79 KiB) Downloaded 70 times
On Windows 10: LibreOffice 24.2 (new numbering) and older versions, PortableOpenOffice 4.1.7 and older, StarOffice 5.2
---
Lupp from München
---
Lupp from München