Larry Evans wrote:
On 09/11/08 12:39, norseman wrote:
Larry Evans wrote:
I created an input field with name=inp-fun-field0'.
Then, a few lines down, I created another input field.
I guess, by accident, I gave it the same name, inp-fun-field0.
Isn't that a bug? I'd expect the input field names are
unique; otherwise, that's the purpose of the name? If
the name is only a description, then maybe I could
understand it, but 'name' at least to me, suggests
a unique value.
Help search for 'input field' did show an 'Input Field'
link; however, when I went there, it had, in bold,
Input Field, but didn't mention anything about unniqueness
of the name.
TIA
-Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
=======================
I'm not seeing a detail I would like to know about.
If you put text or number 1 in first of duplicate field entry and 2 in
second, what happens then? Do both go to second value when used?
If so - overwriting is allowed. If not, The application programmer
needs to answer your question. I assume case and such are also
matching because differing case means differing variables.
The norm is: Each variable has to be unique in order to be discernible.
The exception occurs in Excel. When line 1 has the same text in
different columns and the file is written out as a CSV, duplicate
field names are kept. Excel, when making CSV or DBF files, voids the
rules and neither are then directly usable in data base work. Excel
is position based only. Labels mean nothing. I recently had to work
with a set of files in which each had three different field names
repeated 36 times each. I had to write a black box to straighten them
(several hundred files) out for subsequent use.
Steve
norseman
Steve,
Your mention of Excel suggests your'e talking about OOCalc, not write,
the word processor. My problem was with the word processor (I thought
the [writer] in subject line would indicate that).
Yeah - I got that first time.
To answer your question, the two entries seem completely independent.
I can change the value in one and it's not reflected in the other.
Is that the intention or is there a bug in my OOoWriter.
Would seem so. As in Variable goes here, here and here and is changing
with input. The overwrite I mentioned. The var is loaded again, each
time it is found and if it isn't changed by the user in passing that
point in the file then the view is not changed. Am I making sense?
If the name=[a-var] and the a-var is read from an outside list (think
mail merge) one of two things should show up. 1) the contents of a-var
should be same throughout OR 2) it should be next piece of next record.
If it is a 'type in' it should read current location contents and show
that and allow a change. In this case it's just a dummy that facilitates
the intended action. An overwrite. If you want to know what the
original programmer intended to happen you will need to track that one
down and ask.
As long as you can use it as you intended, or can make good use of it as
it is, I guess it is not actually a bug. Just an unexpected implementation.
This takes me back to: "The norm is:..."
The 'norm' changes by author these days. So straight or bent is
something of just how busted the glass they are looking through is.
To be specific about which writer, the help:about shows:
openoffice.org-core 1:2.4.1-1ubuntu2.Mon Jun 30 11:50:15 UTC 2008.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To us old timers - that glass is really busted up. And that is a shame.
We used to use a few punch cards and bingo, programs ran. Now one has to
type pages of 'setup' before even considering the program. Gotta account
for: fonts, code page, big/little ending, tcp, udp, stream, block, char,
sync, async, and on and on and on and... Complicate it further with
children that insist on not retaining the time tested guidelines.
(They seem to Excel in bad form.) OK - Ouch
Bottom line:
If it does what you want - there is no legitimate complaint to be had.
To satisfy curiosity - gotta find the author.
Steve
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
