A parte i miglioramenti che si possono fare sul criterio per assegnare
il numero, il problema vero è che non riesco a far scrivere la data
letta dal campo "data_emissione" nel campo "Data" della grid.
La macro si interrompe dicendo che il tipo di dato è errato
http://img220.imageshack.us/img220/2109/openofficeorg3211112010.png
Il formato della date è in entrambi i controlli GG/MM/AAAA, nella
definizione del campo della tabella su cui scrive la maschera ho
indicato in Tipo campo Data [Date].
Per leggere e scrivere faccio così:
...
' Legge data di emissione
rem legge
oForm = ThisComponent.DrawPage.forms.Dati
data=oForm.GetByName("data_emissione")
d_em=data.date
print "emissione:" + d_em
...
http://img600.imageshack.us/img600/6962/acquisizioneaschermoint.png
...
oConn = ThisDatabaseDocument.DataSource.GetConnection("","")
oStatement = oConn.createStatement()
...
sinsert = " update ""T_Dati_verbale"" set ""progr_annuo"" = '"& a &"'
where ""ID_gen"" = '"& numero_generale_verbale &"' "
oStatement.execute(sinsert)
sinsert = " update ""T_Dati_verbale"" set ""anno"" = '"&
anno_emissione &"' where ""ID_gen"" = '"& numero_generale_verbale &"'
"
oStatement.execute(sinsert)
sinsert = " update ""T_Dati_verbale"" set ""Data"" = '"& d_em &"'
where ""ID_gen"" = '"& numero_generale_verbale &"' "
oStatement.execute(sinsert)
...
i primi due update funzionano, mentre al terzo (quello sul campo
"Data") compare l'errore del formato dato.
La variabile d_em l'ho definita come:
global d_em
notare che se la definisco
global d_em as date
mi da
http://img560.imageshack.us/img560/6962/acquisizioneaschermoint.png
Qualcuno saprebbe dove può essere l'errore e come fare per farlgielo
scrivere?
N.B.
ovviamente se scrivessi la data direttamente nella tabella il problema
non si porrebbe, ma mi sembrava meglio così per poter fare il test
sulle date prima di scrivere e poi vorrei comunque capire se uso
metodi sbagliati...
Grazie, Riccardo
Vado a memoria ...
La data in hsqldb va introdotta in un formato tipo questo:
2010-12-21
> Grazie, Riccardo
Prego (sempre che l'abbia azzeccata)
> La data in hsqldb va introdotta in un formato tipo questo:
>
> 2010-12-21
Che dovrebbe chiamarsi ISO 8601. E' anche l'unico formato che nelle
versioni recenti di Calc � accettato come conversione automatica stringa
> data delle formule.
--
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Scarica "OpenOffice.org 3: Soluzioni a raccolta", molto pi� di semplici
FAQ! http://it.openoffice.org/doc/manuali/
vi ringrazio, ma io vorrei che fosse la macro a scrivere la data dopo
averla letta; devo quindi usare qualcosa tipo data=format(d_em, "yyyy-
mm-dd")?
bontà divina funzionaaaaaa! Vi devo una birra. Grazie davvero ci ho
passato su tanto di quel tempo....
ho usato questo sistema:
anno=mid(d_em,1,4)
'anno=year(d_em)
mese=mid(d_em, 5,2)
giorno=mid(d_em, 7,2)
data= anno & "-" & mese & "-" & giorno
sinsert = " update ""T_Dati_verbale"" set ""Data"" = '"& data &"'
where ""ID_gen"" = '"& numero_generale_verbale &"' "
ricordo un post di Roberto Montaruli in cui ritieneva un pò
inaffidabile estrarre e rimescolare la data in quel modo, perchè
dipende dalle impostazioni del sistema in uso, ma se faccio
anno=year(d_em)
print anno
mi restituisce 9999
come si può fare allora ad applicare quella funzione in modo corretto?
Dunque vediamo un po' il tuo codice.
data=oForm.GetByName("data_emissione")
d_em=data.date
print "emissione:" + d_em
E qui ti appare emissione:20101113
Solo che quel 20101113 che cos'e'? Una data o una stringa?
la variabile data, che inizializzi con
data=oForm.GetByName("data_emissione")
di che tipo e'?
Deve essere di un tipo particolare visto che possiede una
proprieta' .date
Poi tu assegni data.date ad una variabile d_em che e' quella che poi
visualizzi.
E anche questa d_em di che tipo e'?
Da qualche parte nell'oggetto "data_emissione" o nelle variabili
coinvolte in seguito, ci deve essere un oggetto di tipo data, non
stringa, ma data, un qualcosa che ti permetta di ricavare facilmente
il giorno, il mese, l'anno, il giorno della settimana, etc...
E' da quell'oggetto che devi partire, non dalla stringa che e' una
mera rappresentazione del dato secondo un formato impostato chissa'
dove.
Adesso ci provo io a mettere in una form di calc quel coso col
calendario e poi ti dico.
credo che questo sia il punto: immetto una data (selezionandola dal
calendarietto) e poi il print restituisce quella stringa
>
> la variabile data, che inizializzi con
> data=oForm.GetByName("data_emissione")
> di che tipo e'?
il controllo "data_emissione" è definito come campo data; perciò io
credo che debba essere riconosciuto come data...no?
>
> Deve essere di un tipo particolare visto che possiede una
> proprieta' .date
>
> Poi tu assegni data.date ad una variabile d_em che e' quella che poi
> visualizzi.
> E anche questa d_em di che tipo e'?
d_em la definisco come
global d_em
anche perchè se definisco
global d_em as date
mi restituisce una serie di caratteri senza significato
>
> Da qualche parte nell'oggetto "data_emissione" o nelle variabili
> coinvolte in seguito, ci deve essere un oggetto di tipo data, non
> stringa, ma data, un qualcosa che ti permetta di ricavare facilmente
> il giorno, il mese, l'anno, il giorno della settimana, etc...
>
> E' da quell'oggetto che devi partire, non dalla stringa che e' una
> mera rappresentazione del dato secondo un formato impostato chissa'
> dove.
>
> Adesso ci provo io a mettere in una form di calc quel coso col
> calendario e poi ti dico.
grazie anche a te per il tempo che ci metti
Quindi è una stringa ...
Trattala come tale e vivi felice.
Sarebbe tuttavia interessante sapere se esiste un oggetto di tipo data
e operare su quello.
Ieri sera ho provato a cercare quel calendario da usare come selettore
di data ma non l'ho mica trovato.
Nel basic di OpenOffice c'e' la funzione Now che ritorna la data di
sistema, e usando le funzioni Year(Now), Month(Now), Day(Now) e'
possibile ottenere anno mese e giorno.
Possibile che non vi sia un oggetto di formulario in grado di
restituire un oggetto di tipo data?
Perche' una volta trasformato in stringa si perde un sacco di
informazione.
> Ieri sera ho provato a cercare quel calendario da usare come selettore
> di data ma non l'ho mica trovato.
si deve messere si alla proprietà "apribile" del controllo data:
http://img844.imageshack.us/img844/7582/acquisizioneaschermointn.jpg
>
> Nel basic di OpenOffice c'e' la funzione Now che ritorna la data di
> sistema, e usando le funzioni Year(Now), Month(Now), Day(Now) e'
> possibile ottenere anno mese e giorno.
quando compilo il verbale nello stesso giorno della seduta va bene, ma
non è sempre così....spesso devo indicare una data precedente
> Possibile che non vi sia un oggetto di formulario in grado di
> restituire un oggetto di tipo data?
non lo so....:-(
Ho trovato questa pagina:
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Basic/Date_Field
Direi che chiarisce tutto.
La proprieta' .Date di quell'oggetto li' contiene una stringa in
formato ISO che rappresenta la data, in formato YYYYMMDD
Ci sono due funzioni: CDateToIso() e CDateFromIso() che servono per
gestire la data.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Basic/Date_and_Time_Functions
CDateToIso vuole come argomento un oggetto data, tipicamente la
funzione Date(), e ritorna una stringa in formato YYYYMMDD
Invece la CDateFromIso() vuole come oggetto la stringa YYYYMMDD,
restituita da quel calendario per esempio, e la trasforma in un
oggetto di tipo data, dal quale e' possibile estrarre Year() Month()
Day() e tutto il resto, in modo piu' preciso che manipolando
beceramente la stringa.
Veramente leggo tipo 'long'.
Strano ...
O riccardor ha omesso di copiare una trasformazione in stringa della
data nel suo codice oppure viene da chiedersi come hanno fatto a
funzionare le funzioni di elaborazione di stringa.
Perfetto, CDateFromIso() è la soluzione; ad esempio:
....oForm = ThisComponent.DrawPage.forms.Dati
data=oForm.GetByName("data_emissione")
d_em=data.date
anno_emissione=Year(CDateFromIso(d_em))
print anno_emissione
.....
http://img251.imageshack.us/img251/2452/acquisizioneaschermointh.png
in effetti non ho fatto (almeno non consapevolmente ...) nesuna
trasformazione in stringa; d_em la ricavo così:
...
oForm = ThisComponent.DrawPage.forms.Dati
data=oForm.GetByName("data_emissione")
d_em=data.date
.....
poi applicavo
...
anno=mid(d_em,1,4)
mese=mid(d_em, 5,2)
giorno=mid(d_em, 7,2)
...
e restituiva rispettivamente (ad es.) 2010 , 11 , 15
Forse perchè ho definito
global d_em (senza dire "as date") ?
Riserviamoci di fare i necessari approfondimenti, ma ricordo che
qualcuno sosteneva: "non importa che il gatto sia bianco oppure nero,
l'importante è che prenda il topo..."
O ancora meglio:
d_em=CDateFromIso(oForm.GetByName("data_emissione").date)
YYYY=Year(d_em)
...
Le variabili si usano quando servono.
Se non servono, si puo' scrivere anche in modo piu' compatto.
Con questo approfondimento, ho imparato pure io che esiste
CDateFromIso() e CDateToIso().
In questo caso che prenda il ... tipo ...
Battutaccia da quattro soldi :-)
Udite ... Udite
Sub Main
dim a as double
a=45.7856
print left(a,2)
print a*2
End Sub
Provare per credere ... strano eh?
Non vedo nulla di strano.
pablo
la cosa strana è che left agisca anche su una variabile tipo double
( e non una string) ? Le mie (poche) certezze vacillano....
Sar� ... ma io ho sempre pensato che anche l'argomento dovesse essere
una stringa.
Non c'è nulla di strano, Left agisce su una stringa in effetti.
E' l'interprete basic che effettua una conversione implicita della
variabile double prima di passarla alla funzione Left
Questo succede anche in VB e in VBA.
In effetti questa gestione "intelligente" dei tipi di variabile è molto
comoda perchè consente di evitare un sacco di codice per le conversioni
di tipo esplicite, ma non deve mai mancare la consapevolezza di quello
che accade dietro le quinte.
Ecco un paio di variazioni sul tema che mostrano il comportamento
polimorfico dell'operatore +
Print 2 + Left(45.1234, 2)
Print Left(45.1234, 2) + 2
Infine ecco un comportamento davvero inconsueto:
Print "True" = True
;)
ciao
pablo
> In effetti questa gestione "intelligente" dei tipi di variabile è molto
> comoda perchè consente di evitare un sacco di codice per le conversioni
> di tipo esplicite,
A me me pare una str....! (cit.)
> ma non deve mai mancare la consapevolezza di quello
> che accade dietro le quinte.
L'unico modo sicuro per non far mancare mai la consapevolezza e'
quello di PRETENDERLA.
Le conversioni di tipi e i cast devono a mio parere essere SEMPRE
richiesti.
Si ... va bene ... ma allora ditelo ...