UCase in Excel 2007

[jog]

Hallo,

is er in Excel 2007 iets veranderd t.o.v. 2003 met UCase.
Ik had in Excel 2003 een programma gemaakt waar de data van bepaalde kolommen d.m.v. UCase werden omgezet in hoofdletters.
Nu ik dit wil doen in de 2007 versie krijg ik steeds een foutmelding.

-214741848 (80010108)

Private Sub Worksheet_Change(ByVal Target As Range)
If Target.Cells.Count = 1 And Target.Column = 7 Then
Target = UCase(Target)
End If
If Target.Cells.Count = 1 And Target.Column = 8 Then
Target = UCase(Target)
End If
End Sub

Bovenstaande code werkt voor kolommen bv.7 die hoofdzakelijk bestaan uit letters.
Kolom 8 echter bestaat uit cijfers en letters en hier loopt het nu blijkbaar fout.
Deze code werkt in Excel 2007 blijkbaar enkel voor letters en geeft een foutcode wanneer er ook cijfers instaan.

Kolom 8 bevat bv volgende data: 123456v789 waarbij dus de v in hoofdletter zou moeten komen.

Iemand een idee wat er hier fout loopt?


Alvast bedankt,

 

[Hoornvan]

jog,

Ik gebruik Excel2007 en je code werkt hier zonder probleem.

 

[snb]

Alternatief ?

Private Sub Worksheet_Change(ByVal Target As Range)
  With Target
    If instr("71 81 ", .column & .Cells.Count & " ")>0  Then .value = UCase(.value)
  End With 
End Sub

 

[jog]

Code werkt bij mij ook perfect, behalve voor kolom 8.

Ik heb vandaag op mijn werk het bestand nog eens geopend met Excel 2003 en daar doet ie het zoals het hoort in elke kolom, incl. kolom 8 (cijfers;letter;cijfers).
Weet echt niet wat hier aan de hand is.

@snb

bij jou code krijg ik hetzelfde probleem

Private Sub Worksheet_Change(ByVal Target As Range)
With Target
If InStr("71 81 ", .Column & .Cells.Count & " ") > 0 Then Value = UCase(.Value)
End With
End Sub

 

[Ginger]

Kan het zijn dat die cel/kolom (8) beveiligd is??? Je betoog houdt namelijk geen stand omdat de 1e 7 kolommen WEL werken...

Groet, Leo

 

[snb]

Hoe is het met je ogen ?

Then Value = UCase(.Value)

In mijn suggestie staat

Then .Value = UCase(.Value)

 

[Wigi]

Private Sub Worksheet_Change(ByVal Target As Range)
  With Target
    If instr("71 81 ", .column & .Cells.Count & " ")>0  Then .value = UCase(.value)
  End With 
End Sub

Snb, gewoon ter informatie wilde ik eens weten: is het minimaliseren een van het aantal regels code (of karakters) bij u een bijkomende vereiste voor een oplossing?

 

[snb]

@Wigi

Geen vereiste, wel een gewenste.
Het voldoet aan het wiskundige begrip elegantie: 2 oplossingen kunnen even effektief zijn (hetzelfde resultaat bereiken); als de ene oplossing dat eenvoudiger, met minder middelen doet, wordt dat een 'elegantere' oplossing genoemd. Naast estetische overwegingen kunnen elegantere oplossingen ook efficienter zijn in het gebruik van rekencapaciteit. Vaak komt elegantie ook de leesbaarheid ten goede.

In de filosofie wordt voor elegantie een algemener begrip gebruikt: het principe van de spaarzaamheid (principle of parsimony), ook wel aangeduid met Occam's scheermes. Dat betekent dat ernaar gestreefd wordt om het aantal verklaringsmiddelen te reduceren en het verklaringsgebied te vergroten. Een verklaring die met weinig assumpties, objekten en relaties tussen objekten een aantal verschijnselen kan verklaren/beschrijven wordt geprefereerd boven een verklaring die daarvoor meer nodig heeft.
Dit principe zegt dus niets over de effektiviteit van de verklaring maar geeft een oordeel over de efficiëntie van het verklaringsmiddel.

In de tijd dat 'personal computers' 64k werkgeheugen hadden was het noodzaak te woekeren met geheugencapaciteit en dus ook noodzaak zeer compacte code te schrijven. Maar het is ook een intellectueel interessante extra opgave (naast die van de effektiviteit). Hoewel de capaciteitsnoodzaak afgenomen is, blijft de intellectuele uitdaging bestaan.
Daarnaast is de vraag of iets eenvoudiger, compacter, met minder middelen kan, vaak aanleiding om dieper door te dringen in de aard van het vraagstuk en het exploreren van de mogelijkheden die het oplossingsinstrumentarium (i.c. VBA) heeft. Dat kan leiden tot nieuwe inzichten en is tegelijkertijd een intellectuele 'uitdaging' (die je leuk kunt vinden).
Regelmatig sta ik verbaasd, dat code die ik 6 maanden gelden heb gemaakt, verder vereenvoudigd kan worden (in de wetenschap dat dat over 6 maanden weer het geval zal zijn).
Ik heb zelf - maar dat zal je niet verbazen - een sterke voorkeur voor minimalistische oplossingen voor een probleem.

Vraag beantwoord ?
Gegroet.

 

[Hoornvan]

jog,
Code werkt bij mij ook perfect, behalve voor kolom 8.

Bij mij werkte hij zowel op kolom7 als kolom8.
Ik denk dat het dan ergens anders aan moet liggen.

 

[Finch]

@Wigi

Geen vereiste, wel een gewenste.
Het voldoet aan het wiskundige begrip elegantie: 2 oplossingen kunnen even effektief zijn (hetzelfde resultaat bereiken); als de ene oplossing dat eenvoudiger, met minder middelen doet, wordt dat een 'elegantere' oplossing genoemd. Naast estetische overwegingen kunnen elegantere oplossingen ook efficienter zijn in het gebruik van rekencapaciteit. Vaak komt elegantie ook de leesbaarheid ten goede.

In de filosofie wordt voor elegantie een algemener begrip gebruikt: het principe van de spaarzaamheid (principle of parsimony), ook wel aangeduid met Occam's scheermes. Dat betekent dat ernaar gestreefd wordt om het aantal verklaringsmiddelen te reduceren en het verklaringsgebied te vergroten. Een verklaring die met weinig assumpties, objekten en relaties tussen objekten een aantal verschijnselen kan verklaren/beschrijven wordt geprefereerd boven een verklaring die daarvoor meer nodig heeft.
Dit principe zegt dus niets over de effektiviteit van de verklaring maar geeft een oordeel over de efficiëntie van het verklaringsmiddel.

In de tijd dat 'personal computers' 64k werkgeheugen hadden was het noodzaak te woekeren met geheugencapaciteit en dus ook noodzaak zeer compacte code te schrijven. Maar het is ook een intellectueel interessante extra opgave (naast die van de effektiviteit). Hoewel de capaciteitsnoodzaak afgenomen is, blijft de intellectuele uitdaging bestaan.
Daarnaast is de vraag of iets eenvoudiger, compacter, met minder middelen kan, vaak aanleiding om dieper door te dringen in de aard van het vraagstuk en het exploreren van de mogelijkheden die het oplossingsinstrumentarium (i.c. VBA) heeft. Dat kan leiden tot nieuwe inzichten en is tegelijkertijd een intellectuele 'uitdaging' (die je leuk kunt vinden).
Regelmatig sta ik verbaasd, dat code die ik 6 maanden gelden heb gemaakt, verder vereenvoudigd kan worden (in de wetenschap dat dat over 6 maanden weer het geval zal zijn).
Ik heb zelf - maar dat zal je niet verbazen - een sterke voorkeur voor minimalistische oplossingen voor een probleem.

Vraag beantwoord ?
Gegroet.

Een "kortere" oplossing wil toch niet per definitie zeggen dat ze sneller. Neem nu bv. de Iif functie binnen VBA. Deze laat kortere code toe dan een If-Then-Else structuur, maar is toch trager dan de ITE structuur. Dit omdat bij de Iif functie zowel de true als false component altijd wordt berekend.

 

[robdgr]

Vraag beantwoord ?

@snb,

Ter ondersteuning van jouw verhaal herinner ik me in dit verband een wijze les ooit gekregen: "Sorry, ik had weinig tijd, dus het is een lang verhaal geworden".

 

[snb]

@Finch

Lezen !

Naast estetische overwegingen kunnen elegantere oplossingen ook efficienter zijn in het gebruik van rekencapaciteit

Een "kortere" oplossing wil toch niet per definitie zeggen dat ze sneller (is)

Inderdaad, daarom heb ik dat ook niet beweerd.

 

[Finch]

@Finch

Lezen !




Inderdaad, daarom heb ik dat ook niet beweerd.

In de tijd dat 'personal computers' 64k werkgeheugen hadden was het noodzaak te woekeren met geheugencapaciteit en dus ook noodzaak zeer compacte code te schrijven.

Ik had het op deze zin, en had in je eerste zin te snel over het woordje "kunnen" gelezen.

Het was ook niet mijn bedoeling om hierover een polemiek te starten. Ik snap je redering/motief, maar persoonlijk is mijn uitdaging nooit, om het kort door de bocht te zeggen, zo weinig mogelijk regels code te gebruiken. Tot op een zeker punt natuurlijk wel, maar daar stopt het bij mij meestal. Ik denk wel dat je begrijpt waar ik op doel.

 

[snb]

@Finch

Ik snap wat je bedoelt. Prima

Mijn verhaal was niet anders dan een antwoord op een vraag van Wigi.
Vandaar dat ik eindig met de vraag of diens vraag beantwoord is.
Het enige dat ik deed was een wat uitgebreide toelichting geven op mijn 'stijl' waarover Wigi een vraag stelde. Het bericht was dan ook primair voor hem bedoeld.

 

[Wigi]

Hallo

Ik denk dat het veeleer de eigen gewoontes van programmeren zijn. Als ik vandaag deze code schrijf:

Private Sub Worksheet_Change(ByVal Target As Range)
  With Target
    If instr("71 81 ", .column & .Cells.Count & " ")>0  Then .value = UCase(.value)
  End With 
End Sub

en over 6 maanden bekijk ik die terug, dan moet ik opnieuw de moeite doen om "het systeem" binnen die InStr functie te begrijpen. Dat zou ik veel minder hebben bij:

Private Sub Worksheet_Change(ByVal Target As Range)
  With Target
    If .Cells.Count = 1 Then
       If .Column = 7 Or .Column = 8 Then
           .Value = UCase(.Value)
       End If
    End If
  End With
End Sub

Dat is wel enkele regels langer. Ik ben er wel van overtuigd dat anderen (mindere Excel goden als wij ) de onderste code sneller gaan begrijpen en aanpassen, dan de bovenste code. Het tussenvoegen van commentaarregels gaat wel makkelijker in de eerste code. Voorts declareer ik ook mijn variabelen.

Just my 2 cents.

Ik vind dat de vraag voldoende beantwoord is

Wigi

 

[jog]

sorry voor de laattijdige reactie.
Blijkbaar is de discussie hier nog even verdergegaan, maar mijn probleem is ondertussen nog niet opgelost.

Om het overzichtelijk te houden ga ik deze vraag afsluiten en een nieuwe vraag stellen i.v.m. HOOFDLETTERS

Alvast bedankt voor de moeite.