[VBA] Multi-line textbox naar kolom

[speedy15]

Beste GoT-ers,

Voor mijn stage opdracht moet ik een programma schrijven in Excel om van bepaalde data een grafiek te maken.
Dit wilde ik gaan doen m.b.v. een VBA programma, een UserForm met daarop een Multi-line textbox (om de data in te kopieren) en dan met een druk op de knop deze data kopieren naar een kolom en daarvan een grafiek maken.

De data bestaan uit getalen varierend van (0,000002 t/m 75,2151 (voorbeeld uiteraard)). Echter wanneer ik deze data vanuit de textbox "importeer/kopieer" naar een kolom, veranderden de getallen kompleet. De getallen onder de 1 worden naar de cellen gekopieerd als text ipv een getal (dit is niet het grootste probleem) en de getallen boven de 1, daarvan wordt de comma door Excel verwijderd en worden het ineens duizendtallen (75,2151 wordt 752151).

De VBA-code die ik gebruik is alvolgt:

code:

If TextBox1 = vbNullString Then
        On Error Resume Next
    Else
        strStringToSplit = TextBox1.Value
        Range("D3").Resize(UBound(Split(strStringToSplit, Chr(10))) + 1, 1).Value = Application.Transpose(Split(strStringToSplit, Chr(13) & Chr(10)))
        strStringToSplit = vbNullString
    End If

Heeft er iemand ervaring met dit probleem of kan het kopieren op een andere/betere manier?

Een voorbeeld Excel bestand is eventueel te downloaden via mijn Dropbox:
https://www.dropbox.com/s/ry84a8b6o84cgz2/GoT.xlsm

Uitleg:
De waardes uit kolom C "Ctrl+C", UserForm openen met button rechts boven de grafiek, de waardes uit kolom C plakken "Ctrl+V" in Textbox en op Import klikken

[Gomez12]

1 simpele opmerking (geen idee of het gerelateerd is, maar het geldt eigenlijk altijd VB/VBA) mieter die on error resume next eruit en probeer het dan nog eens (of bouw een fatsoenlijke error handler)

Zolang die erin zit heeft wmb naar de rest van de code kijken geen zin, want hoe erg de error ook is, vba zal doorgaan en indien nodig foutieve data produceren.

[Koenvh]

Misschien even kijken of strStringToSplit wel echt een value ontvangt... Dat lijkt me een mogelijkheid waarom hij iets anders er van maakt...

[siddler]

Het kommaprobleem kan ook te maken hebben met je instellingen van Excel. Normaal als ik iets kopieer vervang ik dan alle komma's door punten (of vice versa) en is t opgelost. Misschien dat het helpt als je de , als decimaalteken instelt.

[Gomez12]

siddler schreef op maandag 03 december 2012 @ 23:57:
Het kommaprobleem kan ook te maken hebben met je instellingen van Excel. Normaal als ik iets kopieer vervang ik dan alle komma's door punten (of vice versa) en is t opgelost. Misschien dat het helpt als je de , als decimaalteken instelt.

Waarschijnlijk zit het probleem idd in de regioinstellingen van windows.

Maar in principe (als de invoer altijd bekend is en gelijk is) zou ik gewoon een custom functie maken die gewoon de input parsed naar het gewenste formaat.

Regio-instellingen en de excel magie die daaraan gekoppeld is is leuk als je echt regiogebonden invoer hebt, maar als je altijd dezelfde invoer hebt zou ik simpelweg de regio-magie negeren het zelf parsen. Scheelt je een hoop gezeur als iemand anders jouw excel sheetje wil gebruiken of je een nieuwe pc krijgt of ... of ...

[speedy15]

Gomez12 schreef op maandag 03 december 2012 @ 21:54:
1 simpele opmerking (geen idee of het gerelateerd is, maar het geldt eigenlijk altijd VB/VBA) mieter die on error resume next eruit en probeer het dan nog eens (of bouw een fatsoenlijke error handler)

Zolang die erin zit heeft wmb naar de rest van de code kijken geen zin, want hoe erg de error ook is, vba zal doorgaan en indien nodig foutieve data produceren.

De "error resume next" heb ik eruit gehaald, maar heb nog steeds het zelfde probleem.

siddler schreef op maandag 03 december 2012 @ 23:57:
Het kommaprobleem kan ook te maken hebben met je instellingen van Excel. Normaal als ik iets kopieer vervang ik dan alle komma's door punten (of vice versa) en is t opgelost. Misschien dat het helpt als je de , als decimaalteken instelt.

De comma is al ingesteld als decimaalteken. Wanneer ik de waardes handmatig kopieer werkt het nl. wel goed.
Maar zodra ik het "Split" VBA commando gebruik gebeurd er iets met de waardes, waardoor de comma weg gehaald wordt en de waardes geen decimale getallen meer zijn.

edit: Na nog wat te hebben geprobeerd, komt het probleem alleen voor als ik het "Application.Transpose" commando gebruik. Als deze niet gebruikt wordt dan worden de waardes op 1 rij weer gegeven, maar wel in het juiste formaat (dus als decimaal getal met een comma). Zit er in de transpose functie een bepaalde optie om de comma's te verwijderen ofzo?

edit 2: Ik heb ondertussen nog een aantal andere voorbeelden geprobeerd, maar elke keer zit ik met hetzelfde probleem. Het lijkt dus toch te komen door een of andere taal instelling. Opzich heel raar, want een aantal weken geleden werkte het programma nl. wel normaal .

[ Voor 21% gewijzigd door speedy15 op 05-12-2012 09:06 ]

[farlane]

speedy15 schreef op dinsdag 04 december 2012 @ 12:15:
Opzich heel raar, want een aantal weken geleden werkte het programma nl. wel normaal .

Andere PC? Andere regio instellingen?Andere Windows?

Anyway, die transpose lijkt me niet zo heel moeilijk zelf te schrijven.

[speedy15]

Zelfde pc, zelfde Windows. Maar ik krijg hetzelfde probleem op de pc bij mijn stagebedrijf (NL instellingen), mijn thuis pc (EN instellingen) en mijn server (EN instellingen).

[speedy15]

BUMP, niemand een idee/oplossing?

[edeboeck]

Vervang eens alle komma's door punten... het is zo dat je in je code de Amerikaanse notatie moet gebruiken (waarbij "." een decimaalteken is en "," een cijfergroeperings/scheidingsteken). Mijn gok is dat de gegevens op een bepaald moment als code worden gezien.
Als je dus de komma's door punten vervangt (dit kan je uiteraard het beste doen bij het uitlezen van je textbox), heb je het probleem dan nog?

[speedy15]

Dat was dus het probleem, THNX edeboeck!!! SUPER

[edeboeck]

speedy15 schreef op maandag 10 december 2012 @ 13:40:
Dat was dus het probleem, THNX edeboeck!!! SUPER

Graag gedaan, blij dat het opgelost is!