[Excel] Het grote Excel vragen topic #40

Ik heb enige tijd geleden de volgende procedure geschreven zodat gebruikers met hun poten vingers afblivjen van mijn pivot tables.

Na het runnen van deze procedure kan je nagenoeg niets meer met alle pivots in je workbook.

Wow!
En dit werkt ook in de Nederlandse versie van Excel?
Waar kan ik ook alweer vinden om een macro te openen?

Ja. ALT+F11.

Als ik dit rechtstreeks in de macro-ding plak, wordt het rood en gebeurt er niets.
Als ik dan op F5 druk, krijg ik een pop-up dat ik een sub moet aanmaken.
Wat doe ik verkeerd?

quote:

Op donderdag 8 mei 2014 11:41 schreef DaviniaHR het volgende:
Als ik dit rechtstreeks in de macro-ding plak, wordt het rood en gebeurt er niets.
Als ik dan op F5 druk, krijg ik een pop-up dat ik een sub moet aanmaken.
Wat doe ik verkeerd?

Zo werkt het bij mij wel..

Als ik het in kopieer krijg ik nu de foutmelding "Complieerfout: verwacht: insructie-einde
En ik krijg het als 1 regel, niet met die tabs erbij. Is dat erg?

EDIT: Dan springt de cursos ook naar de eerste "dim" (van Dim WS As Worksheet)

[ Bericht 21% gewijzigd door DaviniaHR op 08-05-2014 13:54:40 ]

Als 1 regel? Hoe kopieer je die code dan?

http://www.mijnbestand.nl/Bestand-OBWTR84NMQRG.xlsm

Ah, ik heb de code nu goed ingekopieerd.
Maar nu kan ik ook de waardes van de rapportfilters niet meer instellen?
Of de waardes sorteren?

Ik zei toch dat je nagenoeg niets meer kan doen?

Ik heb een vraag wat misschien heel simpel op te lossen is, maar ik weet het niet.
Ik heb een Excel 2007 document met verder alleen maar tekst, wat 1,5 mb groot is.
Vergelijkbare documenten zijn normaal maar iets van 30 of 40 kb.

Volgens mij zit er een verborgen bestandje in ofzo wat voor die 1,5 mb zorgt, hoe kan ik dit zien ?

Veel spaties op tabs aan het einde van de regel?

Hoe kan ik dat zien

Is het niet heel stiekem een gedeeld werkboek of iets dergelijks? Laatst op het werk begon iemand ook al te zeuren een bestand dat steeds maar groter werd.

Bleek het een gedeeld werkboek te zijn waarbij de wijzigingen worden bewaard...

Mogelijk zijn er ook tabbladen verborgen waar veel data in staat.
Afbeeldingen doen het ook altijd goed.

Als het een *.xlsx is, dan kun je *.xlsx veranderen in *.zip en dan unzippen(vergeet niet een copy te maken van je originele bestand!).
Dan kun je misschien nog info vinden over wat de oorzaak is van de grootte van het bestand.

quote:

Op donderdag 8 mei 2014 15:10 schreef sylvesterrr het volgende:
Ik zei toch dat je nagenoeg niets meer kan doen?

Is er een regeltje in de sub die ik kan ewghalen waardoor je wel de rapportfilters kunt instellen?
Niet nieuwe filters inslepen, maar wel op het knopje drukken, zeg maar?

quote:

Op vrijdag 9 mei 2014 12:51 schreef DaviniaHR het volgende:

[..]

Is er een regeltje in de sub die ik kan ewghalen waardoor je wel de rapportfilters kunt instellen?
Niet nieuwe filters inslepen, maar wel op het knopje drukken, zeg maar?

Dat durf ik zo 1,2,3 niet te zeggen. Mijn gebruikers mogen de standaardfilters niet gebruiken vanwege de vele pivot tables die ik filter met behulp van slicers.

Oke, helder.
Bedankt voor je hulp iig

quote:

Op vrijdag 9 mei 2014 12:51 schreef DaviniaHR het volgende:

[..]

Is er een regeltje in de sub die ik kan ewghalen waardoor je wel de rapportfilters kunt instellen?
Niet nieuwe filters inslepen, maar wel op het knopje drukken, zeg maar?

regel 15
PF.EnableItemSelection = isAllowed
Die weghalen

quote:

Op zaterdag 10 mei 2014 14:31 schreef Holy_Goat het volgende:
Lieve mensen.

Waarom de fuck gebeurt dit?
[ afbeelding ]

Ik verwacht gewoon 0.03 als antwoord.

Wel via een omweg opgelost nu, maar slaat echt nergens op
[ code verwijderd ]

Zit er zo een onnauwkeurigeheid in?

Het is maar wat je als zo'n grote onnauwkeurigheid beschouwd (0,00000000000116415210804632
). Het simpele antwoord is gewoon, ja Excel voldoet hierbij aan de internationaal geaccepteerde standaard voor het gebruik van floating point.

Het opslaan van decimalen in een binair getal is zeer ingewikkeld. Ze hebben hiervoor een systematiek bedacht om het toch in 64 bit (of 8 bytes) op te slaan. Wat ze hiervoor doen is je decimale getal omzetten naar de dichtstbijzijnde floating point dat op 15 decimalen nauwkeurig werkt. Door de output af te ronden in je scherm, heb je dit normaal niet door.

Het echte antwoord is eigenlijk dus ja, er zit onnauwkeurigheid in. Zodra je een breuk hebt (je input in dit geval), dan is dit per definitie al een floating point en dus onnauwkeurig. Het zal bijna nooit mis gaan, net zoals je je output in je eerste macro op 2 decimalen had kunnen afronden.

returnsdecimals = Round(value - Round(value), 2)

[ Bericht 5% gewijzigd door snabbi op 10-05-2014 18:09:03 ]

je vergeet dat er ook naar boven kan worden afgerond.

quote:

Op zaterdag 10 mei 2014 19:10 schreef Speculant. het volgende:
je vergeet dat er ook naar boven kan worden afgerond.

returnsdecimals = Round(value - Application.WorksheetFunction.Floor(value, 1), 2)

quote:

Op zaterdag 10 mei 2014 22:17 schreef Holy_Goat het volgende:
Maarem, waarom gaat het dan fout in mijn eerdere voorbeeld?

Voor ons is het net alsof je 3100,03 - 3100 doet. Dit is 0,03
Voor de computer is het echter 3100,02999999988358 - 3100
Dit komt doordat de computer dus de dichtsbijzijnde floating point weergave zoekt die 3100,03 benaderd. 3100 hoeft hij niet te benaderen, want alleen decimalen en getallen groter dan 15 cijfers moeten worden benaderd.

Nu weet de computer wel dat hij 3100,02999999988358 moet weergeven als 3100,03, maar dat is niet zo voor 0,02999999988358. 0,03 heeft namelijk een andere floating point representatie, deze is bijvoorbeeld 0,030000001344.
_{PS ik ben te lui geweest om de echte getallen er bij te zoeken}

Door het rekenen met de andere getallen die niet als floating point hoeven weergegeven te worden, verliest de computer de type weergave uit het oog.

[ Bericht 2% gewijzigd door snabbi op 11-05-2014 10:21:36 ]