Jump to content
Macro Express Forums

Specify Which Computer To Execute Macro On


Recommended Posts

I use two computers: A and B

One keyboard and mouse, by way of MouseWithoutBorders.  Wonderfully controls both computers.

If through Windows Task Scheduler I have a macro to execute on Computer A, but I am currently over working on Computer B, the macro seems to operate on Computer B, and not A as desired.

Is there a way to confine the macro to Computer A, and not switch over to Computer B, even though I am working on Computer B, through MouseWithoutBorders?  In other words, STAY ON COMPUTER A!!! 

Any thoughts appreciated.

Nicholas Kormanik

 

Link to post
Share on other sites

No good ideas. All I can think of is to somehow suspend your MouseWithoutBorders software while the macro runs. But I don't know if that's possible. 

Link to post
Share on other sites

Macro Express simulates keystrokes and mouse movement, so it sort of makes sense it would follow to wherever WebWithoutBorders is directing the keyboard/mouse.

But what about a macro that just does file actions, no keyboard or mouse at all?  Does that still follow the mouse?  Is ME installed on all the computers? 

Link to post
Share on other sites

When I was more active, the majority of my macros didn't use keyboard or mouse. But then I got into programming in .NET where these things are faster, simpler and reliable. I changed my mind and now I agree with you. In most cases if a macro doesn't use a keyboard or mouse, it's better to use scripts or write programs. MEP only shines for automating mouse and keyboard actions and working with the user in short macros. Almost everything else is better to do with a program, even web automation. MEP is for macros, not a programming application.

Link to post
Share on other sites
  • 3 weeks later...

I run the same macros on computers with different screen sizes. I set a registry key with information for a particular screen  or with a computer name.  I then have Macro Express read the registry key into a variable and then I can control which parts or which macros will run on each machine.

Link to post
Share on other sites

Unfortunately, I don't have any simple macros showing this.  In the attached files, the Aspirin_Yes macro would be one I would run. The first thing it does is run the Aprima Variables macro. That macro checks my registry for the screen resolution key I placed in the registry and runs the appropriate macro for that PC screen resolution. That macro then sets the location of various buttons, tabs, etc in my EMR (unfortunately this EMR is not totally windows compliant so I have to do a lot of mouse clicks). Once that macro runs, the Aspirin_Yes macro resumes.

3240x2160.mex

Aprima Variables.mex

Aspirin_Yes.mex

Link to post
Share on other sites
  • 2 weeks later...

Which language to go to would depend on the application. I recommend looking at code samples on line for the environment and type of things you are trying to do and see how many appear in what language. After much consideration I elected to go with VB.NET. I wanted to run on Windows and interact with Office applications so this made sense. The hoi polloi are all about C#, that's the cool language of the .NET,  but I found the syntax ugly and confusing. The whole use of semicolons is a mess to my eye. VB is syntactically more line English. And all .NAT languages a JiT compiled. That is they are compiled Just in Time so as to take advantages of changes and fixes in the underlying .NET framework without having to recompile your code. So both VB.NET and C# both compile into the Microsoft Intermediate Language so there's no performance benefit or anything like that. It's like writing a repair manual in English and French. The mechanic takes the same steps to rebuild the engine. 

Many people think of VB as this old clunky language. And it is. VB.NET however is not VB. VB ended at version 6. VB.NET is a new language that is a proper OOPL. It just uses much of the same syntax. But I was planning on writing many VBA for Excel also and I liked the idea that learning VB.NET would have similarities to VBA. As it turned out, I discovered the Office Interop libraries which allow one to write programs in .NET that control Office applications so I never needed to learn VBA.

Then there's VBScript. Learning VB.NET helped me with that but here again I ended up opting to use .NET because once you learn that, one can write programs instead of scripts. And VB.NET is much more powerful and faster. 

So my concept about crossing over for VBA and VBScript was flawed but it has come in handy a few times when working on other people's VBA or VBScript. 

The main negative I've found is that C# is more popular and when looking for help, samples, and so forth, one will find most examples are in C#. But there are online tools to convert C# to VB.NET. And once I started reading some C# I found I could half follow it and usually enough to get what I need. It's like learning Latin and going to Spain or Italy. Since the foundation is the same, it's possible to understand, at least in a vague sense. 

Link to post
Share on other sites

Really good explanation, Cory.  Greatly appreciate that.

So, one follow-up question I have is:  Can VB.NET do most of what Macro Express Pro can do?  In other words, if I start learning VB.NET will I decide to simply do things in VB.NET, as opposed to creating a new MEP macro to attempt to do it?

Where does one draw the line?  Use MEP to do it.  Use VB.NET to do it?

Or some other.....

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...