The watcher then calls AutoCAD with the new file object. The PS script then gathers all the data, reformats it for the AutoLISP routine, and moves it to the folder that is being watched. In this system, the output actually consists of several data files, spread across multiple folders, and one 'flag' file, to indicate the all data has been written. Jvierra,Watching for new files is what I need it to do.
EXE call outside of the FSW routine.Does this shed any better light? My project has not changed, has not morphed beyond my original post.You have been a great help, and I appreciate it immensely! I do apologize if I've not characterized this properly.Tim EXE closed prior to the WaitForExit.As I've also posted, I did try a single script (that would be my preferred method), but $ntpd2.kill() (from the above example) kills the FileSystemWatcher as well, causing me to look to move the actual.
The code flow is PowerShell -> PowerShell -> EXE (Notepad or AutoCAD). EXE, and return to the calling, main, script.From the rest of your reply, I see I didn't state properly what result I wanted. EXE exits within the wait time, FALSE if it doesn't), and using that allows me to error check the input scripts (move them to an error folder), and the. As the script stands now, $ntpd2 does return the proper values (TRUE if the. I will say that, it appears that $LASTEXITCODE is not what I needed. I apologize if this is way to n00b.I suppose it's possible that I've not expressed my problem in the correct terms, and for that I also apologize. In my development, I can use the event block as a stand-alone script, if I manually enter the arguments that would be returned by FSW when the event is triggered. To me, the event block of FSW is just another script. True, I was not overly specific, as I didn't realize it needed to be. I have a script that uses FileSystemWatcher to catch and process new files in a given folder. Jvierra,I did not intentionally mislead you. I have to modify it to call AutoCAD now, but I'm confident it will work, with your help! Again, thank you very much!And, yes, it is PowerShell calling PowerShell.Thanks!Tim The TRUE/FALSE results are working now, as well (Thank you!!), with NOTEPAD.EXE as the external program (called by the second script). With this result, I began to examine having the 'create' event call an external script, which is now working. This isn't a good option, as this is part of a production sales/quoting application we use, both internally and for our external customers. kill() method on the AutoCAD process, it also killed the Watcher (put another way, no more "create" events were processed until the entire script was restarted. I found, in my testing, that if I used the. The event code then moves the output to a configured location. Jvierra,The reason I'm using two scripts is this: The main script is using FileSystemWatcher, and using the 'Created' event to trigger the AutoCAD process to create a drawing based on the AutoLISP script passed to it. I appreciate any help that can be offered. I'm obviously missing something, but, I'll be darned if I can find it. I've also tried calling it with "&", and "$proc="nameofps1exe", with no success. I've tried adding "exit $LASTEXITCODE" to the end of the external script, with no success. EXE from PrimalScript), and call that from the FSW event block I can't, however, get the return code of this external script/exe. I've decided to move the AutoCAD launch to an external process (a compiled. Initally, I was going to use this inside the event code block of the FSW process, but this proved to kill the FSW process, too, so, while it did kill AutoCAD, it did not pick up subsequent scripts.
This isn't really acceptable (production uses this box, too), so I modified my from WaitForExit() to WaitForExit(300000), and kill the AutoCAD process if the wait expired. However, during development, it's not uncommon for a generated autocad script to not function properly, and 'hang' autocad. This particular case happens to be scripts for AutoCAD.
Hello! I've done some searching, and it seems like capturing $LASTEXITCODE should be easy, however, it's proving not to be.Here's the scenario:I have a script that uses FileSystemWatcher to catch and process new files in a given folder.