jbarr

One computing function that I'm surprised that no one has developed is the simple, cheap ability to remotely print documents across the Internet. I'm talking about creating some sort of "print file" on a remote PC, say .pdf, and then sending that file to my home PC where it would automatically print. It's the "automatically print it" part I'm struggling with. As an example, let's say I am at work. I am surfing the 'net, or I'm creating a document, and I would like to print out what I'm working on on my printer at home. My thought is to leverage .PDF creation apps, FTP, AutoIT's scripting, and an application like "DirMon2" that "polls" a folder and then executes an app (in this case, an AutoIT script) based on user-defined criteria. Here is the flow: While at work, I run any of a number of .PDF creation apps to generate the page(s) that I want to remotely print at home.I FTP to my home PC the resulting .PDF file(s) containing these pages. The home PC is running an application like DirMon2 that polls a folder for specific files, in this case, a .pdf file. When it finds the .pdf file in the folder, it would......execute some application that would print that .pdf file to a pre-defined printer on my home networkMy problem is step #4. I can very, very easily set up and accomplish 1,2 & 3, but how do I write an executable that would print a .pdf file to the default printer? Any suggestions?

This is very interesting. I came from the WinBatch world, but the company I now work for does not use WinBatch, so I decided to throw together an AutoIT solution. I just implemented an AutoIT application that leverages the Postie email program. It's kinda kludgy, but it is very stable, and works well. Basically, I needed an automated solution that would look for files in a directory and email those files as attachments to recipients defined within the files. The files are .CSV data files and the first line of each file contains the recipient's email address. these files are generated by SAP and translated into .CSV format using the GENTRAN EDI translator. The resulting files get dropped into a work directory, and a process executes every few minutes that looks for and processes any files. Here's the basic flow: 1. Start with a "working" directory. 2. Build a list of all files in that directory to process. This part is critical because it gives me a "snapshot" of the files at execution time. That way, any files that may drop into the directory during execution get will processed on the next execution. Everything needs to process, and everything needs to be accounted for. 3. Loop through the file list and process each file as follows: 3.1 Read the first line of the file. The first line contains the recipient's email address. 3.2 Build a complete Postie command string and write it to a batch file in a work directory. The postie command includes the to, from, subject, host, etc. The file being read is included in the Postie command string as an attachment. Almost all parameters are static except for the filename and the recipient. The static parameters are read from a .ini file for easy maintenance. 3.3 Execute the Postie batch file. This actually sends the file. 3.4 Move the data file and the Postie batch files to archive directories. Remember, I am only moving the files in the original file list as well as associated batch files. Any new files will get processed on the next run. 4. loop back to get next filename to process. Misc: I revise all filenames to include date and time stamps based on execution time. This aids in tracability. I added lines in the code to write to log a file at critical points to help with occasional troubleshooting. My only real problem is that I don't like the idea of having to jump out to execute Postie. At that point, I lose some control over execution status. Yes, Postie can return an error level that is handled by AutoIT, but it's a success / fail status. I cannot tell what errors actually occur if any. Fortunatly, I retain archives of the generated batch files so I can troubleshoot later if needed. But a full AutoIT solution would be much nicer! I can upload the sources if you want...

That's exactly what I'm going to do. I forgot that Postis is not "free" but BLAT is. Thanks!

Hi! I just installed a UPS (Uninterruptible Power Supply) on one of my PC's and I'm interested in setting up the Windows XP Pro's UPS services. The UPS provides battery backup for a PC, a router, a cable modem, and a Vonage Phone adapter. The Windows XP's UPS service has a setting that lets you optionally execute a program when the UPS notifies Windows XP that the power is off. I would like to simply have Windows auto-send an email notification when this happens and then shut itself down. The shutdown is a function of the UPS service, so that's a no-brainer. As far as the email notification, do you think this is something that would be appropriate for AutoIT or would it just be simpler to execute a Postie command? Thanks!

I was running into the EXACT same problem! I was REALLY confused about how to make it all work, so after perusing the forum and the help file, I put together a modification of one of the help scripts: Opt("GuiNotifyMode",1) GuiCreate ("Test-GUI", 200, 100) $bAbout = GuiSetControl ("button", "About", 40, 40,50); About Button $bExit = GuiSetControl ("button", "Exit", 110, 40,50); Exit Button GuiShow() ; display the dialog box While GuiMsg () > 0 if GuiRead () = $bAbout then MsgBox(0,"About","This is the About Box.") if GuiRead () = $bExit then exit Wend It displays a small GUI window with an "About" button and an "Exit" button. Clicking the "Exit" button exits the program, and clicking "About" displays a Message Box...but the GUI windows stays displayed! Kinda shows off AutoIT's power in simplicity. Hopefully, you can use this as a model to better understand how it works...

Concerning my above statement about "consolidating versions"... "Nutster" kindly informed me that the standard version is the release version while the GUI version is the current Beta version. Once some design decisions are made, the GUI version will become the release version. Very cool! OK, check that one off the list!

As I stated in another thread, I chose AutoIT as a "WinBatch" replacement. I spent 4 years using WinBatch to automate numerous EDI processes. I streamlined the processes into a VERY automated system requiring little more than occasional monitoring. WinBatch was a lifesaver when our EDI Translator wouldn't handle some of our "corporate idiosyncracies". Of course, using WinBatch was all well and good because the company paid for the $500.00 compiler. Now, I'm working for a different company, and we don't really have any need for WinaBatch. As a hobbyist though, I have several "projects" that have made me seriously consider saving up for that WinBatch compiler. But after playing around with AutoIT for a while, I have left WinBatch behind. It's a VERY slick programming language that, once you take the time to learn the ins and outs, is very powerful. That said, in keeping with the topic, here are some things that might help improve AutoIT and propell it more "mainstream": 1. Consolidate Versions I would love to see an eventual consolidation of the GUI version and the "standard" version. Maybe this will happen soon, but it's a bit confusing having two development forks. If I am missing something here, please correct me! 2. Develop A Decent IDE While there are a few very nice "GUI code creation" apps, I would lOVE to see a more "generalized" IDE. For my needs, I currently use UltraEdit with the AutoIT Syntax Hilighting enabled. This works VERY well, especially when I defined a "tool" to do the compiling. It's now as simple as "edit", click the tool button, and it auto-complies and runs. For MOST purposes, this is an excellent environment, and as a long-time programmer who isn't afraid of the vi editor, it's just fine. But to push it "mainstream" AutoIT may need a "safer", more "controlled" development environment. I'm not really sure what I mean by that. Maybe others can jump in. I guess what I'm saying is that providing a user with simpley a help document and some examples, (while traditionally, probably the BEST way to learn a programming language!) won't be that "attractive" given the "GUI-ness" of many other programming environments. Does that make sense? There are no doubt many other possible suggestions, but for now, those are really the only two "issues" that I have. AutoIT is truely an innovative and excellent scripting tool/programming language that really does more than most scripting tools. And the fact that it easily and simply creates "real .exe" files just rocks! In the end, it's saved me $500.00 that I would have otherwise (happily) spent on WinBatch.

Thanks guys! I used to program these types of things all the time using Wilson WindowWare's WinBatch, but since I'm at a new company, the WinBatch Compiler is no longer available to me, and I really can't justify spending the $500.00 for it for myself. So, AutoIT really fits the bill. It simply shines and is so simple! Oh, and as far as IE goes, I would prefer to use an alternative, but it's the "corporate standard" here, so it's what I use. Obvioiusly, there are inherent issues with IE, but for what we use it for, it's safe and secure enough.

Hi! I've been lurking around the forums for a while, and finally decided to throw together a simple "auto-launcher" application that I thought I would share if anyone else would find it useful. I'm sorry if this type of app has already been posted, but I didn't find one, so I just wrote my own. Every morning, I log onto my computer and go through the boring routine of launching the same 5 or so applications. They are the "core" apps that I need running throughout the day. Though it really isn't that tough to launch them, I wanted a "one-click" solution, so AutoIT did the trick. The app can be found here Basically, I defined an ".ini" file that has a section defining the number of applications to launch and then sections for each application that defines what and how to launch it. Note: You will have to tailor this .ini file to your needs. It will NOT run as-is because you most likely don't have the same apps loaded! The program reads this .ini file and just plugs in the values and launches the apps. It even looks to see if the app's process is already running to prevent duplicate launches. It's certainly not rocket science, but it does makes morning startup simpler and quicker. So, let me know what you think...suggestions are most welcome! -Jim

Excellent suggestions. Worked like a charm. Thanks!

The answer may be obvious, but I seem to be missing something... I have a GUI created using the AutoIT3-GUI extensions, and I would like to include an "Help" button that opens a web page (either a local or a Web URL) in Internet Explorer (or the default web browser.) I can't seem to figure out the best way to do this. The kicker is that I would like the GUI to remain open or available even with the Help window open. Anyone have a good suggestion to do this? Alternately, does anyone have a good suggestion to simply be able to open some sort of scrollable window that would contain the contents of a text file? (Maybe I could simply have it open Notepad.exe? Thanks!

Hi! Not sure if this has been posted before, but I was able to configure UltraEdit's "User Tools" functionality to auto-launch the current file you are editing using the "AutoIT3.exe" program. Simply click on "Advanced > Tool Configuration" and fill in the fields as shown below using your specific paths and then click the "Insert" button. (If you are using the beta GUI version, y9ou can replace "AutoIT3.exe" with "AutoIT3-GUI.exe") The AutoIT choice is now added to the Advanced menu. You can also right-click on the toolbar to add the Tool button if you want. NOTE: This does NOT check to see if the file you are working on is actually a valid .au3 file. It simply saves your current file and passes it to AutoIT3.exe. But it certainly is handy! Edit: You can also click on the "Advanced" button on the above screen and click "Browse". Next, navigate to the AutoIT\Auto2Exe\Icons directory and select one of the icons. The Toolbar icon in UltraEdit will not use that icon! -Jim

JdeB, Great app! I just installed it and used it on one of the apps I'm working on, and it cleaned things up very nicely. Great job! -Jim

Oooo. Nice! Basically what I'm doing, but a bit tighter and cleaner. Good to see I'm at least on the right track! My only real issue now is to figure out the best way to display everything: If I use a "MsgBox" then it requires user input and won't auto-refresh. And the fonts are set. If I use a "SplashText" function, I can nicely set a font, and it will auto-refresh nicely, but it doesn't seem to provide for any user interaction (short of terminating the app from the System Tray or moving the window.) It would be nice to at least have the "standard" GUI controls on the window (Minimize, Restore/Full, Close) but it is workable. Maybe I'll investigate some of the GUI extensions available...

OK, I figured it out! It's a bit kludgy, but it works. Here's what I did... First, I created a list of servers that I want to "ping". I then used the "_RunDOS" command to execute a "ping" command in the background for each server routing the output to a temporary file. I then simply parsed the temporary file looking for a specific string of text that would indicate a successful ping. From this, I build a status string that will later be displayed based on the existance of that string. I repeat this for each host that I have listed, and when finished, the result is a message box listing the hosts and their statuses. The source file can be found here: http://jim.barr.net/files/HostPingStatus.zip See the documentation in the .au3 file for details on how to use it and what features and improvements I'll be making. A few caveats: 1. You MUST follow the instructions in the documentation to configure it to your needs. 2. This only "pings" the host. It doesn't check services or anything else. It just checks to see if the host is reachable. 3. Depending on what version of Windows you are using, the "ping" command may or may not return the same string. I tested this on Windows XP Pro, and it works fine for me. 4. If your hosts are not normally reachable by the "ping" command, this will obviously not work. This is fun! -Jim http://jim.barr.net http://jimstips.com