vb filesystemobject :?

[disjfa]

ok, dit wordt een domme vraag.

ik moet nou ff een directory doorlezen en wat files moven. daar hen ik dus ff een filesystemobject voor nodig.
ik rustig de msdn copypasten, maar hij wil nie met dat filesystemobject werken.

componentje of waar moet je hem als eerst declareren?

[Mart!]

Als we niet weten wat je gepaste hebt, kunnen we je erg lastig helpen. In ieder geval moet je het object aanmaken. En gebruik je VB of VBScript (ASP)?

code:

'[VBScript] (werkt ook in VB)
dim fso as object '(alleen in vb nodig)
set fso = CreateObject("Scripting.FileSystemObject")

'[VB]
'Microsoft Scripting Runtime als reference instellen en dan
Dim fso AS New FileSystemObject

[disjfa]

ik gebruik vb, en dat is zo ongeveer wat ik gepaste heb.

maar als ik dan werkt de filesystemob.. nog steeds nie bij mij

moet je er een xtra componentje voor hebben, lijkt me sterk, maar het kan..

[Basszje]

Disjfa! Lees nou je devguru, had ik toch gezegd

[code]
dim FSO
set FSO = Server.CreateObject("scripting.fileSystemObject")
dim folder
set folder = FSO.Getfolder("d:\bla\images")

dim objfile
for each objfile in folder.files
response.write objfile.name
next

En zo werken de rest van de methodes dus ook .
Have fun

edit:

Ow in VB, dan moet je bij de References even de microsoft scripting library toevoegen, want daar staat ie in en dan werkt ie wel

[disjfa]

Op woensdag 17 oktober 2001 09:53 schreef BaSSzje het volgende:
Disjfa! Lees nou je devguru, had ik toch gezegd

[code]
dim FSO
set FSO = Server.CreateObject("scripting.fileSystemObject")
dim folder
set folder = FSO.Getfolder("d:\bla\images")

dim objfile
for each objfile in folder.files
response.write objfile.name
next

En zo werken de rest van de methodes dus ook .
Have fun

edit:

Ow in VB, dan moet je bij de References even de microsoft scripting library toevoegen, want daar staat ie in en dan werkt ie wel

jup, asp, das leuk, maar nu in vb

[Greyfox]

ASP kun je bijna 1-op-1 copieren naar VB

[disjfa]

het probleem komt bij de dim fso as new filesystemobject, dan errort ie van not userdivined

en dat zou t gewoon moeten doen

[Greyfox]

Dan dim je hem toch gewoon als object.
(of je voegt de reference naar het scripting object toe)

[Basszje]

Op woensdag 17 oktober 2001 09:58 schreef disjfa het volgende:
het probleem komt bij de dim fso as new filesystemobject, dan errort ie van not userdivined

en dat zou t gewoon moeten doen

Dit is een contaminatie .
Het is :
dim FSO as FileSystemobject -of :
set FSO = new FileSystemObject

En voeg je reference toe .

Ik ben trouwens meer fan van :
dim FSO as FileSystemObject
set FSO = CreateObject("scripting.filesystemobject")

[disjfa]

die laaatste wil dus nie, maar t draait nu als een treintje en ik heb niks nieuw meer onder de zon,

nog ff paar regels scripten en een keetje
uiteindeleijk is t allemaal zo

[Crazy D]

Op woensdag 17 oktober 2001 11:39 schreef BaSSzje het volgende:
Dit is een contaminatie .
Het is :
dim FSO as FileSystemobject -of :
set FSO = new FileSystemObject

1e regel declareert de variabele FSO
2e regel initializeert 'm

Kun je (mag je..) ook samenvoegen tot 1 regel:
Dim FSO As New FileSystemObject

En voeg je reference toe .

Inderdaad

Ik ben trouwens meer fan van :
dim FSO as FileSystemObject
set FSO = CreateObject("scripting.filesystemobject")

Hoezo?
Ten 1e heb je dan geen intellisence binnen VB, ten 2e is het trager, ten 3e controlleert VB dan pas at runtime of de aangeroepen functies ed. ook echt bestaan en met de juiste params, .. uh en er zal nog wel een ten 4e zijn maar die weet ik ff niet meer

[Basszje]

Op woensdag 17 oktober 2001 13:57 schreef Crazy_D het volgende:
Kun je (mag je..) ook samenvoegen tot 1 regel:
Dim FSO As New FileSystemObject

Hoezo?
Ten 1e heb je dan geen intellisence binnen VB, ten 2e is het trager, ten 3e controlleert VB dan pas at runtime of de aangeroepen functies ed. ook echt bestaan en met de juiste params, .. uh en er zal nog wel een ten 4e zijn maar die weet ik ff niet meer

ow kjoh, dan van 1 regel wist ik nie . Nah ja weer wat geleerd.

Ik had trouwens links en rechts gelezen dat de createObject methode beter is dan de new methode?

[Crazy D]

Op woensdag 17 oktober 2001 14:20 schreef BaSSzje het volgende:
Ik had trouwens links en rechts gelezen dat de createObject methode beter is dan de new methode?

Je kan er ook beter recht voor zitten

Createobject is op zich wel handig als je dynamich dll's wil laden (leuk voor plugins....) maar tis het zogenoemde Late Binding. Pas op het moment dat CreateObject uitgevoerd wordt, checkt de runtime of de class bestaat, en of de funcities goed zijn ed. (Interdev doet dat trouwens wel ook tijdens het coden, wat erg prettig is i.v.m. intellisence ). VB dus niet, heb je dus alleen intellisence via de new methode. VB checkt dan tijdens het compilen de boel, dus fouten worden er eerder uitgehaald. En 't is iets sneller (ergens gelezen, heb nog nooit 1000 objecten zitten aanmaken en timen ). Maar kan ik me wel iets bij voorstellen, aangezien VB tijdens het compilen de interface van de dll al kent, en dan dus alles kan controlleren. Scheelt dus at runtime checks.
Waar had je dat gelezen dan? Ben nl. op zich best wel benieuwd wat er in die artikelen staat dan.

[Basszje]

Hmmm ziet er naar uit dat ik weer eens heb lopen dagdromen .
Maar nog wat info dan :

1. The main advantage is that code which uses late binding is more certain to be version-independent

If you set a reference in a Word 97 project to Microsoft Excel 8.0 Object Library, then the project willrun OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the Microsoft Excel 9.0 Object Library.

But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional cannot open macro storage error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library. So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead.

2.
The more references your project contains, the larger the file size and the longer it takes to compile.

3.
Some programming environments don't allow you to create references to another application.

^


Dim obj As New TheClass()
In VB6 this was a very poor thing to do, as it had both negative performance and maintainability effects. However, in VB.NET there is no difference between our first example and this one, other than that our code is shorter.
^

[Greyfox]

Op woensdag 17 oktober 2001 15:33 schreef Crazy_D het volgende:

[..]
Createobject is op zich wel handig als je dynamich dll's wil laden (leuk voor plugins....) maar tis het zogenoemde Late Binding. Pas op het moment dat CreateObject uitgevoerd wordt, checkt de runtime of de class bestaat, en of de funcities goed zijn ed. (Interdev doet dat trouwens wel ook tijdens het coden, wat erg prettig is i.v.m. intellisence ). VB dus niet, heb je dus alleen intellisence via de new methode. VB checkt dan tijdens het compilen de boel, dus fouten worden er eerder uitgehaald. En 't is iets sneller (ergens gelezen, heb nog nooit 1000 objecten zitten aanmaken en timen ). Maar kan ik me wel iets bij voorstellen, aangezien VB tijdens het compilen de interface van de dll al kent, en dan dus alles kan controlleren. Scheelt dus at runtime checks.
Waar had je dat gelezen dan? Ben nl. op zich best wel benieuwd wat er in die artikelen staat dan.

Dat is dus niet helemaal ofwel helemaal niet waar.
Late of early binding vind plaats aan de hand van het datatype van de variabele declaratie.
Dus als je 'Dim obj As Object' doet, dan is het zeker late binding, maar als je 'Dim obj As Scripting.FileSystemObject' doet, dan zal die zeker early binden en dan zal ook intellisense het doen in VB.
Als je 'New' gebruikt, heeft dat met name impact als je MTS of Com+ gebruikt. Daar wordt juist afgeraden om New te gebruiken omdat dan het object niet in de transactie van het andere object geplaatst kan worden.
Je kunt in ieder geval altijd 'CreateObject' gebruiken.

[Verwijderd]

Moeilijk, moeilijk

Let op:

1. Early Binding (ofwel je project wordt gecompileerd met de classID van het gerefereerde object)

code:

Dim objFSO As Scripting.FileSystemObject
Set objFSO = New Scripting.FileSystemObject

Voordeel: sneller dan late binding, doordat het object direct wordt aangesproken via de V-Table.
Nadeel: werkt alleen als je de gerefereerde component hebt, of een latere versie die backwards compatible is.

2. Late Binding (Geen intelli-sense)

code:

Dim objFSO As Object
Set objFSO = CreateObject("Scripting.FileSystemObject")

Voordeel: versieonafhankelijk, werkt als er een versie van Scripting.FileSystemObject op het systeem aanwezig is, maar kan conflicten opleveren i.v.m. functies die niet worden ondersteunt. Erg handig bij Office 97 <-> Office 2000 problemen.
Nadeel: elke keer dat het object wordt aangesproken moet de VB-Runtime via de iUnknown en iDispatch interfaces de functie controleren en aanroepen. (Dus relatief traag.)

3. MTS
Als je object binnen MTS in dezelfde ObjectContext (lees transactie) wilt laten participeren kan dat ALLEEN op onderstaande wijze:

code:

Set objFSO = GetObjectContext.CreateInstance("Scripting.FileSystemObject")

Je mag objFSO overigens zowel via Early als Late Binding declareren.

4. Dim objFSO As New Scripting.FileSystemObject
NOOIT GEBRUIKEN
Door deze declaratie zal de VB-Runtime bij elke aanroep naar het object moeten controleren of het reeds bestaat en indien dat niet zo is het object moeten aanmaken:
rete inefficiënt...


Zo, dat was het weer voor nu...

[Crazy D]

Kewl, weer wat geleerd