Newsgroup: it.comp.appl.access
Titolo: Formattazione controlli sottoreport

Situazione:
ho un report principale, nel quale visualizzo alcuni dati. Il report
contiene un sottoreport (senca campi legami), che legge i dati da una query.
Per mie esigenze, queste query contiene, nella prima riga, le etichette dei
campi e dalla seconda in poi i dati.
Ora, il sottoreport dovrebbe formattare in maneira diversa, rispetto alle
altre, la prima riga.
Per farlo, ho gestito l'evento "Su formattazione". All'interno dell'evento,
ho dichiarato una variabile statica che incremento di volta in volta (solo
se il FormatCount=1).
Se la variabile è uguale a 1, formatto i controlli (grassetto), altrimenti
li lascio come sono (in realtà imposto il grassetto a 0, altrimenti eredito
l'ultima formattazione, cioè il grassetto).
Bene, aprendo il sottoreport, da solo, tutto funziona. Se apro il report
principale, non ottengo errori, ma la formattazione viene totalmente
ignorata.
Qual è il motivo? Qualcuno sa rispondere?
Grazie in anticipo.

 ignorata.
Che intendi con "tutto funziona"?
A parte il fatto che non puoi impostare il grassetto in modo diverso da una
riga all'altra, col codice che descrivi ottieni semplicemente delle righe
non in grassetto. Vuoi dire che quando non funziona ottieni tutte righe in
grassetto?
Sib

 grassetto?
No, restano normali (altrimenti non avrei scritto "la formattazione viene
totalmente ignorata").
E, cmq, ti do una notizia: in una report puoi formattare diversamente le
righe!!!
Che notizia, eh?
Non è che forse ti stai confondendo con le maschere continue?
Ciao, Andrea... che non capisce questo livore nei suoi confronti.

Avevo intenzione di risponderti punto per punto, ma essendo principalmente
una persona pacifica preferisco una risposta meno "puntuale".
Prima di tutto datti una calmata che qui nessuno ha niente contro nessuno.
Qui se si risponde lo si fa semplicemente per spirito di collaborazione.
Puo' capitare che a volte uno abbia poco tempo per rispondere e si esprima
in modo brusco o cada in errore senza che per questo chicchessia possa
attribuirsi il diritto di sbraitare.
La mia risposta puo' esserti sembrata aggressiva, ma non voleva esserlo.
Effettivamente sono caduto in errore nel dire che non potevi formattare in
modo diverso le righe. Il mio errore e' stato causato dal fatto che la
routine sotto, che ho usato per fare le prove, non funziona senza la stringa
s.
Il motivo e' semplice, ogni sezione puo' generare l'evento "SuFormattazione"
piu' di una volta per ogni sezione, quindi bisogna impostare nuovamente a
bolt i controlli quando si riverifica
l'evento. Controllando in qualche modo (nel mio caso piuttosto grossolano)
il riverificarsi dell'evento formattazione, ho fatto funzionare
correttamente la routine.
Non conosco la tua di routine, ma verifica che formatti i controlli ogni
volta che l'evento SuFormattazione si verifica, poiche' aprendosi come
sottoreport l'evento si verifichi piu' volte che aprendo direttamente il
report.
A titolo di mero esempio ecco la routine che ho usato.
Static a As Integer
Static s As String
a = a + 1
If a = 1 Or s = Me.aaa Then
    Me.aaa.FontBold = True
    s = Me.aaa
Else
    Me.aaa.FontBold = False
End If
Ad ogni modo ti ribadisco che e' un errore usare i primi campi come nomi, su
questo non sussiste dubbio.
Sib
--
----------------------------------------------------
la mia home:
http://digilander.iol.it/syb
----------------------------------------------------
il sito comune di it.comp.database.access:
http://www.sitocomune.com
----------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

 questo non sussiste dubbio.
Alternative?

Questa è la mia routine che, come ho già scritto nei msg precedenti, già
prevede la formattazione forzata nei due casi (prima riga e altre righe),
visto che, formattando una riga in un modo, quelle che seguono seguirebbero
la stessa formattazione. Potrei gestire solo il caso dove Riga=1 e Riga=2,
per ridurre l'elaborazione, ma dovrò poi gestire la lettura facilitata,
quindi ilcodice va bene così.
Ad ogni modo, continuo a non riuscire a farlo funzionare quando inserisco
questa report all'interno di un'altra, eppure il codice non è molto diverso
dal tuo (a differenza, c'è solo l'enumerazione dei controlli, perchè io li
devo formattare tutti, non uno singolo):
Private Sub Corpo_Format(Cancel As Integer, FormatCount As Integer)
    Static Riga As Integer
    Dim oCtl As Control
    If FormatCount = 1 Then
        Riga = Riga + 1
    End If
    For Each oCtl In Me.Controls
        If Riga = 1 Then
            oCtl.FontBold = True
        Else
            oCtl.FontBold = False
        End If
    Next
End Sub

 End Sub
E anche l'errore e' lo stesso che facevo io.
Quando apri un report come sottoreport di un'altro, succede che l'evento
SuFormattazione si verifica piu' volte per la stessa sezione, in questo
caso, la seconda volta che si verifica l'eventola variabile Riga sara' >1 e
quindi anche la prima riga del sottoreport verra' impostata a normale.
Questo non succede nel report aperto da solo perche' li' l'evento si
verifica una sola volta.
Prova a fare una cosa diversa. Se hai una chiave primaria, la prima riga
avra' un identificatore univoco. In tal caso puoi scrivere:
If IDRiga=IDPrimaRiga then
    For each ctl in me.controls
        Grassetto
    next ctl
else
    for each...
        Normale
    next ctl
end if
Sib

"koo" <koo@k.k> ha scritto nel messaggio news:9o47s6$cfb$1...@serv1.iunet.it...

Dovresti sempre usare i nomi di campo come intestazioni. Oltretutto anche le
autocomposizioni di report e affini partono da questo presupposto.
Sul come poi ottenere i risultati desiderati ci si studia sopra, dipende da
cio' che si vuole ottenere.
Sib

"koo" <koo@k.k> ha scritto nel messaggio news:9o47s6$cfb$1...@serv1.iunet.it...

Scusate l'intrusione.
Immagino che tu possa in qualche maniera riconoscere la prima riga della
query che è origine record del sottoreport dalle altre righe.
Io filtrerei il sottoreport in maniera che utilizzi tutte le righe della
query tranne la prima; avrei così evitato tutti i problemi connessi alla
formattazione differenziata delle varie righe del sottoreport.
Quindi nel Corpo del report principale inserirei delle labels (etichette) e
le posizionerei in maniera adeguata sopra alle colonne del sottoreport; a
fronte dell'evento "Su formattazione" del Corpo del report principale
imposterei la proprietà Etichette (Caption) delle labels, usando delle
funzioni DLookup che prelevano i dati necessari dai campi della prima riga
della tua query.
Se poi non è possibile riconoscere in maniera univoca la prima riga della
query (quella con le intestazioni) dalle altre righe (ma non credo),
sdoppierei la query in due query; la prima dovrebbe contenere solo i valori
delle colonne e la userei come origine record del sottoreport; la seconda
dovrebbe contenere una sola riga con le intestazioni delle colonne e la
userei come dominio delle funzioni DLookup.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 avra' un identificatore univoco. In tal caso puoi scrivere:
Ok, grazie: ottima soluzione. Il proverbiale uovo di Colombo! :-)
L'alternativa che chiedevo nel msg precedente, io non la trovo, se non
utilizzando espedienti come quelli proposti da Roberto o come quelli che ho
adottato io.
Ti posso garantire che ho pensato a come evitare ciň: in tanti anni che
lavoro con Access, non mi č mai capitato di dover ricorrere a questa
soluzione, ma, in questo caso, non ho trovato alternative.
Ciao.

 della tua query.
CUT
Ciao Roberto,
Forse non hai letto il 3d dall'inizio, ma e' una scelta volontaria quella di
koo di usare la prima riga per le intestazioni, che senso ha che la vada a
togliere?
E' questo il motivo per il quale abbiamo "litigato", perche' io sostenevo
che trattava la cosa in modo errato.
Ciao
Sib

 soluzione, ma, in questo caso, non ho trovato alternative.
Non ho modo di obiettare oltre, non conoscendo il tuo problema.
Magari leggendoci ancora capiro' meglio cosa devi ottenere e si vedra'.
Ciao
Sib

 Magari leggendoci ancora capiro' meglio cosa devi ottenere e si vedra'.
Io ho n query che elaborano dei dati (praticamente, ho sempre due colonne
(con nomi diversi, a seconda dei dati elaborati). La prima rappresenta le
etichette di un grafico, la seconda i valori.
Nel classico esempio di un grafico:
Sesso    Totale
Maschi    324
Femmine    643
Boh?    22
Di queste query ne ho una ventina circa.
Ora, per poter visualizzare altrettanti grafici dentro una report, le scelte
erano due:
1. Fare n report
2. Fare una sola report che, da codice, andasse a prelevare i dati
Ho optato per la seconda opzione (probabilmente, perdendo più tempo di
quanto ne avrei perso scegliendo la prima).
Ora, per il grafico da isnerire nella report, non avrei avuto problemi,
associando la query opportuna. Ma già qui sorgevano dei problemi: da codice,
non è possibile cambiare l'origine record di un controllo. A questo ho
ovviato creando una sola query e modificando, prima di aprire la report, la
stringa SQL, in base alla query d'origine dei dati (i grafici sono
parametrizzati in base ad un codice e, le query, hanno dei nomi tipo
QRY_GRAPH_001, dove, gli ultimi tre caratteri, rappresentano il codice).
Il problema grafico, quindi, era risolto.
Restava il problema di far visualizzare, nella report, i dati d'origine del
grafico.
Ho pensato di fare qualcosa si simile (visto che, anche per le sottoreport,
anzi, a maggior ragione, non è possibile modificare l'origine record):
quindi faccio puntare la sottoreport alla stessa query del grafico.
Problema: se i nomi dei campi cambiano da grafico a grafico, come faccio a
modificare l'origine dei controlli delle due colonne? Semplicemente, non
posso.
Le alternative,quindi, erano nuovamente due: modificare da codice la
struttura della report (o usare la soluzione di Roberto), oppure creare una
query con due colonne (chiamate sempre allo stesso modo: FLD001, FLD002) e
visualizzare, al suo interno, sia le etichette, sia i dati.
La prima alternativa non mi piaceva perchè richiedeva un accesso alla
struttura del report, cosa che mi spaventasempre un po'.

 Sib
Ciao
Roberto

 Forse ci saranno soluzioni migliori, ma a me č venuta in mente questa.
Non e' che la tua soluzione non fosse valida ma, giustamente, riportava la
situazione ad una normale query in cui i nomi di colonna sono quelli del
campo. Tanto varrebbe, allora, non usare affatto la prima riga ma usare i
nomi di campo.
O no?
Mi sono confuso?
Sib


Ciao
Roberto

"koo" <koo@k.k> ha scritto nel messaggio news:9o77be$7nl$1...@serv1.iunet.it...

C'è una tua affermazione che non condivido; tu dici che non è POSSIBILE da
codice VBA cambiare la proprietà Origine record (RecordSource) di un report
o di un sottoreport e che non è POSSIBILE modificare la proprietà Origine
controllo (ControlSource) di un controllo di un report o di un sottoreport.
A me risulta il contrario, confortato anche dagli esempi riportati dall'help
relativamente alle due proprietà di cui sopra; allo stesso modo in cui è
possibile farlo per le maschere e le sottomaschere.
Se il report lo apri da una maschera che contiene una combo con la quale
selezioni un valore diverso a seconda della query che vuoi venga usata, a
mio parere a fronte dell'evento "Su apertura" del report o del sottoreport
puoi generare delle righe di codice VBA che, analizzato il valore
selezionato dalla casella combinata, impostino adeguatamente la proprietà
RecordSource del sottoreport e le proprietà ControlSource dei suoi
controlli; oppure, se la query ha sempre lo stesso nome, impostando solo le
proprietà ControlSource dei controlli.


 proprietą ControlSource dei controlli.
Facciamo la distinzione fra RecordSource e ControlSource.
Il primo č l'origine dati di un oggetto, quale potrebbe essere una maschera,
una combo (anche se sarebbe RowSource, in questo caso), un'oggetto MSGraph o
altro oggetto/controllo, capace di "mangiare" dei dati e, eventualmente, di
elaborarli.
Il secondo č il dato associato ad un controllo, utilizzato per la
visualizzazione o modifica, ma che, per quanto ne so io, č sempre e solo UN
valore.
Cito dall'help (che secondo me non č preciso, perņ):
Proprietą OrigineControllo (italiano)
Proprietą ControlSource (inglese)
Č possibile utilizzare la proprietą OrigineControllo per specificare quali
dati vengono visualizzati in un controllo. Č possibile visualizzare e
modificare dati associati ad un campo di una tabella, di una query o di
un'istruzione SQL. Č anche possibile visualizzare il risultato di
un'espressione. Per un livello di gruppo di report, la proprietą
OrigineControllo determina il campo o l'espressione in base a cui effettuare
il raggruppamento.
Proprietą OrigineRecord (italiano)
Proprietą RecordSource (inglese)
Č possibile utilizzare la proprietą OrigineRecord per specificare l'origine
dei dati di una maschera o report. Č possibile visualizzare dati di una
tabella, di una query o di un'istruzione SQL. Per visualizzare e modificare
dati della tabella Impiegati di una maschera, ad esempio, impostare a
Impiegati la proprietą OrigineRecord della maschera. Č quindi possibile
associare i controlli contenuti nella maschera o nel report a determinati
campi della tabella Impiegati impostando la proprietą OrigineControllo del
controllo al nome di un campo nella tabella. Č possibile, ad esempio,
associare un controllo al campo Cognome della tabella Impiegati impostando
la proprietą OrigineControllo del controllo a Cognome.
Ora, tornando al mio caso, in una report, io posso, da codice, modificare il
ControlSource di un controllo (e, cmq, non i tutti i casi), ma non il
RecordSource. Se non mi credi, provaci. Io non ci sono mai riuscito, se non
accedendo in struttura -sempre da codice-, al report stesso, prima di
aprirlo in anteprima (o in stampa).


Non è affatto vero che non si può cambiare da codice VBA il RecordSource di
un report. Per scrupolo ho provato e non ho avuto alcuna difficoltà a farlo.
Questo è il codice VBA che ho generato a fronte dell'evento "Su apertura"
del report:
Private Sub Report_Open(Cancel As Integer)
If Forms!Maschera3!Pippo = 1 Then
Me.RecordSource = "Query1"
Else
Me.RecordSource = "Query2"
End If
End Sub
e, a seconda che il controllo Pippo di Maschera3 avesse o meno il valore 1,
il report mi ha visualizzato le righe di Query1 o le righe di Query2.


 un report. Per scrupolo ho provato e non ho avuto alcuna difficoltà a
farlo.
Prova con una sottoreport...

"koo" <koo@k.k> ha scritto nel messaggio news:9oa8rk$fb$1...@serv1.iunet.it...

Ho provato.
Ho generato il codice VBA di cui il mio messaggio precedente a fronte
dell'evento "Su apertura" del sottoreport e tutto ha funzionata
perfettamente.



Ma "report" č maschile o femminile???
--
Alberto

 Ma "report" è maschile o femminile???
Maschile... prevalentemente :-)


 Ma "report" è maschile o femminile???
Maschile, anche perchè i sostantivi, in inglese, sono sempre maschili.
Quando uso Report al femminile è perchè penso al suo significato: stampa
(non letterale... letteralmente, suppongo significhi "rapporto", quindi
sarebbe sempre maschile)