[VBA] gebruik van "lege" cellen met formule achter

[Jericho NutS]

Wat moet er gebeuren:
Controleer of cell (65+j,2) leeg is of niet
indien leeg ---> j+1
indien niet leeg --> bereken value

Probleem: in de cellen die "leeg of vol" zijn staat dit als code

code:

=IF($F$11>=A65;IF($F$11-A65<=$F$8;A65;"");"")

Ze zijn dus eigenlijk niet leeg maar met "" (als ik ze volledig wis dan werkt het wel maar dit is uitgesloten aangezien die functionaliteit moet blijven)

een tweede probleem situeert zich bij de combin functie
als j toeneemt wordt j op een bepaald moment groter dan (pickfaces-k)
echter het moment dat j groter wordt dan (pickfaces -k) is ook het moment dat de cellen uit (65+j,2) terug leeg zijn. Het wissen van de bovenstaande formule uit deze cellen (dus vanaf 65+j) verhielp dit echter niet.

Hopelijk heb ik het duidelijk genoeg weten te verwoorden en kan er mij iemand zeggen hoe ik dit kan oplossen.

code:

Sub test()

Dim j As Double
Dim lijnenperbatch As Double
Dim pickfaces As Double
Dim k As Double
Dim Value As Double

Value = 0

lijnenperbatch = Sheets("Parts-to-picker").Cells(8, 6).Value
pickfaces = Sheets("Parts-to-picker").Cells(11, 6).Value
k = Sheets("Parts-to-picker").Cells(65, 1).Value

For j = 0 To 250

If (Sheets("Parts-to-picker").Cells(65 + j, 2).Value = "") Then

End If

If (Not (Sheets("Parts-to-picker").Cells(65 + j, 2).Value = "")) Then

Value = Value + (WorksheetFunction.Power((-1), j) * WorksheetFunction.Combin(pickfaces - k, j) * WorksheetFunction.Power((1 - ((j + k) / pickfaces)), lijnenperbatch))

End If

Sheets("Parts-to-picker").Cells(60, 2) = Value

Next j
End Sub

[_js_]

.Text ipv .Value

[Dido]

offtopic:
Lees ik eroverheen, of kun je regels 19-21 vervangen door Else?

[pedorus]

_js_ schreef op donderdag 22 april 2010 @ 00:00:
.Text ipv .Value

.Formula

Dido schreef op donderdag 22 april 2010 @ 00:04:

offtopic:
Lees ik eroverheen, of kun je regels 19-21 vervangen door Else?

Lijkt me ontopic. Zo kun je regel 11 ook schrijven als "lijnenperbatch = ['Parts-to-picker'!F8]". Daarnaast is wat inspringing (tabs) wel handig, 1 tab voor iedere omliggend statement (zoals sub, for en if). Dan is het allemaal een stuk beter leesbaar.

Ik snap eigenlijk niet waarom je hier VBA voor gebruikt, en niet gewoon een paar hulpcellen en wat formules?

offtopic:
Gebruik [code=vb]

[RobIII]

Waar hoort mijn topic?
PRG >> OFF

[Jericho NutS]

de .text zorgde ervoor dat het werkte
.formula bleef foutmelding geven
bedankt ook voor de tip over het else statement, is uiteraard beter

wat is het voordeel van lijnenperbatch = ['Parts-to-picker'!F8] ?
en heb dit ook gedaan voor pickfaces en k maar de functionaliteit lijkt mij dezelfde

@mod mijn volgende vragen komen wel bij prg office, excuses

[pedorus]

jonbeton1 schreef op donderdag 22 april 2010 @ 08:45:
de .text zorgde ervoor dat het werkte
.formula bleef foutmelding geven

Vreemd, het verschil tussen .Text en .Value is dat de een readonly is en is opgemaakt, dus bijvoorbeeld het aantal decimalen kan anders zijn. Als de waarde bijvoorbeeld 11.3214 is, het formaat 2 decimalen is, dan is de .Text "11.32". Bij "" valt er vaak weinig op te maken.

wat is het voordeel van lijnenperbatch = ['Parts-to-picker'!F8] ?
en heb dit ook gedaan voor pickfaces en k maar de functionaliteit lijkt mij dezelfde

Er is ook alleen maar een verschil in leesbaarheid, niet in functionaliteit.

[Verwijderd]

zoals pedorus opmerkt, dit had ook zonder vba opgelost kunnen worden.

het else statement is ook overbodig, regel 17 tem 19 kan je gewoon weglaten aangezien er geen opdracht uitgevoerd hoeft als de cel leeg is.

ik raad het gebruik van de vierkante haken voor kortere cel- of bereikverwijzing af. zie onder andere Square Bracket Notation Is Less Efficient Than Tunneling. maar: http://www.ozgrid.com/forum/showthread.php?t=52372

[pedorus]

Verwijderd schreef op donderdag 22 april 2010 @ 10:47:
ik raad het gebruik van de vierkante haken voor kortere cel- of bereikverwijzing af. zie onder andere Square Bracket Notation Is Less Efficient Than Tunneling. maar: http://www.ozgrid.com/forum/showthread.php?t=52372

Hier 4 keer gebruiken scheelt inderdaad toch zo'n <40 microseconden. Je kunt misschien ook nog wel meer besparen door "With Sheets("Parts-to-picker")" te gebruiken, maar eigenlijk lijken me dit soort performanceverschillen niet zo relevant. Zelfs rond Excel '97, waar dat eerste artikel van is, lijkt het me nog niet relevant. Het wordt ook daar pas relevant als je consequent [] gebruikt, zonder een variabele te gebruiken, in zeg een loop, en/of als je de functies waarin [] wordt gebruikt heel vaak aanroept. In het eerste geval kun je beter een variabele gebruiken zoals dat hier gebeurd, in het laatste geval is een parameter waarschijnlijk netter. Het 2e linkje raadt het gebruik juist aan.

Het blijft natuurlijk een kwestie van smaak. Er tussenin ligt Sheets("Parts-to-picker").Range("F8") ipv Cells(8, 6). Dat scheelt al een stuk in leesbaarheid.

[Verwijderd]

het is idd grotendeels een smaakkwestie, weliswaar is het aan te raden code te schrijven die in zoveel mogelijk situaties correct functioneert. daarom houd ik bij mijn productiecode er standaard aan de volledige objecthiërarchie uit te schrijven : application.workbooks().worksheets().range() enz.., indien je enkel sheets().range... gebruikt moet natuurlijk de juiste werkmap actief zijn of er komt een foutmelding.
het with statement is nogal buggy in office 2000, als je de vierkante haken [F8] herschrijft naar het equivalente, wat langere application.evaluate("F8") is het ook niet zo mooi meer.

[Verwijderd]

Verwijderd schreef op donderdag 22 april 2010 @ 15:34:
daarom houd ik bij mijn productiecode er standaard aan de volledige objecthiërarchie uit te schrijven : application.workbooks().worksheets().range() enz.., indien je enkel sheets().range... gebruikt moet natuurlijk de juiste werkmap actief zijn of er komt een foutmelding.

Wat mij betreft de belangrijkste reden om de hiërarchie altijd volledig uit te schrijven. Er kunnen rare dingen gebeuren als je een macro vanuit een ander werkblad activeert, waarna de procedure lustig loshakt op het verkeerde werkblad...

[Verwijderd]

pedorus schreef op donderdag 22 april 2010 @ 11:17:Het 2e linkje raadt het gebruik juist aan.

offtopic:
ik ben natuurlijk niet te beroerd om zelf onmiddellijk een tegenargument te geven voor mijn redenering

[pedorus]

Verwijderd schreef op donderdag 22 april 2010 @ 16:06:
Wat mij betreft de belangrijkste reden om de hiërarchie altijd volledig uit te schrijven. Er kunnen rare dingen gebeuren als je een macro vanuit een ander werkblad activeert, waarna de procedure lustig loshakt op het verkeerde werkblad...

Het lijkt me sowieso onverstandig om op die manier vba aan te roepen. Wat is er mis met een knop?
Daarnaast zullen goede macro's over het algemeen falen doordat bepaalde namen niet bestaan, want refereren naar vaste cellen is niet zo handig imo. En Sheet CodeNames lijken me handiger dan een volledig path, te zetten bij de properties van een werkblad. Dan krijg je dus Werkbladnaam.Range("celnaam") ipv [Werkbladnaam!celnaam]

[Verwijderd]

Klopt, normaal gesproken stop ik mijn macro's ook achter knoppen. Maar er zijn situaties denkbaar waarbij het aanroepen van een macro middels een sneltoets handiger is. Denk aan het ad hoc bewerken van meerdere bestanden, waarbij de macro in een ander bronbestand zit.

[Jericho NutS]

bedankt voor de reacties
vba is nodig aangezien er enkele keren in één enkele formule gesommeert moet worden tot soms 10000 (i=0 to 10000) en dat ga ik niet met hulp rijen zitten oplossen
en knop wordt uiteraard nog toegevoegd maar dit maakt niets uit voor de functionaliteit
nu ik de basis ken kan ik weer verder doen