Opmaak rapport

  • Onderwerp starter Onderwerp starter Risk
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
Ook goed. Was in de stellige overtuiging dat met de gegeven antwoorden mijn eerdere vraag was opgelost, tot ik vandaag tegen een onvoorzien probleem opliep. Omdat de vraag gesloten was een nieuwe gepost.

Risk
 
De vraag was niet gesloten. Vragen worden in principe niet gesloten. Behalve wanneer er regels worden overtreden en dat was niet het geval. Vraag was dus gewoon open.
 
De oplossing is dan wel niet in een boek te vinden, hij is daarom niet minder bruikbaar :).
1. In een willekeurige module definieer je de variabele.
Code: 
Public arr() As Variant
2. Op je formulier ga je hem vullen
Code: 
Private Sub Knop384_Click()
Dim i As Integer, iMax as integer
    iMax=15
    ReDim arr(iMax)
    For i = 0 To iMax
        arr(i) = Me("txtInput" & i)
    Next i
End Sub
3. Op het rapport lees je hem uit
Code: 
Private Sub Report_Load()
Dim i As Integer
For i = LBound(arr) To UBound(arr)
    Me("txtInput" & i) = Format(arr(i), "#,##0.00")
Next i
End Sub
Easy as ;)
 
Laatst bewerkt:
waarom public variables? Spagetti oplossingen, als je waardes uit het form in een report wil zetten... Haal dan de waarden van het formulier af OF zet ze in een (tijdelijke) tabel....
 
Nergens voor nodig, zoals ik hierboven met redelijk simpele code aantoon. Show me the spaghetti...
 
Michel,
Driftig zitten wijzigen.

Een module maken was even wat vreemd voor mij. Durfde e.e.a. niet in een "willekeurige"te zetten.

Heb gemaakt een module met een wizzard en die luidt:
Code: 
Option Compare Database

Public arr() As Variant

Ik denk dat die niet goed is.

Het rapport opende niet, ik heb de volgende code gemaakt waardoor wel het rapport opende maar de data niet meekomen.

Code: 
Private Sub Print_berekening_Click()
Dim i As Integer, iMax As Integer

  stDocName = "Rapport33"
    iMax = 15
    ReDim arr(iMax)
    For i = 0 To iMax
        arr(i) = Me("txtInput" & i)
    Next i
 DoCmd.OpenReport stDocName, acPreview
    DoCmd.Close acForm, Me.Form.Name
End Sub

In het rapport:

Code: 
Private Sub Report_Load()
Dim i As Integer
For i = LBound(arr) To UBound(arr)
    Me("txtInput" & i) = Format(arr(i), "#,##0.00")
Next i
End Sub

Ik hoor graag wat ik fout doe.

Risk
 
Ik snap niet wat er fout gaat. De Module kan echt elke willekeurige module zijn. Als je in het VBA venster staat, en je kiest <Invoegen>, <Module> dan ben je er al, want dan heb je een module die je kunt gebruiken. Ik wist niet dat daar een wizard voor nodig was :).
Modules zijn er, net als formulieren, in twee smaken: gebonden en niet-gebonden. Een gebonden module is bijvoorbeeld de codepagina van het formulier of rapport waarop je procedures zet. Dat gebruik je nu ook voor je formulier en rapport. Je vindt de gebonden modules onder het kopje <Microsoft Access Klassenobjecten>. Probleem daarmee is, dat je de procedures daarop (voor het gemak) alleen op dat formulier of rapport kunt gebruiken. Een public variabele die je op een formulier definieert, houdt dus de gegevens alleen vast zolang je op dat formulier bezig bent.
Wil je een procedure of functie op verschillende plekken gebruiken (denk aan volgnummers aanmaken) dan moet je die op een algemene module zetten. Die staan dan ook apart aangegeven in het VBA venster onder het kopje <Modules>. En een Public variabele daarop kun je gewoon bovenin declareren, zoals je nu ook gedaan hebt.
Nadeel van een public variabele: hij blijft gedurende de db open is zijn gegevens vasthouden. Vandaar deze code:

Code: 
    iMax = 15
    ReDim arr(iMax)
    For i = 0 To iMax
        arr(i) = Me("txtInput" & i)
    Next i
Met iMax leg je het aantal tekstvakken vast dat je wilt uitlezen. In het voorbeeld zijn dat er overigens 16, omdat de eerste waarde van een array standaard met 0 begint. arr(15) is dus het 16e element in de array.
Alternatieve techniek is dat je de array steeds opnieuw herdefinieert qua dimensie. Dat definiëren doe je dus met Redim. De opdracht ReDim arr(iMax) maakt derhalve een array variabele aan met 16 elementen. Daarbij 'poetst' Redim de variabele wel leeg, dus met ReDim arr(20) vergroot je de array, maar is hij wel weer leeg. Dus als je de eerder ingelezen waarden wilt behouden, maar de array wel wilt vergroten, moet je de opdracht veranderen in: ReDim Preserve arr(20).
Dat legt hopelijk iets meer uit hoe een array werkt.
Als de array is gevuld, en volgens mij doe je dat dus correct, kun je hem op het rapport weer uitlezen. En ook daar zie ik verder geen fouten in. Dus als het toch niet werkt, dan kunnen we ofwel een dag of wat gaan gokken, of je maakt een voorbeeldje :).
 
OctaFish zei:
Nergens voor nodig, zoals ik hierboven met redelijk simpele code aantoon. Show me the spaghetti...
Klik om te vergroten...

De spaghetti zit em in het feit dat als mensen eenmaal met Public variables aan de slag gaan, dit een begin zonder eind kan zijn.
Een database met 5000 public variables is een ramp ....

Public variables moet je zo spaarzaam mogelijk gebruiken...
 
We hebben het hier over één Public variabele. Dat zit dus nog 4999 variabelen van jouw 5000 af. Overdrijf je niet een klein beetje? Bovendien kun je de variabele na gebruik heel makkelijk nog leegmaken als je van een schoon bordje houdt.
 
Michel,

Allereerst dank voor je les.


Ik bemoei me niet in deze spaghetti-western met de schermutselingen, heb al genoeg aan het aan de praat krijgen van. Gaat mij ook veel te ver.

De code heb ik in een database gezet.

Vlgs. mij alles correct overgenomen. De module gemaakt (drukte op een knop en voor mij is alles een wizzard, blijf een leek)


Een set data komt uit een tabel, de rest is naar believen in te vullen en is niet gebonden aan iets. Is een voorbeeldje.

Bekijk bijlage Database TESTPRINT.rar :evil:

Werderom ter leering en den vermaeck.

Risk
 
Ik denk dat ik het komende uur even bij je uit de buurt ga blijven, want er zullen wel een paar muurtjes sneuvelen...
Risk zei:
In het rapport:

Code: 
Private Sub Report_Load()
Dim i As Integer
For i = LBound(arr) To UBound(arr)
    Me("txtInput" & i) = Format(arr(i), "#,##0.00")
Next i
End Sub
Klik om te vergroten...
Mits tenminste het voorbeeldje dat je net gepost hebt overeenkomt met je productiedb :)

Als je zegt: "In het rapport:" dan ga ik er vanuit de je de code ook daadwerkelijk in het rapport hebt gezet. In jouw voorbeeldje staat de code echter niet in het rapport, maar op het formulier. En dat gaat natuurlijk never nooit niet werken; zoals ik hierboven al heb uitgelegd, werkt code die binnen een object van de <Microsoft Access Klassenobjecten> valt, alleen binnen dat specifieke object. Een Report_Load kan dus alleen maar op een rapport draaien, nooit op een formulier. En vice versa.

En zoek nu maar een mooie muur op ;)
 
Je report_load sub... die staat in je FORM, niet in je REPORT...

Stop de code van je "Report_Load" sub in het even "On Load" van je report en het werk.

Snap ik nog steeds gewoon NIET waarom je dit zo moeilijk doet, als control source in je report kan je simpel weg zetten, respectievelijk:
=[Forms]![Inputformulier]![txtInput1]
=[Forms]![Inputformulier]![txtInput2]
=[Forms]![Inputformulier]![txtInput3]

Kan je meteen afscheid nemen van de onzinnige namen van je controls en ze "gewoon" txtInkoop, txtVerkoop etc noemen

Bovendien heb je als bron hieraan nog steeds het simpele tabelletje, dus kan je het "gewoon" zoals ik al zei ook uit het tabelletje halen en alleen de ID "overgooien"
 
@namliam:
Of iemand Public variabelen nodig heeft of niet, kunnen wij op afstand nooit bepalen. Er is niks tegen op het gebruik van Public variabelen, zolang je maar weet wat je doet. Mensen die maar wat aanprutsen (en dat suggereer je een beetje) moet je sowieso ver van een database afhouden. Neemt niet weg dat er meerdere wegen naar een goede oplossing leiden, en ik zou zeggen: pak vooral een oplossing die bij jou past :)
 
namliam zei:
Kan je meteen afscheid nemen van de onzinnige namen van je controls en ze "gewoon" txtInkoop, txtVerkoop etc noemen
Klik om te vergroten...
Op het moment dat je (bijvoorbeeld met een dynamisch formulier of rapport) meerdere controls dynamisch wilt vullen, heeft het wel degelijk zin om ze een standaardnaam + volgnummer te geven. Je kunt dan met een simpele loop de gegevens ophalen in invullen. Dat werkt absoluut niet als je de objecten een herkenbare naam geeft. Dat heeft ook alleen maar nut als je die namen ergens voor nodig hebt. In het voorbeeldje gaat het om 3 velden, en dat kan op deze manier ook. Zijn het er 50, dan weet ik wel welke methode handiger is...
 
OctaFish zei:
Of iemand Public variabelen nodig heeft of niet, kunnen wij op afstand nooit bepalen.
Klik om te vergroten...
Waar, maar, in het algemeen zijn publics er voor zeer specifieke redenen....
Het zijn gewoon vuist regels, net zoals je (simpel) berekenbare informatie niet opslaat in een database... in sommige gevallen is het toch handig, waarom daarom, maar in het algemeen (99+% van alle gevallen) doe je het niet...

En ja, Bricoleur.... die zijn er veel te veel. Mensen moeten ergens beginnen, maar te veel bricoleur is wel de reden dan een eerbare tools als Access en zelfs Excel in veel bedrijven een slechte naam hebben omdat "er maar wat gedaan wordt" inplaats van een "deugdelijke" oplossing te maken
 
Overigens (dit weer voor TS) heb ik net een testje gedaan met een Openargs met 20000 elementen, en een totale lengte van 178484 tekens. Me dunkt dat je dat een stevige string kunt noemen. Geen enkel probleem.... Mag ik er vanuit gaan dat deze hele draad overbodig was, omdat TS de code niet op het rapport had gezet? In welk geval je noch een Public variabele nodig hebt, noch extra tabellen dan wel rechtstreekse verwijzingen naar een openstaand formulier :). Ach, zeggen we dan: het hield ons van de straat en uit de kroeg ;)
 
Michel,

Ik heb weer beeld. Werk het rapport bij en kijk of het lukt. Wordt niet meer vandaag. Hou dit lijntje open. Snap de polemiek niet helemaal, maar mocht het leiden tot iets waar ik wat aan heb, ga gerust verder stoeien. Mijnmuren staan overigens nog, ging vrij soepel, uiteraard: de fout lag bij mij.

Risk
 
Risk zei:
Snap de polemiek niet helemaal
Klik om te vergroten...
Welkom bij de club :). Ik snap best dat helpers andere oplossingen vinden (prima natuurlijk, hoe meer smaken hoe beter) maar dat is nog geen reden om andere oplossingen neer te sabelen (al ben ik daar zelf ook een meester in, geef ik eerlijk toe). Maar goed, ik zou zeggen: kijk nog eens naar de oorspronkelijke oplossing met OpenArgs, want die is betrouwbaarder dan de Public variabele. Die werkt wel, maar het kan voorkomen dat die ineens leeg is. En dan heb je er natuurlijk niet zoveel aan. Ik heb ondertussen uitgezocht dat de OpenArgs van het type Variant is, en daar kun je een stevig boek in kwijt, mocht dat nodig zijn. Ik heb getest tot 20.000 variabelen, en dat ging prima. Bij 50.000 liep hij overigens stuk, dus de grenst ligt daartussen :).
 
Michel,
Polemieken laat ik langs mij gaan. Ik zoek naar een oplossing.

Je laatste opmerking. 50000 die haal ik niet, maar bij 20 liep die al vast. Zie eerdere opmerkingen ergens in dit topic. Wat is nu, door alle opmerkingen heen ben ik het spoor even bijster :eek:, de juister werkende code? Voor ik alles weer overhoop ga halen?

Ik hoor, dank.

Risk
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan