Aloha Sebastian :)
Am Freitag, 28. September 2012, 14:21:33 schrieb Sebastian Sauer:
> Aloha Friedrich and * :)
>
> On 09/27/2012 11:49 PM, Friedrich W. H. Kossebau wrote:
> > Hi,
> >
> > I looked into why date variables are always only displayed with the
> > default
> > format and found that the error lies in that
> > KoOdfNumberStyles::format(...)
> > expects the value for date (and seems also time) to be a number in string
> > form:
> > --- 8< ---
> > QString format(...)
> > {
> > [...]
> >
> > case Date: {
> >
> > bool ok;
> > int v = value.toInt(&ok);
> > return ok ? formatDate(v, format.formatStr) : value;
> >
> > [...]
> > }
> > --- 8< ---
> >
> > Problem now is that DateVariable keeps the value as date string around and
> > not in that single number string version (from what I understood, no yet
> > the complete picture).
>
> Indeed and it makes sense cause the variableManager()->value() is used
> direct for display but that opens the problem that it does not contain
> the information what format was used to produce the date/time what makes
> it rather hard to extract the original value (means translate it back)
> to e.g. apply another format...
>
> I think for the load/save roundtrip this is not a problem cause we just
> load, display and save it like it was but as soon as someone likes e.g.
> during editing change the display format those formatted string value
> needs to be translated to its QTime/QDate/QDateTime representation to
> proper apply the format.
>
> > There is also this TODO (from you, Sebastian):
> > --- 8< ---
> > void UserVariable::valueChanged()
> > {
> >
> > //TODO apply following also to plugins/variables/DateVariable.cpp:96
> > //TODO handle formula
> > QString value = variableManager()->value(m_name);
> > value = KoOdfNumberStyles::format(value, m_numberstyle);
> >
> > kDebug() << m_name<<variableManager()->value(m_name) <<
> > m_numberstyle.formatStr << value;
> >
> > setValue(value);
> >
> > }
>
> iirc that's what the TODO was referring to. In the DateVariable we
> already proper parse the formatted value string to earn a
> QTime/QDate./QDateTime representation that can then be used future.
>
> It's a special case which would needs to be handled in the UserVariable
> where the original formatted string is reused with a new format *AND*
> for editing where a user likes to change the format. Both is handled in
> the DateVariable but not in the UserVariable.
>
> > --- 8< ---
> >
> > Are you working on this any time soon, Sebastian? Or could you point me
> > into the direction how this TODO is planned to be solved, so I can give
> > it a try?
> There seems to be no way currently to make local members a
> variable-instance has accessible to other variables. The KoProperties
> are shared among all instances of a variable (iirc, or not?) and so the
> easy way to just extend the DateVariable to proper write the in loadOdf
> read m_definition into the KoProperties like
> props->setProperty("definition", m_definition); is not possible.
>
> I think what would be needed is a generic "variableInstanceProperty" (or
> since Kovariable inherits from QObject somebody could just use
> QObject::setProperty) and then in loadOdf and on changing the
> m_definition of a DateVariable someone could
> QObject::setProperty("dateDefinition", m_definition) and in the
> UserVariable extract that info using
> QObject::property("dateDefinition").toString() and then something like
> QDate date = parseDate(variableManager()->value(m_name),
> variableManager()->variable(m_name)->property("dateDefinition")); or so...
>
> Maybe it (the parsing) could even be done a level up in the KoOdfNum*
> itself? iirc there is some nice parsing code in
> calligra/filters/sheets/xlsx/NumberFormatParser.cpp and there is also
> quit some logic in the DateVariable which looks like something that may
> of more common use (means e.g. also for other variables).
>
> All that untested and without looking at the code for a long while and
> just now had my first looks after finally figuring out the git checkout
> errors I had for a longer time got solved :) Hope it gives some ideas
> and hope it helps to address that problem. Lot of thanks for looking
> into it! :)
Thanks for replying and giving all the pointers/ideas. Sad thing is a day
later I upgraded my system and messed my development enviroment, so cannot yet
try to make something from that, but hopefully soon will.
Cheers
Friedrich
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
