 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2007Executing vbscript
Hi all, I have a vbscript that I would like to execute from java. It takes 4 arguments, and example usage follows: "C:\cvs_checkout\tool\Projects\UserInterface\utils \ReplaceWorksheets.vbs" "C:\Documents and Settings\vandenbergl\Desktop \sheet.xml" "Sheet 1,Sheet 2" "C:\Documents and Settings\vandenbergl \Desktop\Test\another sheet.xml" "sheet 1,sheet 2" Here is the code that I'm using at the moment: String[] command = {"cmd.exe", argument}; try { Process mergeProcess = Runtime.getRuntime().exec(command); } catch (IOException ioe) { ioe.printStackTrace(); } Where argument is the expression I gave above. If I executre the expression I gave at a prompt it does exactly what I want, but the java code I gave doesn't do anything at all. It doesn't throw any exceptions but it appears the script hasn't even run! Any ideas about how I can get the script to run? > String[] command = {"cmd.exe", argument}; Not real sure, but works for me with my "test.vbs". String[] command = {"cmd.exe", "cscript", argument}; On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > Hi all, > > I have a vbscript Ugh ... excuse me ... need to ... *BLEERRRTCH!* Yep. RIGHT after I finished eating lunch of course. And here I had been thinking cljp was a fairly safe part of usenet when on a full stomach, too. :P > On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > [quoted text clipped - 8 lines] > And here I had been thinking cljp was a fairly safe part of usenet > when on a full stomach, too. :P Don't blame you. If I could avoid it I would. I have to manipulate excel spreadsheets, I tried one java library to manipulate excel spreadsheet saved as xml and it failed miserably. So, I'm stuck with very bad script (vbscript). On Aug 21, 6:46 pm, "lion...@gmail.com" <lion...@gmail.com> wrote: > > On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > [quoted text clipped - 13 lines] > spreadsheet saved as xml and it failed miserably. So, I'm stuck with > very bad script (vbscript). Egads! And I thought nursing, pet store litterbox scooping guy, sewage treatment, and septic tank servicing were dirty jobs. At least you can hold your nose or wear a respirator or something in those jobs. Here you'd have to close your eyes, and then you won't be able to see what you're doing to do your job. How utterly bletcherous! > Hi all, > [quoted text clipped - 23 lines] > > Any ideas about how I can get the script to run? Why run a VB script from Java? You'll never make a portable application that way. Why not rewrite the VB script into Java, or alternatively, write it in javascript and use the scripting api in Java 6. > > Hi all, > [quoted text clipped - 26 lines] > Why run a VB script from Java? You'll never make a portable > application that way. State the obvious :). > Why not rewrite the VB script into Java, or alternatively, write it in > javascript and use the scripting api in Java 6. I need to manipulate excel spreadsheets. Can I do that with scripting API in Java 6? Aside from that, the minimum requirements for the user is Java 5. I didn't take this decision lightly. I was hacking out the excel xml files by hand at one stage but it just proved to be to much work and too fragile for when M$ changes their xml format (you know it will happen :)). I'm able to wrap the whole problem up in verybadscript in about 10 lines of code. Lionel. > I need to manipulate excel spreadsheets. Can I do that with scripting > API in Java 6? Aside from that, the minimum requirements for the user > is Java 5. I didn't take this decision lightly. I was hacking out the > excel xml files by hand at one stage but it just proved to be to much > work and too fragile for when M$ changes their xml format (you know it > will happen :)). <OT> Are you talking about MS's "Office Open XML" format? The last I heard, that was denied an ISO standard (something about being poorly documented, too long, and impossible to understand, I think). </OT> I know that there are APIs to work with the old formats of Excel spreadsheets, and there might be some headway into working with the newer one. What prevents you from converting the VB script into Java and using those APIs? If executing the VBscript is important, it might be better to use a JNI bridge to execute the Windows API to execute the VBscript directly as opposed to running through cmd.exe (which doesn't exactly do what you want, AFAIK). Even better would be to directly execute a VBscript interpreter (there is probably an executable somewhere in C:\WINNT\system32 that does that).  SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > <OT> > Are you talking about MS's "Office Open XML" format? The last I heard, > that was denied an ISO standard (something about being poorly > documented, too long, and impossible to understand, I think). > </OT> I know, it's a load of rubbish. And they don't even release the DTD for it. > I know that there are APIs to work with the old formats of Excel > spreadsheets, and there might be some headway into working with the > newer one. What prevents you from converting the VB script into Java and > using those APIs? Well I started with the xelem API and it failed miserably creating a file that excel could not open. Perhaps I should try some others but it's really a concern if someone uses a newer version of excel that can't be read by the library that I use. Argh, I wish I didn't have to deal with it at all! > If executing the VBscript is important, No, it's not, it just seems the most likely to be successful well into the future :(. > it might be better to use a JNI > bridge to execute the Windows API to execute the VBscript directly as > opposed to running through cmd.exe (which doesn't exactly do what you > want, AFAIK). Even better would be to directly execute a VBscript > interpreter (there is probably an executable somewhere in > C:\WINNT\system32 that does that). I'll see what I can find out about these ideas. >> <OT> >> Are you talking about MS's "Office Open XML" format? The last I heard, [quoted text clipped - 4 lines] > I know, it's a load of rubbish. And they don't even release the DTD > for it. The DTD would probably be longer than the average file that would use it! (Then again, the XHTML 1.1 Transitional DTD is ~31.3 KB and many (X)HTML pages are much smaller than that, so... Granted, however, that DTD is full of comments and whitespace) SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > <OT> > Are you talking about MS's "Office Open XML" format? The last I heard, > that was denied an ISO standard (something about being poorly > documented, too long, and impossible to understand, I think). > </OT> I know, it's a load of rubbish. And they don't even release the DTD for it. > I know that there are APIs to work with the old formats of Excel > spreadsheets, and there might be some headway into working with the > newer one. What prevents you from converting the VB script into Java and > using those APIs? Well I started with the xelem API and it failed miserably creating a file that excel could not open. Perhaps I should try some others but it's really a concern if someone uses a newer version of excel that can't be read by the library that I use. Argh, I wish I didn't have to deal with it at all! > If executing the VBscript is important, No, it's not, it just seems the most likely to be successful well into the future :(. > it might be better to use a JNI > bridge to execute the Windows API to execute the VBscript directly as > opposed to running through cmd.exe (which doesn't exactly do what you > want, AFAIK). Even better would be to directly execute a VBscript > interpreter (there is probably an executable somewhere in > C:\WINNT\system32 that does that). I'll see what I can find out about these ideas. > <OT> > Are you talking about MS's "Office Open XML" format? The last I heard, > that was denied an ISO standard (something about being poorly > documented, too long, and impossible to understand, I think). > </OT> I know, it's a load of rubbish. And they don't even release the DTD for it. > I know that there are APIs to work with the old formats of Excel > spreadsheets, and there might be some headway into working with the > newer one. What prevents you from converting the VB script into Java and > using those APIs? Well I started with the xelem API and it failed miserably creating a file that excel could not open. Perhaps I should try some others but it's really a concern if someone uses a newer version of excel that can't be read by the library that I use. Argh, I wish I didn't have to deal with it at all! > If executing the VBscript is important, No, it's not, it just seems the most likely to be successful well into the future :(. > it might be better to use a JNI > bridge to execute the Windows API to execute the VBscript directly as > opposed to running through cmd.exe (which doesn't exactly do what you > want, AFAIK). Even better would be to directly execute a VBscript > interpreter (there is probably an executable somewhere in > C:\WINNT\system32 that does that). I'll see what I can find out about these ideas. On Aug 22, 11:16 am, "lion...@gmail.com" <lion...@gmail.com> wrote: Sorry about the multiple posts! I don't normally use GG but for some reason everytime I've been pressing refresh it seems to have posted again for me! > On Aug 22, 11:16 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > > Sorry about the multiple posts! I don't normally use GG but for some > reason everytime I've been pressing refresh it seems to have posted > again for me! No worries. If any community is aware that Google Groups is crap, it's the readers of this newsgroup. I think you'll find that people are not prejudiced against GG users here, but we are highly annoyed by GG itself. Do your best to work around its flaws if you don't want to piss anyone off, or better yet, switch newsreaders to another of the free ones out there that lacks Google Groups's manifest flaws. SignatureLew On Aug 21, 4:02 pm, "lion...@gmail.com" <lion...@gmail.com> wrote: > > > Hi all, > [quoted text clipped - 43 lines] > > Lionel. What kind of manipulation are you doing to an excel spreadsheet? Can you require the spreadsheet to be in CSV, or some other well-defined, format first? > On Aug 21, 4:02 pm, "lion...@gmail.com" <lion...@gmail.com> wrote: > [quoted text clipped - 49 lines] > you require the spreadsheet to be in CSV, or some other well-defined, > format first? Removing and inserting worksheets. Unfortunatley CSV is not suitable. The user has spreadsheets that are highly technical and have several formatting styles due to their preferences (but at the same time follow a standard layout). For usability reasons that layout must be preserved and CSV would lose all of these details. After seeing the lack of support I'm considering an alternative whereby I will have 2 spreadsheets. This will allow me to get around having to do any writes to any spreadsheet. That way I only have to read the sheets and the Java libraries handle reading sufficiently well. Thanks Lionel. On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > Hi all, > [quoted text clipped - 23 lines] > > Any ideas about how I can get the script to run? Be sure you're reading everything the process object writes into its streams. > On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > [quoted text clipped - 28 lines] > Be sure you're reading everything the process object writes into its > streams. I did as you said (good point btw) but I get the following uninteresting output: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. and then the input stream blocks indefinitely. Lionel. On Aug 22, 9:11 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > > On Aug 21, 2:47 am, "lion...@gmail.com" <lion...@gmail.com> wrote: > [quoted text clipped - 36 lines] > > and then the input stream blocks indefinitely. Should probably have included: Process process = Runtime.getRuntime().exec(command); BufferedReader streamReader = new BufferedReader( new InputStreamReader(process.getErrorStream())); String line; while ((line = streamReader.readLine()) != null) { System.out.println(line); } I did the above for both input stream and error stream. error stream gives nothing! > Hi all, > [quoted text clipped - 22 lines] > > Any ideas about how I can get the script to run? You might try using the new Desktop class. I've found that it is a great improvement over Runtime.exec() for many things. It is also more portable. SignatureKnute Johnson email s/nospam/knute/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.