Yehnfikm8Gq

Text Type is a Text command. Paste could be handling anything although for most purposes would be alphanumeric. Unless someone can offer opinion to the contrary, Paste is emptying the clipboard in one blob and does not count as a Text command. It makes no attempt to provide output until it has finished processing the data. When I have URLs typed in a browser, they are quite long and type in spurts at relatively slow speed. I usually use Wait for Text Playback and add a short delay at the end. Way back, I think I tried to Paste but found that typing the text was more reliable with the Wait for.. command. Text Type is not great with large quantities of text. I've never had to bother modifying keystroke speeds. Whatever the default is, that's it. As with much of ME application, it's finding what works best for your setup. If I have problems with commands, the first thing I usually do is add a delay after and see if it works. Even the shortest delay can make quite a difference. The extra command seems to get things in order, out of proportion to its apparent significance. If I want to modify a variable between Copy and Paste I always use a Variable. I've never thought of doing it any other way. Is there? I may choose to Text Type if the end application prefers that per browser mentioned above. As an aside from an earlier thread on copying filenames from Explorer to the Clipboard, the Clipboard does its best to handle a wide variety of data but what comes out is not necessarily what you think. Text should be fine. Even that may need to be processed from (say) formatted Word to unformatted text.

There is definitely an ME Pro issue in here. I'll report it as a bug. I've managed to get the full loop of 20 commands working. Immediately after the Variable Set String, Prompt for Filename, I copied T1 to T11 and used T11 throughout the macro. Having spent many (valuable) hours sorting out Variable problems and seeing the same things in other users (eg Rustywinger today), I have to question the whole issue of variables. There seems to be something fundamentally wrong in the way they are working in ME Pro. That manifests in several areas: The actual setting dialogs where the "Undefined variable or variable of the wrong type" appears when you are sure you entered a variable the same way you did for the last month. Use of variables like my problem in this thread and "variables containing variables" which have appeared several times in this forum. Variable problems where you end up with exactly the same code as you started with but now it works. Almost forgot, the old style variables such as %C[1]% are more robust than variables like %controlname%

According to the ME Bible, Wait for Text Playback only applies to Text commands. Moderate amount of paste really need a time delay. When I'm moving 400KB of text from a web page it may need several seconds each to be sure of the Copy and the Paste. Otherwise 300mS and down to 10mS should suffice. It may be that copying text off or on to documents that contain other items such as images takes longer. PC setup may significantly affect times. Something else I've found is that it can help to have a very short time delay (10mS?) after the Wait for (Anything) commands. It seems like the Wait for command hasn't quite done with the processor when it gives the OK signal. That could be PC specific.

I have a bizarre problem with a Repeat not repeating. It was a simple macro set to repeat 100 times. It runs Variable Set String, Prompt for Filename. After messing around and removing all the commands the problem seems to be that any Variable Modify String command that follows causes the repeat to fail. Below is the shortened macro. If the Variable Modify string is enabled the commands run once. If disabled it repeats. Repeats in other macros run normally. Reproducible by others? Repeat Until %T[99]% Equals "Never" Variable Set String %T[1]%: Prompt for a filename Variable Modify String: Replace "\" in %T[1]% with "/" End Repeat <REPEAT UNTIL Variable="%T[99]%" Condition="\x00" Value="Never"/> <VARIABLE SET STRING Option="\x08" Destination="%T[1]%" Value="Choose Folder"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%T[1]%" ToReplace="\\" ReplaceWith="/" All="TRUE" IgnoreCase="TRUE"/> <END REPEAT/>

I couldn't reproduce your problem. Have you tried going back, deleting the variable ZZZZ completely and re-entering? I'm sure I've had similar glitches but they've also been related to If statement issues and variables within variables. This week I was having problems with variables and messed around endlessly. The problem finally disappeared. I had no idea why other than I entered the variable numerous different ways. I've also found %controlname% more problematic than %C[1]%.

Sorry for my late response. The idea is to simplify macros with numerous Ifs. Going off to AutoIt doesn't fit the bill although it's a neat solution. There's no reason why Case can't have the same options as If (as if it can't!), but I suppose it operates per other applications. It's much clearer seeing a list of alternative returns than a bunch of nested Ifs.

It would help if someone with access to your version could chip in. Did you try the resume pause hotkey to pause it?

I don't have that version installed. Did you try searching for "Pause" or "Pause Macro" (no quotes) in Help (Index or Search tabs if 3.2 has them)? It may be in another section in 3.2. It may also be called "Pause Macro HotKey". It will be some combination of Scroll Lock, Pause/Break, ', Win, as will be the "Abort Macro Hotkey". Even back then, ME's Help was good as far as I remember.

For the reasons I commented your biggest hurdle would be to get something working effectively in blocking content. That comes way before effort on meddling control. Their most-likely reason for turning off your system is if it makes things too inconvenient. If it's just your kids, there are far easier ways of checking their behaviour. It could be simple things like writing the time or sequential numbers to a text file every 5 minutes while the macro is running. You could check later (or have a macro do it) to see if there were any gaps. That tells you far more about their mindset eg they want to see unsuitable content.

I don't have anything that fits the bill. You are getting into areas that can potentially be used for malware. Some viruses protect themselves by the method you described - multiple files checking on each other and recreating their buddies if they are deleted. Every time you delete one, it springs up again. The fact you are using ME would indicate that you're not looking at shutting down MS! However, I would not post any code that would give someone else a helping hand or bad ideas. If I come across anything I'll PM you (as hopefully will anybody else with ideas).

An interesting project. Do you think that ME is in danger of being blocked? Is the intention to stop a user other than the "keyholder" from blocking ME? I've never had ME attacked and I've been through quite a few hostile sites - not that I frequent porn or anything, well, not on Sundays! You don't have to show ME at all in the system tray. Marketing anything with ME is of limited value since mxe files cannot be run on PCs without "..the Macro Express player" installed. Never seen a player myself. Must have bought the economy version. There's a host of content policing programs out there. Most websites don't use the capability in the code to identify as safe for kids etc. If you search for anything remotely connected with women you will get results that include nudity etc that is not readily identifiable. "This is a picture of me and the wife" may be pornographic but impossible to identify as such. You can use the page source (View, Source, Page Source depending on browser) to go through text but it's not convenient for the user. As you indicated you would need to parse the page but in an unobtrusive way. AutoIt has quite a few IE related scripts in the Helpfile listing such as _IEDocReadHTML.au3 but then you have to program in AutoIt - not as much fun as ME. Neither seems big on non-IE but then browsers like Firefox have boatloads of add-ons and safe browsers written for them (or you can write yourself).

If Windows or some idiot with access to the PC wants to shut ME down there is nothing you can do as there are a variety of heinous options. Why would someone terminate the process when they can turn off the PC? What happens if some other program freezes the PC? The possibilities are endless. Did you have anything (anyone!) particular in mind? The only thing I can think of is to monitor ME with another program. Check if ME is running every so often and if not start it. You may be able to do that in Scheduled Tasks (I never use it, all scheduled stuff by ME) or other macro programs. If I'm running my PC for weeks unattended and running complex, flaky macros, I use a 3rd party utility to do a forced reboot once or twice every day so that even if ME or anything else hangs up, it will be running the next day. Google may be of help in getting ideas. Screensaver-style lockout programs would tend to inhibit many macros. Perhaps there are some lock utilities that reside in the Task Bar. Even if ME restarts, it may need to know which macro was running. Every macro you plan to run in this scenario of saboteurs will have to register, say in a text file. When ME restarts, you will have to run a macro that runs on ME startup that goes to the text file, gets the name and runs the macro. Not a problem with scheduled macros unless you must re-run one that was in progress. You need to have ME ignore errors so it keeps running as best possible (set in Options). No good having ME running but hung on an error.

I recently went through this exercise upgrading to the Pro version. All ME3 references had to be modified (I keep some of my files in the ME folder). Unfortunately the Pro version is different enough that the macro would need a complete re-write. Can't help further since not many questions were answered. If it is an ongoing issue, heed my last words about storing URLs by other means.

See Options/Preferences/Playback and the associated Help. If the macro is zipping through commands you may not have much choice where it pauses but it's good if you are running round an endless loop.

I'm not sure what you are trying to do. You have macros containing URLs that need to be changed to other URLs? The macros are all in one PC, all in one Macro File? ME is lacking in global replace and ME3 is lacking Replace within a macro file. I'm guessing you would have to write a macro to: Select each of the affected macros in turn (Find in Macro Explorer using macro name) Open in the Direct Editor (context menu or Macro menu) Edit/Search and Replace once in the Direct Editor Close - go to next macro Hopefully someone will post a better method. Did you search the Forum? You could put all the affected macro names in a text file and Text File Process to work through the list (in conjunction with Find). (edit) There are other ways of handling changing data, by storing in an ini file for example and calling up the URL into a text variable when the macro runs. Ini files are plain text so are easy to edit directly. May be a better route than muddling along with what you currently do if this is an ongoing issue.

What you are seeing is exactly what I described. The issues that you will get with ME and Get Pixel Color are the same as screen captures. Digressing a bit, screen caps, grabs etc are terms freely abused. I differentiate into two types - screen captures and video captures but these are only my usage. Screen capture is capturing what Windows puts on the monitor screen. For most folk making a "screen grab", they are capturing what Windows tells the graphics to display. Capturing the screen on a 1:1 basis gives a capture say 1024x768. If the media player is in "Normal" mode, any playing video will also be captured. Windows is putting it there. Get Pixel Color will also work. If the media player is in "Overlay" mode, where the video should be playing, you get the black rectangle when you do a screen capture. That is all that Windows sees (even though we see video on the screen). The video is being intercepted between Windows and the monitor by the graphics card. The black rectangle is replaced with the generated video (could be a game, movie, TV show). Video capture is capturing the video at source. If you capture video at source size from a playing dvd or TV, NTSC format, the capture will always be 720x480. Video games vary to settings. Most capture programs can also resize the capture so you can have it any size including 1024x768. If you want to access "Overlay" video, you have to use video capture (WMP may be an exception, I don't use it). The capture is usually done with a utility that comes with the graphics card, or by a utility that can figure out how to access the video stream directly. As an example, my ATi graphics has a TV tuner and it also has a function ATi Rage Video Capture. The ATi interface can capture the TV video or stills, but I also use another application that taps into the same video capture stream. I've never come across a color picker that provides this access and most "screen capture" utilities do not. Try and capture with Prt Scr and you get black. It's something of a minefield, but generally speaking failure to register the pixels is due to Overlay mode. Media Player Classic will not capture images if in Overlay; you have to change the Playback Output option. Re OT I've yet to have problems with FF and this forum. I'm often compose in Notepad and copy into the forum message box.

Something to considerate when stringing macros together is that if the first hangs up, the second may not run. Take a look at the choices in Options/Playback. I normally ignore errors but it depends what you are doing. I string up to 6 together although there's really no limit. If it is important that all macros carry out their tasks, you can get the first macros to leave a message somewhere (several ways to do that) and run backup scheduled macros later that check the message and run if there was a problem. Another simple method is to stagger the run times, allowing time for the first to finish. That depends on what it is and how predictable. (edit) I forgot the often-forgotten simple method - copy the code of the 2nd macro, make a copy the 1st macro, rename it, add code from 2nd macro at the end of the 1st macro. You should try rberg's method though because you can use it in other ways. I have a list of daily macros to run in a Multiple Choice list. I check the ones I want to run and it runs the selected macros in sequence.

I should elaborate on overlays for anyone trying to Get Pixel Color with ME. You can't do it and it's one scenario where what you see is entirely from the graphics card, not from any Windows action. I'm not familiar with the mechanics of it but here's a simple explanation. If you have a video application such as TV, movie or video game that uses Overlay, the graphics tells Windows to put a black (or similar) rectangle on the screen. All Windows sees is the black. The graphics card puts its display "behind" and everywhere the screen is black, the video shows through. They are normally the same size and location. If you put a colour picker on top, it will only see black (from Windows). Overlays can give some peculiar effects. If you have your TV app running but are viewing photos in a graphic application over the top, you will not normally see the TV picture. However, anywhere the photo is black the TV picture will show through.

Re Paul and rberg, My PCs are similar, XP, same res, different graphics, different graphic card settings. One has changes to brightness and gamma within the card settings to give similar naked eye appearance. I don't think global utilities like Adobe Gamma would affect the measured colour (by ME or other screen colour picker) nor graphics editors like ThumbsPlus where you can adjust gamma for the app. I'm guessing that colour management is a background activity. It still uses the same pixel value but when it comes to doing something like printing, it says "the monitor looks like this but the printer does this, so change the colour to print to this"). IMO the graphics card should make no difference (to static displays) assuming Windows setup is the same. It may look different to the naked eye. On my PCs, I can find no differences on a per pixel basis in areas where one would expect similarity. In the tray for example, the x coords are going to vary due to which icons are where but on a pixel-to-pixel basis my icons are identical in content and y location. If I were going to x64, I would anticipate there could be differences. 131060660 is so much last year's grey! Could be the same as 32 bit but I would check. If screen colour depth is lowered you would certainly see differences. The icons for example would use the lower res versions and graphics would be posterized - colour puddling for high res pics. I can't explain all of the variations you guys are seeing. Title bars with gradients are iffy. I never use them other than the window disappears and there is a different colour behind. On my setup, the title bar is constant colour for about the first 20-30 pixels from left then the gradient kicks in (depends on window width). My older version of Access seems to follow the same rules as any other window. The tray icons changing colour seems strange. When I was compiling the PixelSearch script I looked at modifying an AutoIt icon to make it unique. Too much work to edit all! The icon stack consists of: 16x16 16 colours 16x16 256 colours 32x32 16 colours 32x32 256 colours 48x48 16 colours 48x48 256 colours In my setup it would choose the 16x16 256 colours for tray and file listings. My setup would only use others if I used "large icons" in particular circumstances. If I really had to keep settings for each PC and there were lots of PCs, I would use text or ini files for the settings. Way easier to handle for reports and incidental viewing. Getting info out of ME macros is a bit of a pain. I'll bear your comments in mind for the future.

I realize that. The problem I have is that when I test on my PC where AutoIt is installed, I don't know whether the exe is running correctly or whether it is using the installed AutoIt files. Ideally you need to test on a PC where AutoIt is not installed. Then you know if it works as standalone. As far as colours go I'd have to disagree. I'm not sure what experience would lead you to think otherwise. When pixel colours are grabbed it should be from the data going to the graphic card. Otherwise the standard ME colour tools would not work. If you take standard Windows grey 131060660, that is always the same. Doesn't matter what PC, monitor or graphic card you use, it's the same as far as the system is concerned. One thing you cannot do is to zoom in or out, say on an image after the sampling. The pixel colour will normally change, if not by simple displacement, by resampling. I'm not sure what happens with overlays - I would guess you could only measure the background colour which is normally black. Tested that with my TV app, #100010 or 16,0,16 RGB, curious. I'm not sure about when applications use colour management. For the sort of tasks Alan is most likely doing, that is irrelevant. If you are doing screen calibrations with photometric devices they will be affected by all parameters. I'd be interested in your experience. I do a huge amount of graphics processing and I've never seen variations between colour picker results and applications. What would happen with websafe colours? The script as shown is outline only. As it's written, you change values in the script and save - test only. As I pointed out to Alan, he will have to sort out his own I/O depending on how he uses it. I would assume for automatic operation you would store the required colour as a variable and use the fact the colour has been found or not to do the necessaries. I have run into a really peculiar problem. After all my successful testing I found it did not seem to work. It was easy to find out why but I have not resolved the issue yet: Mouse Locator gives two values. One is a Windows colour number which seem to be (BBGGRR). The GRRRRR is poignant! The other is the HTML Hexadecimal value (#RRGGBB) minus the # of course. AutoIt works with Decimal or Hexadecimal (HTML) colours but not Windows colours. For example, the pale yellow information area in ME Explorer is as follows: Mouse Locator 14811135 (BGR 225,255,255)(E1FFFF in hex) and 0xFFFFE1 (RGB 255,255,225)(16777185 in decimal) AutoIt PixelSearch will work with 0xFFFFE1 or 16777185 That makes it more awkward to use because the Mouse Locator only returns the Windows colour. You would have to manually enter the hexadecimal value in the macro. I have not tackled the conversion yet but maybe PGM have! (Edit) I've made a few more scripts to assist with colour handling, both in dialogued and blind (no user involvement) versions: Decimal to Hex conversion Decimal Windows BGR to Hex RGB conversion The latter would be used if obtaining colours from ME and the mouse, then using the data for PixelSearch or other apps needing Hex RGB. What a pain.

If you are not interested in installing AutoIt, I have written a standalone exe. Unfortunately, although it works fine, I can't test it as one would wish since I have AutoIt installed and I can't tell if it's using that by some roundabout means. Suggestions from experts? I have a second MEPro script similar to the previous one. Instead of calling the script it does the following: Writes all the parameters to a file c:\temp\pixelsearch.ini Runs an AutoIt file PixelSearchfromIni.exe That imports data from the ini file Does the pixel search Exports the info back to the ini file The MEPro script reads the X, Y, and whether the colour was found Deletes the ini file It takes a fraction of a second longer than the scripted version. I can post if you are interested.

That really is desperation! I've been learning AutoIt so this was an opportunity to try out my code on others. Below is code that seems to work. You would need to have AutoIt installed. I thought about making a standalone exe file but this is it for now. Takes about a second on my pc if nothing found (whole screen searched). I did not try your totally-MEPro script so have no comparison. You will need to change input and output presentations to suit your needs. It will return the X,Y coords or a message "Color not found". // Rectangle Coords Variable Set Integer %left% to 0 Variable Set Integer %top% to 0 Variable Set Integer %right% to 1024 Variable Set Integer %bottom% to 768 // Color variation 0-255 None=0 Variable Set Integer %colorvar% to 0 // Step 1=every pixel, 2=every 2 etc Variable Set Integer %step% to 1 // Color as Decimal or Hexadecimal Variable Set Integer %pixelcolor% to 0x990066 External Script: AutoIt // Output in %coordxy% Text Box Display: Result of Pixel Search, X,Y <COMMENT Value="Rectangle Coords"/> <VARIABLE SET INTEGER Option="\x00" Destination="%left%" Value="0"/> <VARIABLE SET INTEGER Option="\x00" Destination="%top%" Value="0"/> <VARIABLE SET INTEGER Option="\x00" Destination="%right%" Value="1024"/> <VARIABLE SET INTEGER Option="\x00" Destination="%bottom%" Value="768"/> <COMMENT Value="Color variation 0-255 None=0"/> <VARIABLE SET INTEGER Option="\x00" Destination="%colorvar%" Value="0"/> <COMMENT Value="Step 1=every pixel, 2=every 2 etc"/> <VARIABLE SET INTEGER Option="\x00" Destination="%step%" Value="1"/> <COMMENT Value="Color as Decimal or Hexadecimal"/> <VARIABLE SET INTEGER Option="\x00" Destination="%pixelcolor%" Value="0x990066"/> <EXTERNAL SCRIPT Language="AutoIt" Dest="%coordxy%" Script="; Find pixel entered as decimal or hexadecimal in defined rectangle\r\n$left = \"%left%\"\r\n$top = \"%top%\"\r\n$right = \"%right%\"\r\n$bottom = \"%bottom%\"\r\n$colorvar = \"%colorvar%\";color variation 0-255\r\n$step = \"%step%\" ;steps, optional, 1=every pixel\r\n$pixelcolor = \"%pixelcolor%\"\r\n\r\n$coordxy = PixelSearch( $left, $top, $right, $bottom, $pixelcolor, $colorvar, $step)\r\n\r\nIf Not @error Then\r\n;Optional message from AutoIt\r\n;MsgBox(0, \"X and Y\", $coordxy[0] & \",\" & $coordxy[1])\r\n ConsoleWrite($coordxy[0] & \",\" & $coordxy[1])\r\nElse\r\n;Optional message from AutoIt\r\n;MsgBox(0, \"Warning\", \"Color not found\")\r\n ConsoleWrite(\"Color not found\")\r\nEndIf\r\n" _COMMENT="Output in %coordxy%"/> <TEXT BOX DISPLAY Title="Result of Pixel Search, X,Y" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\qc\\lang4105\\f0\\fs16 Color %pixelcolor%\r\n\\par %coordxy%\\lang1033\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="177" Height="107" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

Most people would find other ways of identifying screen changes or, given the utility you mentioned, invoke that with MEP to do the legwork. MEP is great for ease of use but where it is slow, it is better to use it to control other apps. Not a big deal IMO. Now that MEPro can run external scripts, that's another route - minus the ease of programming! You have to be quite desperate to be searching for pixel colours generally. I've usually found non-pixel ways of doing it. You may be looking at pixel colour to tell if a box has appeared but that's not one-pixel sensitive. My main pixel colour usage is in telling whether Firefox has loaded a page. I went the route of the custom throbber which you design to give a predictable area of uniform colour. I cannot envisage any method for speeding up the macro you specified other than if some parts of the rectangle are more likely to contain the pixel than others (have MEP build a history of past search successes and start there!)

I've had quite a few hangups (most of which seemed to require closing MacExe, MacEdit and MacScript in Task Manager and waiting a while). The occasional hangup required a reboot. Most have been limited to two scenarios: First, using Test Run in Script Editor. After using it a couple of times, a hangup seems obligatory. I normally troubleshoot new macros by adding in multiple Text Box Displays as breakpoints and manually running the macro so it's not a big problem. Having used Test Run a few times and exiting Script Editor, the hangup problem may still persist. I find the Script Editor highly suspicious. Even if I have not made any changes, it takes 5 seconds for the window to close (no backup on exit selected). On the plus side Script Editor can handle large numbers of macros under edit at the same time. Second, I run housekeeping macros that are run from my System Maintenance macro file. It is open in MEP Explorer. It opens each pre-selected macro file one at a time, does the necessaries and closes it. Repeat through the list. While running a macro that added a specified macro to each macro file, it would hang at the point the current file was closing and the next one was opening. I resolved the problem by allowing more time for the current file to close. Other than for these operations, I usually only have one macro file open at a time. Have you tried not starting MEP at startup and starting manually? When I was running my PC unattended for weeks on end I would do a forced reboot each day using another program and delay the start of ME (in Options) to ensure no conflict with other starting programs. I had no particular reason to do that other than to ensure it started up exactly the same way each time. ME itself started other programs on its startup and kept them clear of the boot process too.

Unfortunately my current exercise is to replace If statements where possible and to use Case more in the future.