🚀 go-pugleaf

Hugo Maes wrote:

> Weet er iemand hoe een bestaand Excel spreadheet uit te lezen vanuit
> Visual Basic [dus niet via VBA die in Excel zelf zit].
> Tenzij ik erover heb gekeken is er geen standaard ActiveX in VB zelf om
> dit te doen.
> Mijn probleem hierbij is dat het een tijdelijk project is dat ik in 1
> week klaar moet hebben, en daarom prefereer ik in mijn vertrouwde VB
> omgeving te blijven. Ook Google helpt me niet direkt op weg, noch mijn
> MSDN, noch mijn VB6 handboeken.

Dat vind ik nu eens een perfect voorbeeld van hoe het NIET moet. MS maakt 
een eigen "programmeer"-taal en die ondersteunt geeneens hun eigen 
document-formaten!
Een dikke proficiat aan MS.

En hopelijk vind je een oplossing voor het probleem. Want ik ken geen VB, 
laat staan Excel. Ik programmeer enkel in echte programmeer-talen en 
gebruik enkel Open Source programma's met idem dito bestands-formaten.

-- 
ing. Toni Van Remortel
Researcher @ D-scienelab on "LinEmb" project.
LinEmb = Real Time Linux for Embedded Systems
--------------------------------
Lab website: http://www.d-sciencelab.com
Project email: linemb @ d-sciencelab . com

Toni Van Remortel wrote:

> Hugo Maes wrote:
> 
>> Weet er iemand hoe een bestaand Excel spreadheet uit te lezen vanuit
>> Visual Basic [dus niet via VBA die in Excel zelf zit].
>> Tenzij ik erover heb gekeken is er geen standaard ActiveX in VB zelf om
>> dit te doen.
>> Mijn probleem hierbij is dat het een tijdelijk project is dat ik in 1
>> week klaar moet hebben, en daarom prefereer ik in mijn vertrouwde VB
>> omgeving te blijven. Ook Google helpt me niet direkt op weg, noch mijn
>> MSDN, noch mijn VB6 handboeken.
> 
> Dat vind ik nu eens een perfect voorbeeld van hoe het NIET moet. MS maakt
> een eigen "programmeer"-taal en die ondersteunt geeneens hun eigen
> document-formaten!
> Een dikke proficiat aan MS.

Het is niet de "taal" die de formaten moet ondersteunen (IMO). Btw ik denk 
wel dat er manieren inVB _zijn_ om dat te kunnen lezen, maar VB'ers zoeken 
toevallig gewoon altijd manieren die "bij iedereen werken". Dat betekent: 
ze gaan ervan uit dat de gemiddelde winbie niet snapt wat libraries zijn 
(en ze hebben meestal nog gelijk ook) en dus hebben ze 2 mogelijkheden:

- distribueer elk programma met alle libraries die het gebruikt. Veel 
gebruikt, bron van grote installatiepakketten en bron van "na X maanden 
opnieuw installeren" (omdat de helft van die domme installatieprogramma's 
ongevraagd dingen overschrijft etc).
- gebruik geen niet-standaard-bij-Windows-zittende libraries.

Hoe zou het moeten zijn (ik weet niet in hoeverre Microsoft dat zo doet):

Je hebt een applicatie die Excel bestanden wil kunnen lezen. Daarvoor heb 
je dan een library nodig, die eventueel automatisch bij Excel zit of als 
extra geinstalleerd kan worden. Heb je die niet, dan heb je pech (maw dan 
moet je die downloaden en installeren). Een goed installatiesysteem 
waarschuwt je als je de benodigde libraries niet hebt (en eventueel kan het 
aanbeiden de nodige libraries zelf te downloaden en installeren).

Logisch, niet?

Het grote probleem zal nu wel liggen in het feit dat die dingen 
waarschijnlijk allemaal commerciele ontwikkelingen zijn en alles zodoende 
weer veel moeilijker moet ... (typisch).

(Ik moet zeggen: hierop verwacht ik een flinke tegenaanval-reply van PP 
over hoe goed Microsoft het wel zal hebben opgelost, of dat het niet aan 
hen maar aan de slechte programma-ontwikkelaars ligt ofzo :-).

-- 
Nicolas Barbier
MY_PROFILE:   http://users.pandora.be/HATE/profiles/itsme/
HOW_TO_QUOTE: http://www.houghi.org/quote/ /* Dutch */

Nicolas Barbier wrote:

> (Ik moet zeggen: hierop verwacht ik een flinke tegenaanval-reply van PP
> over hoe goed Microsoft het wel zal hebben opgelost, of dat het niet aan
> hen maar aan de slechte programma-ontwikkelaars ligt ofzo :-).

Bwa. Ik geef toch geen jota om MS-software, laat staan VB-geschreven 
software (die is nl super traag en geheugen-vretend, weet ik van iemand 
hier op mijn werk).

Ik bedoelde ivm die Excel-formaten: MS voorziet blijkbaar geen libraries 
waardoor je Excel bestanden kan uitlezen. Alhoewel ik mij meen te 
herinneren uit mijn school-tijd dat er wel een MFC-class bestond voor 
Excel-files uit te lezen. Maar dat was wel C/C++ natuurlijk.

-- 
ing. Toni Van Remortel
Researcher @ D-scienelab on "LinEmb" project.
LinEmb = Real Time Linux for Embedded Systems
--------------------------------
Lab website: http://www.d-sciencelab.com
Project email: linemb @ d-sciencelab . com

Hugo Maes <Hugo.Maes@chello.be> wrote:
> Weet er iemand hoe een bestaand Excel spreadheet uit te lezen vanuit
> Visual Basic [dus niet via VBA die in Excel zelf zit].

Kan je er niet geraken via menu Project->References en dan in de lijst
Microsoft Excel aantikken?

In de code moet je dan dingen gaan schrijven alla

Dim Foo As Excel.Worksheet
Foo=CreateObject("Excel.Sheet")
Foo.WeetIkVeelWelkeMethod

of iets dergelijks. Soit, dat is het principe dat ik toch gebruik om aan
mijn eigen COM interfaces te geraken. Hoe de Excel interfaces juist in
elkaar zitten of hoe ze genoemd worden heb ik totaal geen idee, maar dat
moet je wel in ieder goed boek over het programmeren van Office vinden.

Tenzij je met het bovenstaande juist de 'VBA die in Excel zelf zit'
bedoeld natuurlijk, en je een EXE wil maken die kan werken op een
puter waar Excel niet geinstalleerd is of bijvoorbeeld.

cu bart

-- 
http://www.irule.be/bvh/

Toni Van Remortel <ToniVR @ softhome . net> wrote:
> Dat vind ik nu eens een perfect voorbeeld van hoe het NIET moet. MS maakt 
> een eigen "programmeer"-taal en die ondersteunt geeneens hun eigen 
> document-formaten!
> Een dikke proficiat aan MS.

Rustig maar.  Het is niet omdat Hugo niet juist weet hoe het moet, dat het
niet kan.

1. Een taal moet geen bestandsformaten ondersteunen
2. Een taal moet mechanismen ondersteunen die toelaten gemakkelijk
bestandsformaten te manipuleren
3. VB heeft dat laatste wel degelijk

> En hopelijk vind je een oplossing voor het probleem. Want ik ken geen VB, 
> laat staan Excel. Ik programmeer enkel in echte programmeer-talen en 
> gebruik enkel Open Source programma's met idem dito bestands-formaten.

Dat is allemaal heel leuk voor jou, maar maakt je post wel totaal
overbodig.

cu bart

-- 
http://www.irule.be/bvh/

Toni Van Remortel wrote:

[...]

> Bwa. Ik geef toch geen jota om MS-software, laat staan VB-geschreven
> software (die is nl super traag en geheugen-vretend, weet ik van iemand
> hier op mijn werk).

Lap. Ik had het bij mijn oorspronkelijk bericht willen bijzetten, maar
ik dacht dat het publiek hier tenminste iets Usenet-rijper was dan op
andere be.forums. Ik heb er absoluut geen boodschap aan hoeveel beter
Linux is of godbetert, dat ik een Mac zou moeten kopen. Ik vroeg gewoon
een concrete oplossing voor een concreet probleem, in de hoop dat er
iemand snel een oplossing zou weten. Nu ja, ik heb de aanzet tot het
antwoord vanmiddag gevonden op de internationale programming
nieuwsgroepen, dus daar blijf ik dan maar. Ik heb echt geen behoefte aan
be.comp.programming.philosophy. Tot binnen 2 jaar nog eens hier.

mvg, HM

"Toni Van Remortel" <ToniVR @ softhome . net> wrote in message
news:YE0e9.105421$8o4.14626@afrodite.telenet-ops.be...
> Hugo Maes wrote:
>
> > Weet er iemand hoe een bestaand Excel spreadheet uit te lezen vanuit
> > Visual Basic [dus niet via VBA die in Excel zelf zit].
> > Tenzij ik erover heb gekeken is er geen standaard ActiveX in VB zelf om
> > dit te doen.
> > Mijn probleem hierbij is dat het een tijdelijk project is dat ik in 1
> > week klaar moet hebben, en daarom prefereer ik in mijn vertrouwde VB
> > omgeving te blijven. Ook Google helpt me niet direkt op weg, noch mijn
> > MSDN, noch mijn VB6 handboeken.
>
> Dat vind ik nu eens een perfect voorbeeld van hoe het NIET moet. MS maakt
> een eigen "programmeer"-taal en die ondersteunt geeneens hun eigen
> document-formaten!
> Een dikke proficiat aan MS.
>
> En hopelijk vind je een oplossing voor het probleem. Want ik ken geen VB,
> laat staan Excel. Ik programmeer enkel in echte programmeer-talen en
> gebruik enkel Open Source programma's met idem dito bestands-formaten.

Voor je te vlug roept, waarom zou dit nu niet mogelijk zijn? Het kan via
ADO, DAO, ODBC, noem maar op...

Zie http://support.microsoft.com/default.aspx?scid=kb;en-us;Q190195

Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
programmeren... Probeer maar eens een algemene database toepassing te
schrijven in GNU C "open source", zonder beperkingen te leggen op welke
database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC :)

Vincent

Vincent WILLEMS wrote:
> Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
> programmeren... Probeer maar eens een algemene database toepassing te
> schrijven in GNU C "open source", zonder beperkingen te leggen op welke
> database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC :)

ODBC is traag.

-- 
ing. Toni Van Remortel
Researcher @ D-scienelab on "LinEmb" project.
LinEmb = Real Time Linux for Embedded Systems
--------------------------------
Lab website: http://www.d-sciencelab.com
Project email: linemb @ d-sciencelab . com

Hugo Maes wrote:

> Toni Van Remortel wrote:
> 
> [...]
> 
>> Bwa. Ik geef toch geen jota om MS-software, laat staan VB-geschreven
>> software (die is nl super traag en geheugen-vretend, weet ik van iemand
>> hier op mijn werk).
> 
> Lap. Ik had het bij mijn oorspronkelijk bericht willen bijzetten, maar
> ik dacht dat het publiek hier tenminste iets Usenet-rijper was dan op
> andere be.forums. Ik heb er absoluut geen boodschap aan hoeveel beter
> Linux is of godbetert, dat ik een Mac zou moeten kopen. Ik vroeg gewoon
> een concrete oplossing voor een concreet probleem, in de hoop dat er
> iemand snel een oplossing zou weten. Nu ja, ik heb de aanzet tot het
> antwoord vanmiddag gevonden op de internationale programming
> nieuwsgroepen, dus daar blijf ik dan maar. Ik heb echt geen behoefte aan
> be.comp.programming.philosophy. Tot binnen 2 jaar nog eens hier.

Sorry voor mijn reactie, maar ik heb ook een tijd met MS software 
geprogrammeerd en mij veel te veel geergerd aan incomplete implementaties, 
niet ondersteunde formats ed.
Ik ben wel een gebruiker van Linux, maar dat wil niet zeggen dat ik iedereen 
Linux wil opleggen. Ieder zijn keuze, uiteraard.
Maar ik dacht dat MS tegenwoordig zijn eigen systeem vrij compatibel en voor 
de hand liggend had gemaakt (en met systeem bedoel ik alles waar de naam MS 
op staat). Blijkbaar nog steeds niet. Na zoveel jaren. En dat ergert me. Ze 
doen alsof alles vanzelf gaat en kan, maar dat is het niet. Dan heb ik 
liever dat ze toegeven dat je voor bepaalde doeleinden naar alternatieven 
moet gaan zoeken (zoals even het net afzoeken). Dat is nl wel een algemene 
gedachte in de open-source gemeenschap.

En nee, ik ben geen prediker. Wel iemand die ondertussen de buik vol heeft 
van het MS-platform qua programmeren. Mijn excuses daarvoor.

-- 
ing. Toni Van Remortel
Researcher @ D-scienelab on "LinEmb" project.
LinEmb = Real Time Linux for Embedded Systems
--------------------------------
Lab website: http://www.d-sciencelab.com
Project email: linemb @ d-sciencelab . com

Bart.Vanhauwaert@nowhere.be wrote:

> Kan je er niet geraken via menu Project->References en dan in de lijst
> Microsoft Excel aantikken?

Bedankt. Voor de geinteresseerden geeft ik ondertussen de link, die in
de lijn van Bart's oplossing ligt:

http://maths.sci.shu.ac.uk/units/advvpl/ole/OLE%20Automation%20of%20EXCEL.pdf

mvg, HM

Toni Van Remortel wrote:
 
> ODBC is traag.

Een nieuwe omgeving leren is nog veel trager voor een
gelegenheidsprogrammeur die snel een wetenschappelijk probleem wil
oplossen.

Voor de geinteresseerden:

http://maths.sci.shu.ac.uk/units/advvpl/ole/OLE%20Automation%20of%20EXCEL.pdf

mvg, HM

Hugo Maes <Hugo.Maes@med.kuleuven.ac.be> wrote:
> Bedankt. Voor de geinteresseerden geeft ik ondertussen de link, die in
> de lijn van Bart's oplossing ligt:
> http://maths.sci.shu.ac.uk/units/advvpl/ole/OLE%20Automation%20of%20EXCEL.pdf

Ha ja, ik was bij het opstellen van mijn antwoord al op zoek naar het
buzzword dat je moet gebruiken om deze techniek te benoemen, maar het
ontsnapte me volledig. Automation dus.

cu bart

-- 
http://www.irule.be/bvh/

Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> Toni Van Remortel <ToniVR @ softhome . net> wrote:

[...]

> > En hopelijk vind je een oplossing voor het probleem. Want ik ken geen VB,
> > laat staan Excel. Ik programmeer enkel in echte programmeer-talen en
> > gebruik enkel Open Source programma's met idem dito bestands-formaten.
> 
> Voor je te vlug roept, waarom zou dit nu niet mogelijk zijn? Het kan via
> ADO, DAO, ODBC, noem maar op...

[...]

> Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
> programmeren... Probeer maar eens een algemene database toepassing te
> schrijven in GNU C "open source", zonder beperkingen te leggen op welke
> database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC :)

Dat doe je zeer eenvoudig door een stel wrappers.  Ik heb een applicatie van
me draaiende gehad onder MySQL (pseudo-database), PostgreSQL, DB2, Sybase en
Oracle.

Die applicatie kan in theorie perfect werken op ieder platform met een
degelijke (=POSIX conformerende) C-library.  Enige eis is dat de libraries van
de DBMS beschikbaar zijn om tegen te linken.

Het komt neer op modularisatie.  Als je database parameters gaat hardcoden (in
*any* language) maak je er een soep van.  Als je ADO, DAO of andere prutsjes
gebruikt, ben je platform-afhankelijk.  (Open)ODBC is tergend traag.

Als je je database 'native' aanspreekt in je programma, volstaat het dat de
gebruiker de DBMS installeert met de libraries erbij.

 - Philip

-- 
Philip Paeps                                                   philip@paeps.cx

  Remember the golden rule:
  Those that have the gold make the rules.

"Philip Paeps" <philip@paeps.cx> wrote in message
news:kX4e9.105730$8o4.14651@afrodite.telenet-ops.be...
> Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> > Toni Van Remortel <ToniVR @ softhome . net> wrote:
>
> [...]
>
> > > En hopelijk vind je een oplossing voor het probleem. Want ik ken geen
VB,
> > > laat staan Excel. Ik programmeer enkel in echte programmeer-talen en
> > > gebruik enkel Open Source programma's met idem dito bestands-formaten.
> >
> > Voor je te vlug roept, waarom zou dit nu niet mogelijk zijn? Het kan via
> > ADO, DAO, ODBC, noem maar op...
>
> [...]
>
> > Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
> > programmeren... Probeer maar eens een algemene database toepassing te
> > schrijven in GNU C "open source", zonder beperkingen te leggen op welke
> > database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC :)
>
> Dat doe je zeer eenvoudig door een stel wrappers.  Ik heb een applicatie
van
> me draaiende gehad onder MySQL (pseudo-database), PostgreSQL, DB2, Sybase
en
> Oracle.
>
> Die applicatie kan in theorie perfect werken op ieder platform met een
> degelijke (=POSIX conformerende) C-library.  Enige eis is dat de libraries
van
> de DBMS beschikbaar zijn om tegen te linken.
>
> Het komt neer op modularisatie.  Als je database parameters gaat hardcoden
(in
> *any* language) maak je er een soep van.  Als je ADO, DAO of andere
prutsjes
> gebruikt, ben je platform-afhankelijk.  (Open)ODBC is tergend traag.
>


Misschien interessant om eens te lezen:
http://ourworld.compuserve.com/homepages/Ken_North/API_test.htm

Vincent

Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> Philip Paeps <philip@paeps.cx> wrote:
> > Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:

[...]

> > > Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
> > > programmeren... Probeer maar eens een algemene database toepassing te
> > > schrijven in GNU C "open source", zonder beperkingen te leggen op welke
> > > database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC :)

[...]

> > Het komt neer op modularisatie.  Als je database parameters gaat hardcoden
> > (in *any* language) maak je er een soep van.  Als je ADO, DAO of andere
> > prutsjes gebruikt, ben je platform-afhankelijk.  (Open)ODBC is tergend
> > traag.
> 
> Misschien interessant om eens te lezen:
> http://ourworld.compuserve.com/homepages/Ken_North/API_test.htm

Boeiend.  Dat artikel is ondertussen meer dan zeven jaar oud.  

Ik moet eerlijk bekennen dat ik OpenODBC niet extensief gebruikt heb (om
verschillende redenen, de belangrijkste dat ik het niet nodig heb gehad omdat
de database libraries steeds ter beschikking waren), de paar keren dat ik het
echter wel - tegen beter weten in - gebruikt heb, was het mijn ervaring dat
het *tergend* traag was, in vergelijking met 'gewoon' gebruik van de API.  Dit
viel me op bij PostgreSQL en bij DB2.  Andere databases en pseudo-databases
heb ik nooit door OpenODBC geprobeerd wegens niet nodig, en wegens eerdere
turn-off.

Wil je alsjeblieft ook eens de settings van je newsreader nakijken?  Die helpt
linebreaks finaal om zeep, en wrapt op een hoogst idiote manier.  Niet
iedereen heeft een gq operator om zo'n rommel op te ruimen.

 - Philip

-- 
Philip Paeps                                                   philip@paeps.cx

  BOFH Excuse #288:
    Hard drive sleeping. Let it wake up on it's own...

"Philip Paeps" <philip@paeps.cx> wrote in message
news:zE8e9.106186$8o4.14778@afrodite.telenet-ops.be...
> Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> > Philip Paeps <philip@paeps.cx> wrote:
> > > Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
>
> [...]
>
> > > > Laat iedereen toch eens zijn eigen keuzes over hoe en waarin ze
> > > > programmeren... Probeer maar eens een algemene database toepassing
te
> > > > schrijven in GNU C "open source", zonder beperkingen te leggen op
welke
> > > > database er gebruikt dient te worden. Och ja, er is nu ook OpenODBC
:)
>
> [...]
>
> > > Het komt neer op modularisatie.  Als je database parameters gaat
hardcoden
> > > (in *any* language) maak je er een soep van.  Als je ADO, DAO of
andere
> > > prutsjes gebruikt, ben je platform-afhankelijk.  (Open)ODBC is tergend
> > > traag.
> >
> > Misschien interessant om eens te lezen:
> > http://ourworld.compuserve.com/homepages/Ken_North/API_test.htm
>
> Boeiend.  Dat artikel is ondertussen meer dan zeven jaar oud.
>
> Ik moet eerlijk bekennen dat ik OpenODBC niet extensief gebruikt heb (om
> verschillende redenen, de belangrijkste dat ik het niet nodig heb gehad
omdat
> de database libraries steeds ter beschikking waren), de paar keren dat ik
het
> echter wel - tegen beter weten in - gebruikt heb, was het mijn ervaring
dat
> het *tergend* traag was, in vergelijking met 'gewoon' gebruik van de API.
Dit
> viel me op bij PostgreSQL en bij DB2.  Andere databases en
pseudo-databases
> heb ik nooit door OpenODBC geprobeerd wegens niet nodig, en wegens eerdere
> turn-off.

Artikel is inderdaad vrij oud, 't komt uit Dr. Dobbs; er is in de tussentijd
wel al heel wat veranderd, denk maar aan connection pooling, parameter
binding, etc. die de performantie alleen maar naar boven kan halen!

Ik ben niet pro 't een of pro 't ander (ook niet uitgesproken voor Unix,
Linux, FreeBSD, Microsoft, noem maar op), maar ODBC is onder Microsoft (en
dus nu ook bvb. onder Linux) een heel makkelijk middel om een applicatie te
schrijven, zonder dat je op voorhand weet welke database er gebruikt zal
worden. Jouw wrapper verhaal is een oplossing, maar zoals je zei, er dient
gelinkt te worden met de native API's. Bij ODBC volstaat het dat er een
driver is en bovendien kan van de ene op de andere dag zonder hercompileren
of whatever een andere database gebruikt worden. Dit voordeel (en andere) is
zeker een van de redenen van het bestaan van dingen zoals o.m. UnixODBC.

Daarnaast niet onbelangrijk, platform-onafhankelijkheid is er, want de ODBC
code is dezelfde voor UNIX & Microsoft...

> Wil je alsjeblieft ook eens de settings van je newsreader nakijken?  Die
helpt
> linebreaks finaal om zeep, en wrapt op een hoogst idiote manier.  Niet
> iedereen heeft een gq operator om zo'n rommel op te ruimen.

Outlook Express standaard ingesteld

Vincent

Het is vrij gemakkelijk.  Hierbij een voorbeeldje
    Dim dbXLS As DAO.Database
    Dim rsXLS As DAO.Recordset
    Dim myVar as string
    Set dbXLS = OpenDatabase(xlsFile, False, False, "Excel 8.0;HDR=yes;")
    strSheet = dbXLS.TableDefs(0).Name
    Set rsXLS = dbXLS.OpenRecordset(strSheet)
    Do While Not rsXLS.EOF        ' elke lijn
        myVar = rsXLS.fields({kolomnummer})        'elke kolom
        rsXLS.Movenext
    loop
    rsXLS.Close
    dbXLS.Close

Wel Microsoft DAO 2.5/3.5 toevoegen aan uw References.

Geoffrey Frederickx
www.geoware.be
info@nospam.geoware.be



"Hugo Maes" <Hugo.Maes@chello.be> wrote in message
news:3D77E4C6.10EA0A65@chello.be...
> Weet er iemand hoe een bestaand Excel spreadheet uit te lezen vanuit
> Visual Basic [dus niet via VBA die in Excel zelf zit].
> Tenzij ik erover heb gekeken is er geen standaard ActiveX in VB zelf om
> dit te doen.
> Mijn probleem hierbij is dat het een tijdelijk project is dat ik in 1
> week klaar moet hebben, en daarom prefereer ik in mijn vertrouwde VB
> omgeving te blijven. Ook Google helpt me niet direkt op weg, noch mijn
> MSDN, noch mijn VB6 handboeken.
>
> mvg en dank bij voorbaat, HM