June 25, 2012

Sorting a String

Filed under: Scripting — Marcus Tettmar @ 1:22 pm

In the forums this morning PepsiHog asked for some code to sort a string of numbers.

We have a built-in method for sorting arrays. But here we want to sort a string of characters. E.g. we want the string “4731” to end up as “1347”.

I ended up writing a reusable subroutine which will sort any length string alphanumerically. I thought I’d post it here as it demonstrates a few useful ideas:

//CharSort, parm1: the string to sort, parm2: name of variable to return
SRT>CharSort
  Let>LOCALVARS=1
  Let>tmp=
  RegEx>.,CharSort_Var_1,0,matches,nm,0
  ArraySort>matches
  Let>x=0
  Repeat>x
    Let>x=x+1
    Let>this_char=matches_%x%
    Let>tmp=%tmp%%this_char%
  Until>x=nm
  Let>LOCALVARS=0
  Let>%CharSort_Var_2%=tmp
END>CharSort

To use the subroutine do something like:

Let>MyString=317536492750930
GoSub>CharSort,MyString,{"MyString"}
MessageModal>MyString

This demonstrates a number of things:

– How we can call a subroutine with parameters, and how we can use one of those parameters to set a “result” variable (note the second parameter is set to a string value, and the subroutine sets a variable with this name to the result).

– How we use LOCALVARS to ensure the subroutine has local scope (except when we need to set the return variable). This is important for functions we might re-use elsewhere and drop into other scripts, as we would want to avoid the subroutine modifying any existing script variables. By using local scope we make sure the variables used in the subroutine are local only to that subroutine.

The subroutine works first by splitting the string into an array of characters. It does this by using a Regular Expression which identifies all characters (“.”). RegEx returns an array of matches, which will therefore be all the characters in the string (because “.” means match any character). We can then sort this array using ArraySort and then finally loop through the array and concatenate each item back into a string.

June 21, 2012

Why does my macro stop working when Windows is locked/logged out?

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

Despite our FAQs we get asked a version of the following question at least once a week:

“I just wrote my first macro with Macro Scheduler and it works great but if I lock Windows it stops working, is this a limitation of the trial version”.

My most recent answer to this was as follows:

No, it’s a limitation of how Windows works. I assume that your script needs to simulate a user (i.e. send keystrokes and/or mouse events and needs to “see” windows).

When Windows is locked or logged out *windows cease to exist* and *there is no input console*. Ergo you cannot simulate a user when Windows is locked or logged out. There is nothing anyone can do about this as that is simply the way Windows works.

A more detailed and technical explanation of this can be found here:

http://www.mjtnet.com/msfaq171.htm
http://www.mjtnet.com/msfaq17.htm

Think about it for a second – can YOU use Windows when it is locked or logged out? Of course not. But most people don’t realise that when you lock or log out of Windows the user’s “window station” literally no longer exists, and applications no longer have UIs. While a process may exist, it has no windows and UI objects simply aren’t there. So there’s nothing to interact with. Furthermore the only thing that has keyboard/mouse focus is the security console. So you cannot send mouse/keyboard events.

So in short you cannot automate user interfaces when Windows is locked or logged out.

Command line tasks, and tasks that do not need to access a user interface (interact with windows) may still be possible assuming they do not require logged on credentials.

The only solutions are:

1. Leave Windows logged in
2. If you are running Vista/Windows7/2008 Server you can use Macro Scheduler’s AutoLogon system. See under Macro Properties. This will log Windows back in on schedule, run the macro, and then log out again.

June 13, 2012

Calling All Freelance Macro Scheduler Developers

Filed under: General — Marcus Tettmar @ 1:29 pm

We have a growing list of freelance script developers which we draw from whenever we receive a request for local assistance. If you are a freelance script developer and would like to be considered for potential projects please drop me a line with your details and a summary of your experience so that we can add you to the list.

May 18, 2012

How to do an HTTPS Request Without Installing all of OpenSSL

Filed under: Automation, Scripting — Marcus Tettmar @ 9:52 am

I recently wrote a small macro for a customer which does an HTTPRequest via SSL. This requires that OpenSSL is installed. But the customer wanted to know if there was any way of distributing the macro to his users without having to install OpenSSL on all their PCs.

Thanks to our wonderful forums one of our users has already figured out how to do this and it turns out only 2 DLLs are required and can be placed in either the Macro Scheduler program folder, or, in the case of a compiled macro, the exe’s folder.

Adroege says:

I use this solution:

Download the “binaries” from this page as a zip file
http://gnuwin32.sourceforge.net/packages/openssl.htm

Unzip the contents

find the files libeay32.dll (version 0.9.8.8) and libssl32.dll
(version 0.9.8.8) in the Bin folder

Make a copy of libssl32.dll and call it “ssleay32.dll”

Now just deliver all 3 DLL files in the same folder as the
compiled Macro Scheduler EXE
(libeay32.dll libssl32.dll ssleay32.dll)

Using this method, I didn’t have to do any special SSL “install”,
run regsvr32.exe, or do any registry hacks. It just works.

And rullbandspelare responds:

It appears to work with just putting
ssleay32.dll and libeay32.dll in the same folder.

Even I learn stuff from our forums, or at least find answers more quickly. A great resource. Thanks guys.

May 15, 2012

April 20, 2012

April 18, 2012

March 27, 2012

Sending Keys to Invisible or Unfocused Windows

Filed under: Automation, Scripting — Marcus Tettmar @ 2:32 pm

Can you send keystrokes to invisible or unfocused windows? The answer is yes, if the control you want to send the keystrokes into is a “windowed control”. That is, one that has a handle.

If that’s too technical just try using the “Send Keys to Object Wizard” in Macro Scheduler 13 which generates code that uses the ObjectSendKeys function. Or Watch the video to see it in action.

If the wizard is able to identify the control the code that it generates will work even if the window is not visible or not focused. This is because it works by sending the keyboard codes directly to the specified control.

In contrast the regular Send command sends characters into the global input buffer. In other words it sends keystrokes into whatever happens to have the focus at the time. The great thing about this is that it means it can send keystrokes to ANY thing regardless of whether it is a windowed control or not and regardless of the technology. But the control does need to be focused.

So if your control has a handle then you can use ObjectSendKeys to send keystrokes to it and avoid it having to be focused. This also means it will work even if the window is minimized, or hidden. This could be turned to your advantage if you wanted to manipulate a window and be able to do something else at the same time. Of course this assumes that all the controls have a handle which is not always the case.

As an example, run this script. Notepad will open, then be minimized and then text will be sent into it. When the script has finished restore Notepad and you should see the text inside it.

Run>Notepad.exe
WaitWindowOpen>Untitled - Notepad
WindowAction>2,Untitled - Notepad

GetWindowHandle>Untitled - Notepad,hWndParent
FindObject>hWndParent,Edit,,1,hWnd,X1,Y1,X2,Y2,result
ObjectSendKeys>hWnd,{"Hello World"}

March 12, 2012

And The Winner Is …

Filed under: Announcements — Marcus Tettmar @ 2:07 pm

Many thanks to everyone who submitted and/or voted on an entry to our Kindle Fire contest.

We had so many great entries that it was so hard to choose and the decision was hotly debated between all the judges lobbying for their favourites. But we ended up going with Lorence Sing’s “Because everything matters” story which everyone loved.

For the past 13 years, the Laboratory at Nationwide Children’s Hospital in Columbus, Ohio, has benefited enormously from a small piece of software found on the internet, software that has saved staff time, assured patient and management reports have run at the right time, on time, every time.

In 1997, the laboratory changed to a new Laboratory Information Ssystem, a new more modern LIS. For 10 years prior, we ran a system that required 24×7 computer operators to run jobs, print specimen labels, patient reports, microbiology and virology reports, blood bank reports. Our new system would eliminate the need for most of that, with many of the reports able to be scheduled and run unattended. Several reports, though, specifically reports microbiology reports concerning infectious disease, nosocomial reports, and basic epidemiological reports all had to be run manually, as did all of the blood bank reports.

These reports are incredibly important to the health and welfare of Children’s Hospital’s patients and doctors and need to be run on time, every time.

To enable proper execution of theses critical reports, I searched online for a product that would let me schedule tasks. I was NOT impressed with the Windows Task scheduler. I found Macro Scheduler at www.mjtnet.com. I’m not sure where, possibly through download.com, but I knew when I read about its many features that I had to try it. The free download showed me immediately that this was the product I’d been looking for. Since that first very inexpensive purchase we have painlessly upgraded several time, migrated to new hardware without incident, helped to save lab tech frustration, countless hours of system analyst time, and most importantly, innumerable lives. Every day, the epidemiology report that Macro scheduler initiates may potentially save a child’s life.

In the many years that we have used MJT Net’s Macro Scheduler, we’ve expanded its use, executing reports, renaming files, backing up data, zipping log files, restarting system interfaces, manipulating printers via their internal web server, even created a stand alone password reset application for the hospital’s help desk to utilize. My next major project with Macro Scheduler will involve its graphics recognition capabilities to automate a tedious weekly interface wiretap reset.

At the end of nearly every user satisfaction survey I’ve ever taken, there is one common question – “Would you recommend this product to a friend?” Marcus hasn’t asked me this question, but I can say without hesitation “Yes!” Not only would I recommend Macro Scheduler to a friend, but I have, many times. I frequently give presentations to the Sunquest Users Group (SUGInc.org) and Macro Scheduler is the basis for one of my presentations, “The Unschedulables” (http://lorencesing.com/SUG-XI,The_Unschedulables.zip).

In conclusion, Macro Scheduler from http://www.mjtnet.com/ hasn’t just been a useful tool, it has been a lifesaver. Our Hospital’s slogan is “When your child needs a Hospital, everything matters.” Macro Scheduler is one of the small details that help us make that true.

Lorence sing, MT(ASCP)
LIS System Analyst
ChildLab Database Analyst
Nationwide Children’s Hospital, Columbus, Ohio
http://www.nationwidechildrens.org/

Congratulations Lorence, your Kindle Fire is on its way.

Thanks to everyone for the great entries.

March 7, 2012

Macro Scheduler and 64 Bit Windows

Filed under: General — Marcus Tettmar @ 12:10 pm

Every now and then someone asks whether Macro Scheduler works on 64 bit Windows and if there are any implications. Another question that comes up very occasionally is “Why no 64 bit build of Macro Scheduler?”

Well, first of all, yes, Macro Scheduler runs on 64 bit versions of Windows and it can control and automate 64 bit applications. There are very few implications to be aware of and the vast majority of people will never need to worry about them.

What are these implications?

1. File System Redirection for Processes living in the System Folder

As Macro Scheduler is a 32 bit application if you try to execute a process that resides in the System32 folder by specifying System32 in the path Windows will force Macro Scheduler to look in the 32 bit subsystem folder instead. This is Windows\SysWow64.

Sound confusing? Blame Microsoft. The System32 folder has remained System32 even on 64 bit versions, and the 32 bit versions of system processes/DLLs are in Windows\SysWow64. Since a 32 bit process cannot load a 64 bit DLL Microsoft uses something they call “File System Redirection” to redirect 32 bit apps to look in Windows\SysWow64 to prevent errors when loading system DLLs.

The only time this might affect you is if you specifically want to execute a .exe or load a file which lives in System32 and there is no 32 bit equivalent and/or you really do want to run the 64 bit version. This is rare for the large majority of users. But some of you system administrators may very occasionally want to do this.

The solution is simple. With Macro Scheduler 13 simply refer to the file using the SYS_NATIVE variable which returns an alias to the *native* system folder which will not get redirected (rather than the SYS_DIR variable which will return the system32 folder name which will be redirected to SysWow64). Specifying the literal C:\Windows\System32 path will also be redirected and is not sensible anyway, as these folder names aren’t necessarily fixed (and may not be on drive C) – use the variables. SYS_NATIVE is simplest and is also portable since it will work on 32 bit windows.

Another way to do it is to disable file system redirection which can be done with the Wow64DisableRedirection command. But, very important, remember to renable it with Wow64EnableRedirection. A safer way is to set the RP_WIN64PROCESS variable to 1 before your RunProgram call. This will disable redirection for only all subsequent RunProgram calls rather than the entire process.

Personally I’d go with SYS_NATIVE.

Remember, we’re only talking about the need to run files which live in System32. You need not do anything special for other 64 bit processes. It is simply that Windows will divert you away from System32.

File System Redirection is explained in more detail here.

2. The 64 Bit Registry Hive

In a similar way, calls by 32 bit processes to some parts of the registry may be redirected. This is explained here. If you specifically want to access the 64 bit version of a registry key you need to set REG_64 to 1 before a call to one of the Registry functions.

That really is it. Both situations are rare for the vast majority of users who are automating end-user applications. Only a small minority using the software for really low level system administration tasks may need to be aware of these things.

Wouldn’t a 64 bit version of Macro Scheduler solve this?

This is another way of asking “Why isn’t there a 64 bit version of Macro Scheduler?”. Well, while a 64 bit version would solve these two rare cases, it would also, by extension, turn the two cases the other way around and create another problem. While it would automatically see the 64 bit System folder, you’d have to set a flag or use another variable to make it go to the 32 bit subsystem if you needed to. Same again for the registry.

So you see there is no gain. No difference. It just turns things around. There are more inconveniences with a 64 bit version.

The vast majority of applications out there are still 32 bit. The vast majority of things our customers are automating are 32 bit. Macro Scheduler can control and interact with both 32 and 64 bit applications interchangeably. It is very rare that anyone would ONLY be interacting with 64 bit processes. More often than not if you are needing to control a 64 bit app it is probably when you also need to control a 32 bit one. So support for both, at the same time, is more important.

Our text capture libraries rely on system level hooks which hook various text out calls. Therefore they need to have separate hooks for 64 bit apps and 32 bit apps. Previous versions of Macro Scheduler only had a 32 bit hook. This meant we could only get text from 32 bit processes. With the new version we included a 32 bit hook and a 64 bit hook with a 64 bit proxy allowing the 32 bit hook to get text from 64 bit applications.

Now, if we made a 64 bit version of Macro Scheduler you could get text from 64 bit processes, but if you also wanted text from 32 bit processes you’d need things the other way around (again, no gain or difference). Or we could have offered two versions of Macro Scheduler which could ONLY get text from apps of the same bitness. Since most people need to control both or need to control 32 bit apps running on 64 bit windows and may need to get text from the system as well as the 32 bit app, that wouldn’t help them.

So rather than offer two versions which would be limited or would still need to do special things in certain circumstances, right now it seems safer and simpler to continue to offer the 32 bit version, with the 64 bit text capture proxy, which can automate and control both types of processes. It is much better for us to provide and support one build which works in all situations.

And whichever way we go there is no getting round the redirection issues one way or another. This is not unique to Macro Scheduler: whatever programming language you use you need to explicitly tell it if you want to avoid the redirection issues (whichever the direction).

So hopefully you can see that there’s no real benefit in offering two different versions.

The Future

We’re always monitoring the way things are going. One day the situation might be reversed and the majority of applications may become 64 bit.

We can already create 64 bit builds. If we perceive a NEED we’ll publish it.

In the mean time if you think you NEED a 64 bit only version, drop me a line and explain why and we can get you a custom build, if you do really, really need it.

« Newer Posts — Older Posts »