Even internally Calc doesn’t remember the way a number (may be information of the kind
special number like dates representable by numbers) was once entered, or if it was entered via the keyboard or by pasting or…
While you are typing there is a recognition process guessing (kind of) whether you intend to enter a constant needing (by default) to be represented as a number - or if you want to enter text.
In addition there is a guess concerning the question if a ‘special number’ is input. In many cases the result of the guess depends on the locale and/or respective settings for the concerned cell. It will distinguish the as-if-types
Scientific, and probably additional ones. The number type to which the entered sequence of key hits is converted after the final
IEEE 754 Double in all these cases. The only trace the process of entering is leaving is the format automatically assigned to the cell then as a hard attribute. This is done by routines of the core code -and has effects Lupp (e.g.) clearly deprecates. He also cannot change this.
Depending on what, precisely, you actually want, there are thinkable workarounds coming with different disadvantages:
-W1- Enter your number explicitly as a text prefixing an apostrophe (or by setting the
@ format code in advance).
-D1a- Such numbertexts may be automatically converted for calculations depending on the locale at least.
-D1b- These celle contents are ignored by accumulating functions like
AVARAGE(), and more.
-D1c- The handling and the consequences generally are error-prone as a result.
-W2- You create user code using a
KeyListener to override the hardcoded default processes.
-D2a- A lot of studies and labor needed, also error-prone (depending on your skills).
-D2b- Will also need to use hard attributing (like te default processes in many cases).
-W3- You write user code working against unwanted effects after the fact (with onContentChanged e.g.) .
-D3- Similar as with -W2-
-W4- Something probably someone else will suggest …
My honest advice: Let it be!