[ASP/VB 6.0] MS worddocumenten openen vanaf webpagina

[Verwijderd]

Ik heb een VB-applicatie geschreven waarin er via het Wordobject worddocumenten worden geopend. Wanneer ik de VB-applicatie direct draai vanaf mijn PC werk alles perfect. Echter wanneer ik de applicatie aanroep vanuit een ASP-pagina d.m.v. een wscriptshell kunnen de worddocumenten niet geopend worden. De rechten voor de werkdirectory en de worddocumenten waarmee gewerkt wordt staan op 'alle bewerkingen toestaan voor iedereen'. Dit wordt tevens bevestigd door het feit dat het VB-programma wél de betreffende documenten kan hernoemen (ook wanneer het programma via de wscriptshell vanuit de ASP-pagina wordt gestart).

Visual Basic:

Dim oWord As New Word.Application
Dim oDoc As Word.Document

'Hier gaat het dus mis
Set oDoc = oWord.Documents.Open("blaat.doc") 

PS - Wanneer ik op mijn PC kijk zie ik trouwens wel dat er geprobeerd wordt om een worddocument te openen, aangezien er zo'n verborgen tijdelijk worddocument in de werkdirectory komt te staan.

[Verwijderd]

Krijg je een foutmelding of zie je gewoon niets?

Bedenk je dat het gebruik van ActiveX op een webpagina kan leiden tot grote beveiligingsproblemen, waardoor ze door veel beveiligingssoftware worden geblokkeerd. Wellicht werkt de software goed maar wordt het geblokkeerd.
Ik heb geloof ik iet goed gelezen, want dit verhaal klopt niet

[ Voor 12% gewijzigd door Verwijderd op 18-08-2005 16:07 ]

[mulder]

Er is verschil tussen client- en serverside VBscript. Ik denk dat je nu serverside draait, zodat het Word document op de server word geopend en niet op de client.

[Verwijderd]

Don Facundo schreef op donderdag 18 augustus 2005 @ 15:27:
Er is verschil tussen client- en serverside VBscript. Ik denk dat je nu serverside draait, zodat het Word document op de server word geopend en niet op de client.

Indeed. En de worddocumenten worden door een gecompileerde VB-applicatie geopend i.p.v. dat ze door vbscript worden geopend. Althans het is de bedoeling dat de worddocumenten geopend worden. De gecompileerde VB-applicatie wordt vervolgens weer vanuit ASP aangeroepen d.m.v. het shellcommando.

Edit:

Ik heb de beveiliging van de complete MS-Office-map nu net naar 'alles toestaan voor iedereen' gezet en nog steeds loopt het programma vast op het moment dat er een document in MS Word geladen wordt..

[ Voor 16% gewijzigd door Verwijderd op 18-08-2005 16:00 ]

[Verwijderd]

Verwijderd schreef op donderdag 18 augustus 2005 @ 15:16:
Krijg je een foutmelding of zie je gewoon niets?

Bedenk je dat het gebruik van ActiveX op een webpagina kan leiden tot grote beveiligingsproblemen, waardoor ze door veel beveiligingssoftware worden geblokkeerd. Wellicht werkt de software goed maar wordt het geblokkeerd.

Ik krijg geen foutmelding want het programma wordt niet direct uitgevoerd, maar via een webpagina. Tevens springt het programma ook niet naar het label dat ik bij 'on error goto' heb gespecificeerd. Ik heb dus ook geen idee hoe ik achter het probleem kan komen aangezien ik geen foutmeldingen terugkrijg.

[Verwijderd]

Sorry, mijn eerdere opmerkingen klopten van geen kant, dus vergeet deze even.

Waarom maak je niet een COM component met de functionaliteit die nu in het VB programma zit? Je kunt het component dan creeeren door een Server.CreateObject("[objectnaam]") en vervolgens de juiste functionaliteit aanroepen. Dan draait alles binnen 1 security context en krijg je ook eventuele fouten door vanuit het COM component, zodat je zinvol kan debuggen en eventueel zinvolle error handling kan implementeren.

[Verwijderd]

Na wat kloten heb ik nu een foutcode + foutomschrijving: foutcode: 5981 omschrijving: Could not open macro storage.

Het lijkt er dus op dat het worddocument wel geopend wordt, maar dat het worddocument niet door gestuurd kan worden naar de virtuele PDF-printer die d.m.v. een macro automatisch het betreffende worddocument omzet naar PDF en in een vooraf ingestelde map gooit. De macro's binnen MS Word heb ik al op 'laag' gezet.

Het printen naar de virtuele printer even uitgezet. Ik krijg nog steeds dezelfde melding, dus het probleem zit hem in het openen van een worddocument.

[ Voor 18% gewijzigd door Verwijderd op 18-08-2005 17:19 ]

[Verwijderd]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:10:
Sorry, mijn eerdere opmerkingen klopten van geen kant, dus vergeet deze even.

Waarom maak je niet een COM component met de functionaliteit die nu in het VB programma zit? Je kunt het component dan creeeren door een Server.CreateObject("[objectnaam]") en vervolgens de juiste functionaliteit aanroepen. Dan draait alles binnen 1 security context en krijg je ook eventuele fouten door vanuit het COM component, zodat je zinvol kan debuggen en eventueel zinvolle error handling kan implementeren.

Wat is het verschil tussen het aanmaken van een COM-Word-component en het direct aanmaken van een Word-component? Ik krijg nu immers toch ook gewoon een foutbericht terug?

Je kunt in VB trouwens toch niet met 'Server.CreateObject' werken?

[ Voor 6% gewijzigd door Verwijderd op 18-08-2005 17:24 ]

[Verwijderd]

Verwijderd schreef op donderdag 18 augustus 2005 @ 17:23:
[...]


Wat is het verschil tussen het aanmaken van een COM-Word-component en het direct aanmaken van een Word-component? Ik krijg nu immers toch ook gewoon een foutbericht terug?

Ik maakte mijn suggestie was voordat je meldde dat je een error kreeg. Ik was bang dat de scripting shell de foutmelding niet goed zou doorgeven.

Het probleem lijkt te zitten in een security context, die vanaf de user waaronder IIS anonymous access toelaat wordt overgedragen naar de uiteindelijke Word macro. Nogsteeds is het door het groot aantal lagen lastig te debuggen wat er precies gebeurt. Wat minder lagen maakt het wellicht toch wat makkelijker debuggen.

Jij doet momenteel (als ik het goed begrijp) dit:
ASP (VBScript) --> WScriptShell --> Applicatie (VB) --> Word (Macro) --> PDF Printer

Ik stel voor om wat schakels hieruit te halen, met 2 alternatieven:
1) ASP (VBScript) --> COM Object (VB) --> Word (Macro) --> PDF Printer
2) ASP (VBScript) --> Word (Macro) --> PDF Printer

Optie 1 is misschien wat eenvoudiger te debuggen, omdat je het COM object binnen je VB omgeving kan testen voordat je het vanuit je ASP pagina gaat aansturen. Optie 2 is iets directer, maar dan moet je je Word aansturing volledig in VBScript doen, wat een beetje lastiger debuggen is.

Ik weet ook niets af van office specifieke securityeisen en -instellingen, dus daarvoor zal je in de documentatie moeten duiken, of misschien kan iemand anders je helpen.

Je kunt in VB trouwens toch niet met 'Server.CreateObject' werken?

Vanuit VB werk je met CreateObject(), aangezien je geen Server context hebt. Jij gebruikt New in je code en dat doet vrijwel hetzelfde, dus dit is verder een niet relevant punt. Ik moet wel zeggen dat VB / COM alweer een tijdje geleden voor mij is, dus de specifieke dingen weet ik niet uit mijn hoofd.

[Verwijderd]

Bedankt voor de tips. Ik heb de keten wat versimpeld en ben tot de conclusie gekomen dat het probleem hem (toch) ligt in de afdrukpermissies. Het worddocument kan namelijk wel goed geopend en e.v.t. opgeslagen worden. Ik ga dus nog maar eens wat googlelen.

Edit:

Na wat foutopsporing krijg ik de volgende fout:

Foutnummer: 5140
Omschrijving: Word cannot print. There is no printer installed.

Deze foutmelding krijg ik als ik zowel naar een fysieke als virtuele printer afdruk.

Edit 2:

Ik ben achter het probleem. Het blijkt dat het VB-programma het register niet kan accessen en dus niet kan afdrukken (wanneer het vanuit een webpagina via een shell wordt aangeroepen).

[ Voor 54% gewijzigd door Verwijderd op 19-08-2005 12:43 ]