With Christmas round the corner I thought I might post a reminder that we have a number of official logo T-shirts, mugs and mouse mats available via Zazzle.com:
Marcus' Macro Blog
Mostly tips, tutorials, articles and news about Macro Scheduler & Windows Automation
Archive for the ‘General’ Category
Macro Scheduler T-Shirts and Merchandise
Monday, December 13th, 2010Video Tutorial – Macro Scheduler for Non-Technical Beginners – Part 1
Tuesday, November 30th, 2010Following my recent request for video tutorial contributions long-time Macro Scheduler user Peter Begelsdorf has stepped up to the plate and put together a short tutorial aimed at the non-technical beginner.
This slick three minute video introduces the fundamental, yet very important, SendText and Press commands and shows beginners how to create a simple text macro assigned to a hot key.
Peter is now planning to create a sequel to expand on the basics and explain how to execute a file and wait for a program to be ready.
While many of my regular readers may be amongst the more technical and experienced Macro Scheduler users I think these new videos will be a great help to newcomers to the software.
Peter Bengelsdorf is a media integration consultant who was a newspaper editor when he started using Macro Scheduler more than a decade ago. For his contribution Peter has been awarded free future Macro Scheduler updates and a WebRecorder license.
If you would like to create a video tutorial or have ideas for one, please let me know. We’re giving away licenses and future upates to video contributors.
This tutorial has been added to the Video Tutorials page.
Support Email Rant
Tuesday, November 23rd, 2010I received the following email today (I have paraphrased and anonymised it to protect the innocent):
“We were given a Macro Scheduler script to run on our system that someone else wrote which we are trying to use with your trial version. It doesn’t work. Your product seems to be very flaky and unreliable. Is this a feature of the trial version?”.
Now, when I read an email like that I have to breathe carefully and compose myself. To see what’s wrong with it let’s reword the same message as if it were talking about a different product:
“We were given a VBScript file which someone else wrote and we are trying to run it on our system but having problems. Microsoft VBScript must be very buggy!”
Yeh, so because a script that someone else built using a particular product is buggy the user thinks it is the product that is buggy. It seems not to have occurred to them that the script they were given is clearly not put together very well, or at least not written to run on their system. It hasn’t crossed their mind to report back to the person who wrote the script. For all we know the person who wrote it never intended it to be run on any other system but his/hers anyway.
You can build all kinds of dodgy, bug-ridden and dangerous software with C++. Does that mean Microsoft Visual Studio has a bug?
I’ve downloaded lots of dodgy VBscript code snippets, buggy PHP files and Perl scripts that fail to do what the author says they do, or need tweaking to work on my system. It never occurred to me to blame the VBScript, PHP or Perl interpreters. Next time rather than email the author of the code I’ll email Microsoft, PHP.com or Larry Wall instead.
Sheesh.
Creating Native Function Aliases for Win32 Functions
Monday, November 15th, 2010The other day I posted a response on the forums which uses LibFunc to run the Win32 API function GetKeyState. This prompted someone to email me the following:
I didn’t know the Win API call to check for a key being down. The API call works but have you considered adding a native MS command called KeyDown> or maybe CheckKeyDown>
Well, it’s already possible to create native looking functions for DLL functions and therefore Win32 API functions.
We can do this by creating an Imports file in the Imports sub folder of Macro Scheduler. Let’s make an import file for some functions in User32.dll:
Step 1. If you don’t already have an Imports subfolder inside the Macro Scheduler program folder, create one: c:\program files\Macro Scheduler12\Imports
Step 2. Create a symbolic link to the appropriate DLL in this folder. Start a CMD prompt and CD to the Imports folder and for User32.dll type the following:
mklink user32.dll c:\windows\system32\user32.dll
If on a 64 bit system replace system32 with syswow64
This will create a link to the DLL in the Imports folder. Next we need to make a corresponding INI file.
Step 3. Create a file called User32.ini in the Imports folder. Inside this file create entries for each function you wish to import. E.g.:
[GetKeyState]
FunctionName=GetKeyState
Parms=1
Parm1=INT[SendMessage]
Parms=4
Parm1=INT
Parm2=INT
Parm3=INT
Parm4=INT[FindWindow]
Parms=2
Parm1=PCHAR
Parm2=PCHAR
Now, instead of writing:
Let>VK_UP=38 LibFunc>user32,GetKeyState,result,VK_UP
You can write:
Let>VK_UP=38 GetKeyState>VK_UP,result
So here’s a project for someone or a group of people: Create a User32.ini file for a fuller list of compatible functions which we can share on the website. Any function that accepts either integers (INT) or strings (PCHAR) and returns an integer (or nothing) can be included. And then we want another one for Kernel32.dll … etc.
Accessing 64 bit System Folders – Turn off File System Redirection
Wednesday, September 15th, 2010If you need to run a 64 bit system command, or a system command that requires access to the 64 bit system folders you may need to turn off File System Redirection.
To turn off File System Redirection call the snappily named Wow64DisableWow64FsRedirection function and remember to turn it back on with the equally memorable function Wow64RevertWow64FsRedirection.
For example:
//turn off File System Redirection LibFunc>kernel32,Wow64DisableWow64FsRedirection,result,0 Let>RP_ADMIN=1 let>RP_WAIT=1 DeleteFile>%TEMP_DIR%\vss.txt Run>"cmd.exe" /c vssadmin list shadowstorage >> "%TEMP_DIR%\vss.txt" ReadFile>%TEMP_DIR%\vss.txt,vss MessageModal>vss //revert File System Redirection LibFunc>kernel32,Wow64RevertWow64FsRedirection,result,0
Recently someone running the 64 bit version of XP was having a problem running this innocuous looking code:
Run>c:\windows\system32\mstsc.exe
mstsc.exe is the remote desktop client. Macro Scheduler returned an error saying that c:\windows\system32\mstsc.exe could not be found, yet using Windows Explorer we could see mstsc.exe clearly in the system32 folder. The same code worked perfectly fine on a Win7 x64 system.
Eventually I realised what was happening. Because the OS was 64 bit and Macro Scheduler is 32 bit, Windows was redirecting “c:\windows\system32\” to “c:\windows\syswow64″ – the 32 bit system folder. There should be a 32 bit version of mstsc.exe in there, but on this particular system it was missing (it may be that earlier versions of Remote Desktop on x64 did not install a 32 bit version). Hence the error that Macro Scheduler could not find the file. We quickly resolved this by turning off File System Redirection using the code above.
Although the current 32 bit version of Macro Scheduler runs on and is compatible with all 64 bit versions of Windows, a 64 bit version of Macro Scheduler is in the pipeline. Until then calling some system level functions may need the above treatment if those commands need to access the 64 bit subsystem. Macro Scheduler can happily execute and interact with 64 bit applications, but Windows will redirect references to some locations such as system32 unless File System Redirection is disabled.
Macro Scheduler on Facebook!
Tuesday, September 14th, 2010If you’re a Facebook fan you can now find Macro Scheduler there too. So head on over and say hello. Here’s the URL:
Associating a File Extension with a Compiled Macro
Wednesday, June 23rd, 2010I have a few scripts which perform actions on files. Rather than have the script ask me what file to use, it is easier to associate the file type with the script so that I can just double click on the file (or right click and choose “Open with”) in Windows Explorer.
For this to work the script must first accept a file on the command line. Here’s a really simple script which reads the content of a file passed into the script with the “thefile” command line parameter:
ReadFile>%thefile%,fdata MessageModal>fdata
If you were to compile this script and then pass thefile on the command line it would read in the file content and display it in a message box:
c:\path\myexe.exe /thefile=c:\somefile.mjt
Now, if we create a file association for .mjt files we would only need to double click on the .mjt file to have it open in the exe.
The easiest way to create a file association for a file that does not already have one is to just double click on the file in Windows Explorer. Then when asked choose to select from a list of installed programs and on the next dialog click on the “Browse” button to locate your executable.
If the file extension is already associated with other applications then right click on the file and choose “Open With” and then “Choose program…”, then UNCHECK “Always use the selected program to open this kind of file” and click on “Browse” to locate your executable.
Initially this won’t quite work. We need to make a small change, as this creates a mapping in the registry which looks like this:
“c:\path\myexe.exe” “%1″
We want to change it to:
“c:\path\myexe.exe” /thefile=”%1″
So after creating the file association via Windows Explorer we need to make a small registry change:
1. Fire up RegEdit.exe (Start/Run and then type regedit.exe)
2. Open HKEY_CLASSES_ROOT
3. Search for your exe name to find the “c:\path\myexe.exe” “%1″ entry
4. Make the change as above, changing the “%1″ to /thefile=”%1″
Now, when you double click the file (or right click/Open with) it will launch your exe, with the filename passed to it in the “thefile” parameter.
You could actually code the script in such a way that you don’t need to do the registry change. You could parse the COMMAND_LINE system variable to get the file from the command line, without requiring a custom parameter name. This is discussed in this forum post which talks about being able to drag and drop a file onto a script.
If you want to create the file association programmatically, take a look at what registry entries are created by Windows when you do it manually. Then you can use the registry functions to achieve the same. E.g. this script associates .why files with the “c:\where\why.exe” executable expecting the file in a parameter called “thefile”:
RegistryWriteKey>HKEY_CLASSES_ROOT,.why,,why_auto_file RegistryWriteKey>HKEY_CLASSES_ROOT,why_auto_file\shell\open\command,,"c:\where\why.exe" /thefile="%1"
Weekly Forum Round-up
Friday, May 21st, 2010I thought I might start a weekly round up of some of the Macro Scheduler forum posts that caught my eye during the week. Not everyone gets a chance to browse the forums all the time, so it might help to link to some here. Then those that subscribe to the blog via RSS/Email will see them and they’ll also show up in Macro Scheduler’s News Feed window.
The forums are quite active but I won’t link to every little discussion or request for support – just those that demonstrate a new feature, or work as a “how to” or anything else that I think could be useful. We’ll see how it goes.
So here’s my list for week ending 21st May 2010:
How to trim spaces from the ends of, or within, a string
A Progress Bar Demo using Macro Scheduler 12
How to make a custom dialog minimize to the task bar
Putting a status bar with multiple panels on a custom dialog
Finding a drive based on its label (volume name)
Getting the HTML source of a page using WebRecorder
Running Automated Testing scripts in the background via VMWare
Sharing and Synchronizing Macros
Thursday, May 20th, 2010A new feature in Macro Scheduler 12 is the ability to easily share macros with other people on your network, or between desktops.
It has long been possible to work outside of the Macro Scheduler interface and indeed many people already do this. You can use the standalone editor and run or edit macro script files (.scp) directly from Windows Explorer. So to share script files you can store them in a network folder which each person in your team can access.
But until now that had some limitations. Firstly you would have to work outside of the Macro Scheduler interface and secondly, until version 12, scripts weren’t opened exclusively. So if two people were working on a script at the same time the last person to save would overwrite the changes made by the first. Until now Macro Scheduler was not built with network sharing in mind. And of course if you wanted to apply a schedule, trigger, or hot key to a shared macro you would need the Macro Scheduler interface. So would need to import it. Therefore any time it was changed you’d have to re-import it again.
Linked Groups and Exclusive Opens
With Macro Scheduler 12 you can now create “Linked” macro groups. Version 12 also makes sure that when you open a script for editing it is opened exclusively. This means the file is locked and no one else can open it until you’re done.
To create a Linked Group, create a new macro group as you would normally, set the path of the group to point to a network share, and check the “Create Linked Group” box. Give it a name and click OK.
Any macros already in the folder will show up immediately. And if you create a new macro in that group (or move a macro to it) other people with a group linked to the same folder will see those macros too.
So Linked Groups are useful where you want to easily share macros between members of your team or between two desktops – e.g. your desktop and your laptop.
You could also share macros between a developer and several users and prevent the user from being able to edit them by using a network share that you can write to but they only have read only access to. The users would be able to run the macros but not edit them or create new ones in that group.
Note that at present to delete a macro from a Linked Group the file needs to be deleted from the folder using Windows Explorer. This is partly to avoid accidental deletes and to prevent people from moving linked macros. We are considering ways of improving on this in future so that linked groups can be administered more easily within Macro Scheduler. It’s early days for Linked Groups and I’m sure as more people start to use them ideas will start flowing in. So if this is something that becomes popular expect improvements over time.
Using an Old Version? Time to Upgrade for Vista/Win7 Support.
Friday, April 23rd, 2010If you’re using an old version of Macro Scheduler, especially version 8 or lower, and like many others, you or your company are considering upgrading your Windows operating system to Vista or Windows 7 soon then you will need to consider upgrading Macro Scheduler too.
Windows 7 adoption rates are outpacing those of Vista fast and many companies are planning on going straight from XP to Windows 7. Already Windows 7 has over 15% market share with over 90 million licenses sold as of March 2nd.
Version 8 of Macro Scheduler was superseded before Windows Vista came along. And Vista brought with it some changes that required us to make changes to Macro Scheduler. So Macro Scheduler v9 was the first version that fully supported Vista. The latest version supports Vista and Windows 7 fully and is listed at Microsoft.com as a “Windows 7 Front Runner” application.
One of the things that Vista introduced were the thumbnail windows that appear when you hover over a task bar icon. These have the same title as the application’s main window. So in Macro Scheduler 8.0 and lower you will run into a problem where your SetFocus lines and other window functions find this thumbnail window before the main window and prevent your scripts from working properly.
Starting with Macro Scheduler 9.0 (in 2007) we made the window functions ignore these new thumbnail windows to prevent this problem. We also had to make some changes to the macro recorder. Older versions may not be able to record under Vista without running Macro Scheduler as admin.
So if you’re still running Macro Scheduler 8 or below then even if you have no plans to change your macros, you’re going to need a newer version when your operating system is upgraded to Windows 7.
Furthermore, we can’t support old versions forever and with the release of version 12 we will be discontinuing support for versions 8 and lower. Since version 9.0 was the first version that properly supported Vista and above we can only really continue to provide support for this version and onwards.
Version 12 offers even more Vista/7 functionality including a reliable AutoLogon mechanism that works in Vista/7/2008 to allow you to schedule macros to run even when Windows is locked or logged out.
So now is the time to upgrade. And if you buy or upgrade to v11 now, we’ll give you a free upgrade to v12 when it is released in a few weeks.
So there’s really no need to wait.
For a summary of new features in v12 click here and here.
The best way to upgrade is to log into your registered account and click the upgrade links. Any problems accessing your account email us.
Consider adding maintenance to your order as well. This will ensure you continue to get all future upgrades and new features automatically at no extra cost. Maintenance is the easiest way to ensure your software stays up to date with all the new Windows releases.
Take a look at the Macro Scheduler history list to see how many improvements there have been since version 8:
http://www.mjtnet.com/mswhatsnew.htm
You are currently browsing the archives for the General category.
Pages
Archives
Categories
- Announcements (189)
- Automation (88)
- General (186)
- Podcasts (5)
- Scripting (116)
- Success Stories (12)
- Testing (10)
- Tutorials (5)
- Uncategorized (18)
- Vista (23)
- Web/Tech (14)
- Windows 7 (6)
- Windows 8 (1)