New Purchase Page

We’ve just updated our purchase page to use the latest purchasing facilities offered by our partner Fastspring. This means a faster, easier checkout process and more importantly for users of Microsoft Edge, no longer any need to enable cookies to complete your purchase. We’ve tested the checkout process as thoroughly as we can but if you encounter any difficulties please report them to us!

Wait until button is enabled: PTFB Pro v5.4.3.0

Sometimes when automating a task you need to wait for a variable amount of time before the next step becomes available. One such case occurs in my favorite image editing software Affinity Photo.

Let’s say you start a new “focus merge” – this is where multiple photographs are blended to create a single image with a deep region of sharp detail. The following screen pops up allowing you to specify (“Add”) the images that are to be blended:

Focus merge in Affinity Phot

When you’ve done that, the software goes into high gear as it scans the source photos, and it doesn’t enabled the OK button – which must be pressed to start the actual merge – until it is ready. That could take anything from a few seconds to a few minutes, and I’d like PTFB to monitor and press the OK button the instant it becomes available. That is now possible without any workarounds thanks to this new addition to the “Identifying the Target” page:

The new Must Be Ebaled option for buttons

The “Must be enabled” option is new in version 5.4.3 and is only available for “Single Press” macros where the target of the press is a regular button or an easily recognizable link in a web page. It’s something that has been requested by a few users over the years, but I didn’t appreciate how useful it would be until I ran into a situation where I needed it. It can really help cut down on wasted time and irritation when you’re doing lots of repetitive work!

Get the latest version from our downloads page and remember it’s a free upgrade for all licensed users of version 5.

New: Improved Multi-Monitor Support in PTFBPro v5.4.0.0

If you use multiple monitors you’ll be glad to hear that PTFBPro now has the ability to move a target window to the monitor on which the mouse currently resides. This new functionality comes in version 5.4; you’ll find it on the “Actions” page when editing your Window Restore macros as shown below:

Multi-monitor functionality in Window Restore macros
As you can see it extends the existing actions and provides the ability to position the window relative to the current location of the mouse. As the new functionality is part of Window Restore macros you can easily:

  • set an appropriate delay on the Triggers page for autonomous triggering, OR
  • turn off autonomous triggering and use a “Run Item” action in a Window or screen-based macro as the trigger, OR
  • chain the window restore macro using the Run Script/Program notification action of any other macro

Note that this new functionality is entirely optional; you can still move a window to a specific point on any monitor by using “Restore Position” with appropriate coordinates.

Additionally note that the “Center” action will now center a window on the monitor which is its closest container (previously centering always occurred on the main monitor, regardles of which monitor was currently holding all or most of the window).

These changes were inspired by a feature request from a long-time PTFB user; if you have any suggestions please feel free to submit a ticket to the HelpDesk, or just use the “Email Support” option off the Options menu in PTFB itself.

Head over to our downloads page to get the latest installer for PTFBPro now!

How to run a macro whenever a window becomes active

Recently I was asked if there’s a way to get PTFB Pro to run a macro (or a single press item) whenever the target window becomes active. This can indeed be done using a little oft-ignored setting on the “Identifying the Target” page of the macro’s properties:

Fire only if foreground

The key is to tick the “Fire only if foreground window” option; with this set, the macro will only run automatically if the target window is active, ie. the foreground window. Whenever the window becomes inactive (because you’re working in another window) it will fall off PTFB’s radar, but when the window becomes active again PTFB will see it and launch the macro according to the other settings you’ve made on the “Triggers” page.

In the above example you can see I’m using this technique with a Window Restore macro for the Opera browser; I have it set to correctly maximize Opera whenever it becomes the foreground app. There are a few other things to note about this example. Firstly, like other browsers Opera changes its window title according to the web page currently being viewed; to make my macro match Opera regardless of the page I’m viewing, I’ve set it to match any window whose title ends with ” – Opera”. I’ve also specified that only windows that are owned by the Opera process (“opera .exe”) are to be considered a match – this latter setting makes it easier and faster for PTFB Pro to identify genuine Opera windows.

PTFB Pro and Remote Desktop – a new release

Further to the previous post on using PTFB Pro on a machine that is primarily accessed through Remote Desktop, a new version of PTFB Pro is now available (v5.2.3.0). This version has an updated Help file, and ships with a ready-made batch (.bat) file designed to be used whenever you wish to close the remote desktop session window.

The batch file contains an upgraded version of the TSCON command featured in the last blog post, like this:

for /f “skip=1 tokens=3” %%s in (‘query user %USERNAME%’) do (
%windir%\System32\tscon.exe %%s /dest:console )

Rather than assuming a fixed ID for the session, this small snippet of code gets the correct ID and uses this in the TSCON command.

The new installer for PTFB Pro has an option to place a shortcut to the batch file on your desktop, for convenience. What’s more, the shortcut is marked as requiring Administrator privileges, so there’s no need to remember to use “Run as Administrator” when you launch it.

Serious thought was also given to including the registry hack that keeps the Remote Desktop session responsive when the window is minimized, i.e. this one:

  1. On your local computer, close all open Remote Desktop sessions.
  2. Launch the Registry editor (regedit.exe).
  3. Navigate to the following Registry key:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
  4. Create a DWORD value named RemoteDesktop_SuppressWhenMinimized and set it to 2.
  5. Close the Registry Editor.

Ultimately the decision was taken not to include this, as it may not be appropriate in all cases (for example, this registry modification is know to cause issues with some other 3rd party software), so don’t forget to apply this mod yourself if you need it.

Using PTFB in conjunction with Remote Desktop

Lately I’ve dealt with a number of support requests involving the use of PTFB on servers, where the user typically connects to the server via remote desktop. While the remote desktop window is open and on-screen, everything works fine; if the remote desktop window is minimized or closed, PTFB seemingly stops dealing with target windows automatically.

In reality, what’s happening here is that when the remote desktop window is minimize or closed, the remote Windows machine becomes unresponsive to all PTFB’s attempts to press buttons and keys. PTFB still tries to carry out its appointed tasks, but  its efforts are ignored by the remote OS. Happily, there are ways round this.

On XP or a more recent OS with UAC Disabled

If against all security advice you’re still using Windows XP(!), OR you’re running a more recent OS with User Account Control (UAC) disabled, there’s a setting in PTFB that should help:

1) Click the Options button and choose “Configure…” from the popup menu
2) On the Settings tab (first tab of the Configure screen) look for the section labelled “Locked Workstation / Remote Desktop”
3) Within that section, tick the option marked “Disconnect Remote Desktop Session to press targets” and close the config screen

When this option is set and PTFB Pro is about to take action via a single press or macro, PTFB checks to see if a remote desktop session is open but inactive (i.e. RDP is blocking simulated actions because the window is closed or minimized). If the session is inactive, it uses the tscon command to formally disconnect the session, removing the blockage. The beauty of this setting is that no action will be taken unless it’s really necessary, i.e. the session will not be disconnected unless it has entered the inactive state and a target must be handled.

More recent Windows OS with UAC enabled, when minimizing a remote session

If you typically minimize your remote desktop session windows rather than closing them, there’s little registry edit that will eliminate the problem. Warning: take great care when editing the registry, otherwise you could leave your operating system in an unusable state.

On your local computer, close all open Remote Desktop sessions.

  1. Launch the Registry editor (regedit.exe).
  2. Navigate to the following Registry key:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
  3. Create a DWORD value named RemoteDesktop_SuppressWhenMinimized and set it to 2.
  4. Close the Registry Editor.

The above edit should kick in when you next minimize an RDP session window, and allow PTFB to keep doing its thing.

Other cases

So let’s say you’re running a recent OS like Windows 7/8/10 or Svr 2008 or later, you have UAC enabled, and you typically close your remote session windows when you’re done with them. In this case, you need to use the TSCON command kick the remote machine back to an interactive state so that PTFB can operate. PTFB cannot do this for you, because the TSCON command requires admin privileges and by default PTFB does not run in an elevated / privileged state.

As a workaround, you can create a small .bat file on the remote PC that includes the following command line:

tscon 1 /dest:console

Now create a shortcut to the .bat file and in the Compatibility page of the shortcut’s properties set the option labelled “Run this program as an administrator”. Remember to use the shortcut to exit the remote session from within the remote desktop window whenever you want PTFB Pro to be able to continue handling targets; do this instead of closing the window as normal. Note however that Windows will ask you for permission for this each time your little .bat file runs.

App-Specific Switching in Windows

I was recently asked if there was any way to switch to a specific app in Windows using a short key sequence. The person in question was well aware of the ALT-TAB feature in Windows, but didn’t want to have to step through the list of running programs; he just wanted a short key sequence that would take him directly to the desired program without even having to look at the screen. As it turns out, this is easy to accomplish with a bit of help from PTFB Pro:

  1. Make sure the app you want to target is currently running
  2. Create an empty screen macro; just choose “Screen Macro” from the New Macro button on PTFB’s main, then immediately tap the Pause/Break key on your keyboard to stop recording.
  3. Double-click on your new macro to open it for editing, and give it a suitable name. On the Triggers page, turn OFF the “Trigger spontaneously” option and tick the hotkey trigger option, choosing a memorable hotkey that doesn’t interfere with anything else, e.g. for my favorite text editor I might use CTRL+SHIFT+T.
  4. Finally, on the Editing page add a new “Switch to prog” item (it’s at the bottom of the Misc section on the left) and choose your target app from the drop-down list. Now save all your changes by pressing “OK” in the Switch To dialog and in the macro properties dialog below it.

That’s all there is to it. From now on, whenever your target app is running your can summon it to the front instantly by using your chosen hotkey.

 

Better macro sorting and visual trigger delays in PTFB Pro 5.2.0.0

The latest release of PTFB Pro brings two user-requested enhancements: more control over sorting of macros, and an optional delay for visual triggers. The new sorting options can be accessed from the list context menu; just right-click anywhere in the list on PTFB’s main screen and choose “Sort Options…”


Choose “Sort Options…” from the list context menu


And this is the resulting sorting options screen

As you can see you can now sort by up to three different fields in ascending or descending order. The settings in the example above will always show enabled macros first, and they’ll be sorted by name and type. The choice of sort fields is quite extensive – it includes things like macro type, name, enabled state, creation and last usage date/time – but if there’s something you’d like to see added to it please just let us know. As in previous versions you can have these sort options applied automatically or manually via the “Sort Targets” command.

The other much-requested change in v5.2 is the addition of an optional delay for visual triggers. This functions exactly like the “Initial Delay” used on the main macro “Triggers” page, and you’ll find it at the bottom of the Visual Change Settings screen:

The delay goes to a granularity of tenths of a second. If you leave it set to the default of zero, then it has no effect; PTFB triggers the macro the instant it detects a visual change meeting the requirements you’ve specified. However, if you set a non-zero delay then PTFB won’t take action immediately; instead it will wait for the specified time, all the while checking that the trigger conditions are still being met.

For example, let’s say you want macro to fire if a red warning indicator appears in the window of a target app. If you set up the visual trigger with a zero delay, the macro will fire almost as soon as the red warning indicator appears. On the other hand, if a 5 second delay is specified then the red warning indicator can flicker on and off briefly without triggering the macro; the macro will only fire if the warning indicator remains “on” for the full 5 seconds.

Finally, I’d just like to mention an error in the Help file that ships with PTFB Pro. In the section on sending notification emails it states that the recommended port for SMTP for GMail is 465. This was correct back in the days when PTFB could only use either unencrypted smtp or basic SSL encryption. Now of course PTFB Pro can use TLS, and it will choose this newer and generally superior option unless you explicitly tell it to do otherwise. All that would be fine, except that the GMail port for SMTP using TLS is different – it’s 587 not 465. The Help doc will be updated for the next release, but for now if you want to send notifications through GMail, remember that it’s port 587 you’ll need to use, not 465. If all that sounds like gobbledygook don’t worry – it only applies if you want to hookup email notifications through GMail.

How to play an alert sound when a window appears (or changes state)

Recently a couple of people asked me how to set up PTFB Pro to play a sound when a certain window pops up. This is actually a really easy thing to do – just follow these basic steps:

1. Open up PTFB Pro’s main window and choose to create a “New Window Macro” for the target window

 

 

 

 

2. Stop recording immediately to produce an empty – or virtually empty – macro (tapping the Pause/Break key on your keyboard is the quickest way to do this)

3. Double-click your new macro to open it up for editing, and switch to the “Notifications” page. The bottom section causes a sound to play when the macro runs automatically. You can pick one of the predefined Windows sounds, or supply the path to a “.wav” file of your own choosing.

 

 

 

 

 

 

And that’s all there is to it. If needed you can further refine your macro so that it only fires when the window enters a particular state, e.g. when the title changes to a certain pattern (configure this in the “Identifying the Target” page), or when part of the window conetnts changes visually (use the new “Visual Change” option on the “Triggers” page for this).

 

Upgrade to PTFB Pro 5.1.1.0 for Windows 10 Creators Update!

There’s what appears to be an intermittent timer bug in Windows 10 Creators Update which causes PTFB Pro to consume huge amounts of cpu. It doesn’t happen every time PTFB starts; in our tests, the problem seems to strike 2-3 times in every 5 launches, but once it starts it keeps going for the whole session, basically consuming 100% cpu (or 100% of one cpu core if your processor is multi-cored). Previous versions of Windows 10 (as well as all versions prior to windows 10) are NOT affected.

Happily there’s no need to wait for Microsoft to fix this one, which is just as well, given that they took around a year to fix the intermittent crash when searching RegEdit (remember that one?). All you have to do is grab the latest installer from our download page (PTFB is at version 5.1.1.0 at the time of writing) and use it to update your existing installation.

If you’re still on version 4 of PTFB and are about to move to Windows 10 Creators Update, it’s extremely likely that you too will be hit by the same bug. If you want to upgrade to the latest version of PTFB Pro you’ll require a new license; depending on when you bought your existing copy, you’ll either be able to get this free or at a 50% discount – just drop us an email at support@ptfbpro.com and we’ll help you out.