• Privacywetgeving
    Het is bij Helpmij.nl niet toegestaan om persoonsgegevens in een voorbeeld te plaatsen. Alle voorbeelden die persoonsgegevens bevatten zullen zonder opgaaf van reden verwijderd worden. In de vraag zal specifiek vermeld moeten worden dat het om fictieve namen gaat.

VBA marco debuggen. Hulp gewenst

Status
Niet open voor verdere reacties.

Jeroen1000

Gebruiker
Lid geworden
15 jan 2008
Berichten
40
Hallo iedereen,

Alles leek prima te werken tot ik een nogal bizarre fout opmerkte. In bijgesloten Winrar-achief zitten 2 modules (subroutines), 1 met code om het formulier aan te roepen (module2), en de andere met een subroutine om de berekeningen te maken(module1). Er zit ook 1 Userform bij, hetwelke paramters verschaft aan module1. Tenslotte zit er een Excel sheet bij, waarop de berekeningen plaats vinden.

Bij elke cel waarin een valuta staat (andere getallen worden met rust gelaten), wordt er 3% bijgetelt (3 invoeren in het percentagevak van het formulier zonder het '%' teken). Als bereik geef ik i1 tot o35 (de letter 'o', niet het cijfer) op (lege vakken worden natuurlijk ook met rust gelaten).

Alles gaat goed tot Excel aan de laatste rij begint (in het vet gedrukt). Het eerste bedrag van die rij (21.627,50 €) wordt nog correct ingelezen. Daarna worden er getallen gelezen die niet in de Excel sheet staan (dat kan je zien door de debugvariabelen die ik heb toegevoegd). Er staat 1 debug var voor de berekening om te zien of Excel wel met het juiste getal op de proppen komt. En 1 debug var na de berekening. De fout zit hem volgens mij in het feit dat Excel verkeerde getallen inleest. Waar hij ze vandaan haalt weet ik niet. Het gekste is dat dit enkel bij de laatste rij voorvalt. De rij niet in het vet gedrukt zetten helpt niet (wanhoopspoging:p).


Ontvlooien iemand?:D
 

Bijlagen

Waarom dat form en die modules apart, en niet binnen het Excel bestandje?
Graag een versie waar zowel het userform als de code binnen het Excel bestand staan.
 
Hier lijkt ie het goed uit te voeren op het eerste zicht. Kan je anders eens precies de handeling beschrijven waarbij het fout loopt, zo kan die gereconstrueerd worden.

Een paar meer algemene opmerkingen:

-Waarom een boolean var voor verhogen EN verlagen. Je kan ook werken met 1 var. Indien verhogen=false dan moet je verlagen uitvoeren.
-Je kan ook een refedit element toevoegen aan het userform. Dat dient juist om een bereik in te lezen. Bij verwijzingen moet je dan refedit aanvinken, en dan kan je die ook gebruiken.
-De manier waarop jij je bereik samenstelt kan problemen opleveren, er zit daar geen error checking laat staan handling op.
-Je bereik gaat altijd uit van de huidigesheet (activesheet), hoewel dan nergens in de code staat. Best is ook de naam van je sheet te zetten voor het bereik, dit kan fouten uitsluiten.
-De code om een nieuwe waarde te bereiken is wel juist, maar kan efficienter:
ipv: A=A+0.05A wat je hier eigenlijk doet kan je beter dit gebruiken A=A1.05. De uitkomst is gelijk maar nu moet Excel maar 1 keer A gaan ophalen. Zal nu niet zo veel maken in deze context maar bij zeer veel getallen gaat dat sneller werken.
 
Hier lijkt ie het goed uit te voeren op het eerste zicht. Kan je anders eens precies de handeling beschrijven waarbij het fout loopt, zo kan die gereconstrueerd worden.

Een paar meer algemene opmerkingen:
-Waarom een boolean var voor verhogen EN verlagen. Je kan ook werken met 1 var. Indien verhogen=false dan moet je verlagen uitvoeren.

Moet idd nog weg. Op het moment zelf wist ik er even een nut voor maar in de huidige vorm mag de variabele weg.
-Je kan ook een refedit element toevoegen aan het userform. Dat dient juist om een bereik in te lezen. Bij verwijzingen moet je dan refedit aanvinken, en dan kan je die ook gebruiken.
Handige tip, lijkt me beter als het er speciaal voor dient.
-De manier waarop jij je bereik samenstelt kan problemen opleveren, er zit daar geen error checking laat staan handling op.
Ik dacht dat VBA, in tegenstelling tot Java en .NET, geen try/catch/final ondersteunde?
Met die veronderstelling ben je als programmeur aangewezen op het zelf schrijven van doordachte error handling methodes. Deze macro is voor persoonlijk gebruik dus liet het (mss voorlopig) achterwege. Ik heb via de variabelen evenwel nagekeken of het bereik correct werd ingelezen.
-Je bereik gaat altijd uit van de huidigesheet (activesheet), hoewel dan nergens in de code staat. Best is ook de naam van je sheet te zetten voor het bereik, dit kan fouten uitsluiten.
Marco wordt steedds maar op één sheet gebruikt. Maar in het opzicht van ondubbelzinnigheid een zinnige :-) aanpassing.
-De code om een nieuwe waarde te bereiken is wel juist, maar kan efficienter:
ipv: A=A+0.05A wat je hier eigenlijk doet kan je beter dit gebruiken A=A1.05. De uitkomst is gelijk maar nu moet Excel maar 1 keer A gaan ophalen. Zal nu niet zo veel maken in deze context maar bij zeer veel getallen gaat dat sneller werken.

Bij het zoeken naar de fout heb ik alles in het lang en het breed gerekt. Ik probeerde maar iets. Wordt zeer zeker weer aangepast.


Nu om de handeling te reconstrueren:

  1. De eerste keer dat ik een sheet open, selecteer ik alle bedragen en markeer ze als valuta (Euro) met twee cijfers na de comma.
  2. Ik importeer mijn modules en het Userform
  3. Vervolgens voer ik de Marcro (module1) uit
  4. als beginbereik geef ik i1 in. Als eindbereik o35.
  5. De ontvlooimarkers in de sheet leren mij dat het bij het 2de getal (links te beginnen) van de rij in het vetgedruk misgaat. Daar toont hij iets anders. De volgende uitvoering van de lus toont wel het goede getal (maar eerst was er dus een getal dat niet in het rijtje thuishoorde).
  6. Alle je als bereik enkel de laatste rij ingeeft gaat het blijkbaar wel goed
 
Laatst bewerkt:
Beste Finch: problem solved! Blijkbaar ging het elke met de eerste sheet goed maar in de 2de (en volgend) sheets had men de kolommen automatisch gesomeerd. Dom dat ik dit niet opgemerkt had:o

Weer iets bijgeleerd:-):)
 
Beste Finch: problem solved! Blijkbaar ging het elke met de eerste sheet goed maar in de 2de (en volgend) sheets had men de kolommen automatisch gesomeerd. Dom dat ik dit niet opgemerkt had:o

Weer iets bijgeleerd:-):)


ook in het vb zaten som functies op de laatste rij (niet alle cellen), en ook daar deed hij wat er verwacht werd, maar ik wist niet dat die som er eigenlijk niet mocht staan.

Goed dat het opgelost is, en dank voor de terugkoppeling.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan