September 18, 2009

Fun with Chinese Windows

Filed under: General — Marcus Tettmar @ 11:12 am

As you may have noticed, in the last Macro Scheduler update we fixed a problem that prevented compiled macros from running on Chinese Windows. This probably affected other non-Western language versions of Windows too. It took us a while to track down this little bug even though, as is often the case, it turned it to be a simple little thing.

In order to replicate the problem quickly I installed the Chinese Simplified version of Windows XP into a Virtual Machine. That was interesting when I have no knowledge of Chinese whatsoever. Luckily (or unluckily) I’ve installed XP so many times I knew from the location of each option what each one did. Here’s our XP Windows showing the control panel:

Do what?

Do what?

It did give me a great idea for a way to stop my friends and family from mucking up their PCs. Maybe if they don’t understand what the screen says they can’t muck it up …oh wait …

Anyway, with the 490 million Chinese Internet users soon to outnumber the rest of us, I’m glad this little bug has been squashed.

August 28, 2009

Kudos

Filed under: General — Marcus Tettmar @ 4:44 pm

Just received this email and had to share it.  It’s notes like this that make it all seem worth it, especially at the end of a long week. 🙂

To ALL

I’m sorry.  I know I must sound like a broken record.  But……

OMG!!!

You guys are AWESOME!!!

The LEVEL of Tech Support here is insane!! It is through the roof!  The Freak’n roof is on FIRE!!!

The POINTS are OUT the WINDOW!!

How DO you do it?  You have to answer so many e-mails and yet you maintain this unheard of level of
EXELLENCE!!  I KNOW you have to deal with some….well you know.  And yet…..

OMG!!!

Please tell me you can’t help me, just so I know I’m still ALIVE!!

Keep up the GREAT work!
PepsiHog

August 26, 2009

Strange Support Requests

Filed under: General — Marcus Tettmar @ 10:35 am

I never ceased to be amazed at some of the queries we get. This one came in today via Live Chat. Perhaps it was a joke:

Strange Support Chat

Weird.  Now, I did wonder for a minute if the thesis had something to do with the use of Macro Scheduler or automation tools or similar, in which case I might have been able to help somehow, but after asking how the question related to Macro Scheduler the requestor simply said sorry and left.  So it clearly didn’t.

The only way to initiate a live chat request is via our website, which I’m pretty sure doesn’t say anything about offering translation services. Last time I looked (just now) mjtnet.com is pretty obviously all about Macro Scheduler and our other automation tools.

August 11, 2009

Windows 7 Keyboard Shortcuts

Filed under: General,Windows 7 — Marcus Tettmar @ 4:37 pm

Back in January we were able to download the Windows 7 beta and I reported that Macro Scheduler 11 is fully compatible with Windows 7. Yesterday the final RTM (Release to Manufacturing) version was made available to MSDN subscribers and so today I upgraded my Vista desktop to Windows 7.

I am pleased to report that the upgrade went painlessly. The only issue I encountered after the upgrade was lack of audio which was easily rectified with a visit to Creative’s website and a download of the updated driver for my audio device. Needless to say, Macro Scheduler is running smoothly under this shiny new interface.

Most people seem to be saying that Windows 7 is the Vista upgrade that makes Vista what it should have been. Seems pretty slick so far, but I’ll report back after I’ve been using it a while.

In the mean time here’s a full list of keyboard shortcuts in Windows 7 which may come in handy for Macro Scheduler developers.

August 5, 2009

Examples are Examples

Filed under: General — Marcus Tettmar @ 10:20 am

Examples are examples not doctrine. In the topic on the “Release” command in the Macro Scheduler help file it mentions that to exit a program you might do:

Press ALT
Send>fx
Release ALT

This would hold down ALT while sending the f and x keys before releasing the ALT key again. Commonly this invokes the standardised File/Exit menu option.

But this is not always true. Not all apps have these options. Not all aps have a File menu. And as we’ve seen in my last post, not all apps work the way we would expect them to. The above is just an example. It’s not dictating the way all Windows apps work. Not every application is the same or obeys the “rules”.

June 26, 2009

Weddings and Updates

Filed under: Announcements,General — Marcus Tettmar @ 11:03 am

Apologies for the quietness on my blog lately.  This month has been a busy one for me personally as on 13th June I – finally – married my partner of 6 years (and the mother of my children), Angela, and went away for a short, but very relaxing, honeymoon last weekend.

We at MJT have also been busy working on some client projects, so it has been a bit of a manic month all round and I didn’t manage to get a newsletter out for June.   But I plan to put one together for next week.  We should also have a Macro Scheduler maintenance release out soon, and have also started on some new video tutorials.  So watch this space!

June 4, 2009

Calling Macro Scheduler Scripts from VB/VBA

Filed under: General,Scripting — Marcus Tettmar @ 4:10 pm

I’m often asked how you can run Macro Scheduler macros from other programming languages, particularly VB.  

Macro Scheduler scripts can be run from the command line.  See the help file topic “Command Line Options”.  E.g.:

msched.exe “c:\someplace\mymacro.scp”

VB/VBA lets you execute external commands/applications via the Shell function:

Shell “””c:\program files\macro scheduler 11\msched.exe”” “”c:\scripts\example.scp”””, vbNormalFocus

The only problem with the Shell function is that it does not wait until what it is calling has finished running before continuing.  So it fires off the macro and the program continues.  In most cases you’d want to wait for the script to finish before you continue.  To do this you can use the following ShellAndWait function:

    Private Declare Sub Sleep Lib "kernel32" ( _
        ByVal dwMilliseconds As Long)
    Private Declare Function GetExitCodeProcess Lib "kernel32" ( _
        ByVal hProcess As Long, ByVal lpExitCode As Long) As Long
    Private Declare Function timeGetTime Lib "winmm.dll" () As Long
    Private Declare Function OpenProcess Lib "kernel32" ( _
        ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As Long
    Private Const STILL_ACTIVE = &H103
    Private Const PROCESS_QUERY_INFORMATION = &H400
    Private Declare Function CloseHandle Lib "kernel32" ( _
        ByVal hObject As Long) As Long

    Public Function ShellAndWait( _
     ByVal sShell As String, _
            Optional ByVal eWindowStyle As Integer = vbNormalFocus, _
            Optional ByRef sError As String = "", _
            Optional ByVal lTimeOut As Long = 2000000000 _
        ) As Boolean
        Dim hProcess As Long
        Dim lR As Long
        Dim lTimeStart As Long
        Dim bSuccess As Boolean

        On Error GoTo ShellAndWaitError

        ' This is v2 which is somewhat more reliable: 
        hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, False, Shell(sShell, eWindowStyle))
        If (hProcess = 0) Then
            sError = "This program could not determine whether the process started." & _
                 "Please watch the program and check it completes."
            ' Only fail if there is an error - this can happen 
            ' when the program completes too quickly. 
        Else
            bSuccess = True
            lTimeStart = timeGetTime()
            Do
                ' Get the status of the process 
                GetExitCodeProcess(hProcess, lR)
                ' Sleep during wait to ensure the other process gets 
                ' processor slice: 
DoEvents:       Sleep(100)
                If (timeGetTime() - lTimeStart > lTimeOut) Then
                    ' Too long! 
                    sError = "The process has timed out."
                    lR = 0
                    bSuccess = False
                End If
            Loop While lR = STILL_ACTIVE
        End If
        ShellAndWait = bSuccess

        Exit Function

ShellAndWaitError:
        sError = Err.Description
        Exit Function
    End Function

So your code becomes:

ShellAndWait “””c:\program files\macro scheduler 11\msched.exe”” “”c:\scripts\example.scp”””, vbNormalFocus

If you have Macro Scheduler Pro you can compile the script to an EXE and then just execute the exe, making the command line simpler:

ShellAndWait “c:\someplace\mymacro.exe”, vbNormalFocus

The above code is based on the code found here.

June 3, 2009

T-Shirt Winner for May

Filed under: General — Marcus Tettmar @ 11:21 am

This month a fancy MJT Net logo T-Shirt goes to Rain for receiving 10 forum reputation points in May.  Thanks, Rain, for your valuable contributions on the forums and for continuing to help others out.  

Don’t forget that each month I send T-Shirts to the people receiving the most reputation points in the previous month.  So if you’re not already active in the forums, get stuck in – you could win a T-Shirt.

Make it Easier with a Few Basic Windows Skills

Filed under: Automation,General — Marcus Tettmar @ 10:17 am

Some pre-sales questions we get seem to suggest that the user lacks basic Windows skills.  What surprises me is that these questions are often from people working in company IT departments.  Their ability to comprehend how to automate something appears to be diminished by their inability to use a PC effectively.  Perhaps I’m being unfair – I guess it’s easy to forget that there’s another way to do something.

For example.  We might get asked:

“How do I make my macro click on a desktop shortcut if I don’t know where that desktop shortcut is going to be, and I want the macro to work on any PC where the desktop shortcut could be in different places?”.  

Think about it for a second. The answer is that you do NOT click on the desktop shortcut.  Why would you?  The clue is in the name – a shortcut is .. a shortcut to something.  Why would you record or write a macro that clicks on an icon when the macro simply needs to run whatever the shortcut runs?  Right click on the shortcut to show its properties and look at what the shortcut executes.  Copy that into your script and have the Run or ExecuteFile command run it.

As I said in Top Tips for Reliable Macros: Don’t automate mouse clicks or keystrokes just to start an application!

Now, even if you did want to select a desktop shortcut, there’s still another way to do it without needing to know or care where it is.  Just type it.  If you focus the desktop and type the name of a desktop shortcut on the keyboard it will get selected.  This is what I call “drill down” and it works on most lists.  So your macro could just send the text of the item.

When we get asked questions like this I’m always a little surprised.  I would have expected someone in an IT department to know what a desktop shortcut is and also to know that you can control Windows via the keyboard.

Of course, if you really, really want to create a macro that double clicks on a shortcut using the mouse and want it to find its position you can do that with image recognition.  In some applications, like the one I wrote about yesterday, that is the only way to go.  But it’s overkill if you just want to start an application, or run a file.

See also: Keyboard Shortcuts; Top Tips for Reliable Macros

May 19, 2009

Multiple Monitors aid Productivity and Debugging

Filed under: Automation,General,Scripting — Marcus Tettmar @ 3:20 pm

If you’re not using more than one monitor, you are missing out big time.  For one thing, some research by the University of Utah found that using two monitors increases productivity 44%.  There’s a good summary and more comment on this on the coding horror blog.

A huge benefit of multiple monitors for Macro Scheduler developers is that it makes developing and debugging automation macros a lot easier.  When I’m building a script that controls another application I will often put the Macro Scheduler editor on one monitor and the application I’m automating on another.  I can then see both side by side, so I don’t need to switch focus back and forth.  I can run my macro as I’m developing it and see the script at the same time as the results.  If I need to debug I can step through the script and see the progress of the script at the same time as the outcome without the changing of focus effecting it.

Debugging a script that simulates a user and needs to change focus can be a bit of a conundrum, since the act of debugging introduces delays, allowing more time for events to complete, and causes loss of focus.  In Macro Scheduler there’s a “Refocus Windows” setting in the Debugger, but even that isn’t enough in some cases.  Being able to work on the macro and see the target application at the same time without either interfering with each other is therefore the best solution.  

If you don’t have a PC or video adaptor that can support more than one monitor you could use ZoneScreen along with a laptop or second PC to act as your second screen.  A single monitor big enough to let you put the editor and target apps side by side without them overlapping would work too.

If you’re stuck with a small monitor and simply can’t have both editor and target application visible at the same time – you may be at a client’s site or working on a notebook – and need to debug code that needs to see the screen, don’t forget you can also set and run to breakpoints.  With a breakpoint you can step through the code and at any time run to the next breakpoint, allowing the macro to whizz through the code to that point without switching focus back to the editor between each step.  So for crucial sections of code which need to, say, capture a screen or scrape some text, it can be very useful.  Once the script reaches the breakpoint you will be returned to the editor where you can continue stepping line by line, or run to the next breakpoint or end.

In my opinion multiple monitors are an absolute must.  But there are limits!

« Newer PostsOlder Posts »