Jump to content
Macro Express Forums

jsams

Members
  • Posts

    23
  • Joined

  • Last visited

Recent Profile Visitors

167 profile views
  • max

jsams's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Well, stupid is as stupid does. Once I'd decided it was a bug in ME, I was blind to the bug in my code. Thanks, paul. My face will eventually quit being this color...
  2. Can someone either give me insight or verify this issue on their machine? I use virtualization almost exclusively in my work. At any one time, I'm typically administering two dozen different virtual machines. Now if I name a VM "VM-Foxtrot", there is no way for that VM to self-reference its name [a configuration report, for example]--until I create a registry value within each VM. Okay, done. The macro only runs at startup of the VM [after MEP loads], and should display the prompt only one time: <IF REGISTRY Key="TRUE" Exists="FALSE" Path="HKEY_LOCAL_MACHINE\\SOFTWARE\\Macros\\VM"/> <VARIABLE SET STRING Option="\x01" Destination="VM" Prompt="Name this VM:" Mask="FALSE" OnTop="FALSE" Left="Center" Top="Center" Monitor="0"/> <WRITE REGISTRY VALUE Key="HKEY_LOCAL_MACHINE\\SOFTWARE\\Macros\\VM" Destination="%VM%"/> <ELSE/> <MACRO STOP/> <END IF/> Except this macro still prompts at every startup of every VM, asking for a VM name when the registry key and string value already exists. I put a delay on MEP starting, it still prompts every time. I flopped the logic; still prompts. Sure, all I have to do is cancel the prompt forevermore after the initial run, but it still annoys me to no end why this simple macro doesn't work as expected. So, either I'm missing something fundamental [i don't know what I don't know], or it's a virtualization issue, or possibly a defect in MEP 4.2.2.1. Thoughts?
  3. Yup, I'm adding my two cents to bump this thread; this is certainly something ISS needs to be addressing. I didn't begin experiencing any significant slowdown until 4.0.4.1, released last month. I've been using MEP to automate some software test processes in my job, so the applications under test [ArcGIS software] frequently crash. [Yeah, I'm paid to break things. ] Initially, I thought it was the crashed AUT that was seizing up my virtual machine; I had no macros running, so it couldn't be MEP. I then went on vacation, and came back to discover this thread at the top of the bb. Sonuvagun, it is MEP! Terminating MEP during any slow-running or mouse/keyboard locking, the issues went away immediately. I now terminate MEP before any testing, and have not used MEP in the past week. If MEP can't be trusted even to lounge in resident memory without doing something detrimental to the OS, yeah, that's a serious bug, IMO. ISS, let us know when we can go back to using MEP...
  4. 1. Nope, ain't be using Save/Restore. There are no values carried from one iteration to the next. 2. I was using the Goto to skip the If/End If statements for values between 100000 and 999999. 3. My duh. Never realized I needed only one If loop to pad the decimal appropriately. Actually, come to think about it, I don't need any If commands... <VARIABLE SET INTEGER Option="\x05" Destination="%Lon_Seconds%" Minimum="1" Maximum="999999" _IGNORE="0x0003"/> <VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon_Seconds%" Variable="%LonSeconds%"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon%" Variable="%Long%"/> <VARIABLE MODIFY STRING Option="\x06" Destination="%Long%" Value=".%LonSeconds%"/> <VARIABLE MODIFY STRING Option="\x05" Destination="%Long%" Variable="%Longitude%"/> Well, let me run these overnight again and see if this clean macro throws the same horseshoe. Thanks for the feedback on my fat script.
  5. I have a macro that is designed to run overnight, creating data in a .csv file. Part of the data is latitude and longitude values, generated randomly by two sub-macros, aptly named "Longitude" and "Latitude". The value returned is a decimal variable with six decimal places [padded if necessary]. These two sub-macros are identical in logic, and differ only in the names of the needed variables. The Latitude macro is always called before the Longitude macro runs. This routine has never finished an overnight run in four attempts. At some point, only the macro Longitude generates a script error: "Undefined variable or the variable is the wrong type '%Lon_Seconds%' ... Line Number: 2". This is after this macro has successful runs between 12,000+ and 47,000+ iterations before erroring. The macro never errors at the same time or after the same number of iterations; it seems quite random in its hiccup. Yesterday, I decided to define the offending variable %Lon_Seconds% in the parent macro as a possible workaround for this odd behavior. Last night, the macro Longitude—after 13,004 successful calls—threw an error: No matching "End If". WTF? I don't think I'm looking so much for a solution [since this seems to be a deep and intermittent issue that may not have an easy fix] but more for verification. Anyone else have macros that throw similar errors after many successful iterations? For what it's worth, I'm attaching the code. But if it runs 10,000 times, I don't know why the code seems to go south even though nothing's changed mid-run... <VARIABLE SET INTEGER Option="\x05" Destination="%Lon_Seconds%" Minimum="1" Maximum="999999" _IGNORE="0x0003"/> <VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon_Seconds%" Variable="%LonSeconds%"/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x03" Value="99999" IgnoreCase="FALSE"/> <GOTO Name="Done"/> <END IF/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="10" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <END IF/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="100" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <END IF/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="1000" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <END IF/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="10000" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <END IF/> <IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="100000" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/> <END IF/> <LABEL Name="Done"/> <COMMENT Value="The integer %Lon% is created in the calling macro."/> <VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon%" Variable="%Long%"/> <VARIABLE MODIFY STRING Option="\x06" Destination="%Long%" Value=".%LonSeconds%"/> <VARIABLE MODIFY STRING Option="\x05" Destination="%Long%" Variable="%Longitude%"/>
  6. How are you determining that a macro isn't doing anything while Mr. Green's running? Variables window? Task Manager? Other? Defining how you're looking at the issue will allow it to be replicated on other machines--or determine that it's all in Steve's machine's head...
  7. Sorry. I guess I probably should have divulged more of what I understand about the issue—not that that equals much... What I'm seeing is from an add-on app to a WinForms program; the app uses WPF. The WPF windows that are generated by this app can be manipulated by keystrokes [such as <TAB><TAB><ENTER>] and even accepts MEP-generated text in textboxes, etc. But to the Pixel Color in the Mouse Locator tool, these windows just are not there. The pixel color is whatever is beneath the WPF window [or windows; at one point there are two WPF windows stacked, and the pixel color sees only the underlying WinForms pixels]. With that said, I'll have to look at some of your workarounds, Alan. I haven't noticed if I can cue off of the mouse cursor, so I'll report back. Thanks for the alternatives. I will file a bug report with Insight about this limitation. There's an interesting WPF webpage that confirms what looks like a general WPF/WinForms issue, and code for a workaround, which might be a seed for a solution in MEP. Pixel-color-under-mouse. I am a bit amazed that this info is almost two years old, especially if WPF is "the future", according to some developers. But, like any transition, there's bound to be headaches...
  8. Well, on the bright side, this is not an issue specific to MEP; it is also visible in ME3 as well as AutoIt. [Darn it! I was hoping for a workaround with AutoIt, if nothing else.] I've attached a busy screenshot of AutoIt's and ME3's Mouse Locators simutaneously looking at pixels not visible in the WPF window. AutoIt has a nice feature of a Zoom window for accurate pixel location, which actively shows the pixels under the mouse, which is why I included AutoIt in the screenshot--as well as a sanity check for ME3's Mouse Locator. This may be one that I throw back into the laps of the developers; maybe they should have to come up with a standalone app for picking up the pixel color in a WPF window. Well, I can hope, can't I?
  9. Some of the development of WPF is occuring in browsers [using Silverlight, for example], yes, but this particular WPF app is actually desktop-based. The head of Development made the analogy that it's like building a addition onto one's home using a completely different architecture: you can live in it, but from the outside it looks a bit 'different'. I know many of us have had our share of headaches in using ME to interact with controls, comboboxes, buttons, et al, in browsers. The problems I've had with standalone apps and ME have always come down to my current capabilities in using ME, and usually browsing these boards give me new ideas, and new ways of approaching a particular problem. In other words, I always had absolute faith in my ability to automate standalone apps with ME. Until now. It's gonna suck if MEP does not play nice with WPF. I hope Insight has some input. Wish I could but, again, it's a desktop application [and proprietary software currently in development].
  10. Does MEP work with a WPF framework? Currently, I'm trying to automate a process whose UI is written in WPF, not the usual Windows Forms. In waiting for the creation of a child window, I use the usually robust 'Wait for pixel color under mouse to equal %Green%, then proceed.' But, in scripting the macro, I launch the Mouse Locator to determine the exact value of the pixel color for which I'm waiting. The mouse locator returns ONLY the value for Light Grey [on my monitor, 13554646], no matter where in the WPF window my mouse is! The window itself has red and green and blue, but the Pixel Colors according to MEP are grey and grey and grey. And if all pixels in the parent window are grey, and all pixels in the child window are grey, that means 'Wait for pixel color' is no longer an option, which is gonna turn my hair flippin' 13554646. ISS, is WPF supported? Everyone else, have any ideas or experience with this?
  11. Sorry my workaround doesn't work around your needs, Steve. There's always hope that Kevin'll weigh in and show us what yoyos we are and how easy it is to do... I have a vague recollection of some sort of Excel-Macro Express 'solution' being in the works, looking for testers, something like that. Anyone else remember anything like that, or am I having a Monday morning hallucination? Wonder what's happening there?
  12. Ah, man, you're preaching to the choir here! About 80% of the data I deal with daily needs to be in .csv form, which is great because ME handles .csv files so well. And, yeah, Excel outputs some FUD when trying to save to a .csv file. Here's what I do: 1. First, set the default program for opening .csv files as Notepad and not Excel. That prevents future corruption of .csv files with Excel's crappy conversion. (I can still open .csv files with Excel, just not by accident!) 2. With existing .xls or .csv files, open them in Excel, but save them as a tab-delimited .txt file. 3. Now turn ME loose with Text File Begin/End Process, replacing all TAB characters with commas. <COMMENT Value="The tab-delimited file saved from Excel."/> <TEXT FILE BEGIN PROCESS Filename="C:\\My_text_file.txt" Start_Record="1" Process_All="TRUE" Records="1" Variable="Record"/> <COMMENT Value="You can copy the \"invisible\" tab in the text file, paste it into the \"Replace\" field, and replace with a comma. Toggle \"Replace All Instances\"."/> <VARIABLE MODIFY STRING Option="\x0F" Destination="Record" ToReplace=" " ReplaceWith="," All="TRUE" IgnoreCase="FALSE"/> <VARIABLE MODIFY STRING Option="\x12" Destination="Record" Filename="C:\\My_converted_file.txt" CRLF="TRUE"/> <TEXT FILE END PROCESS/> 4. Once all records are processed, ME can rename the converted file to "My_converted_file.csv", and I'm done. Alternately, I occasionally need my .csv files with quotes around data with spaces between the commas. I do the same conversion, but replace all TABs with \",\" and then prepend and append an additional quotation mark to each record before it gets written to the converted file. Clear as mud?
  13. Yeah, every now and then I get that same error message for a variable at runtime (for me, though, it always happens at first run, never suddenly appearing after successful runs). My workaround, when my variables are getting the values I want (i.e., everything's working fine except for the flippin' variable error), is to switch off the "Halt Macro" for that error. (From "Variable Set String" window, the "On Error" tab, there's a combobox for every error type to tell MEP how to respond.) Change it from "Halt Macro" to "Ignore Error", and see if that gets your macro to run successfully.
  14. Steve, have you peeked into the registry to see if your key value is being populated with the correct values after a Clipboard copy/Registry write? Similarly, have you verified your variable %cb% is correctly populated at runtime? If both of those are accurate, then Paul's probably right about the clipboard being the weak link. Other fundamental troubleshooting questions: * Is text the only thing on the clipboard? * Are there any CR/LFs tagging along on the clipboard? (I'm not sure how the Registry would interpret a CR/LF in a string value; could that choke the macro?) * Are you copying from only one source (e.g., MS Word), or are there multiple programs from which you use your multi-clipboard? Is there one specific program for which your macro fails? * Alternately, take the same text value that works in one program, and use it in the other programs from which you copy/paste. It may be program specific. * Your copy/paste uses %cb% as an array, but you don't have the array for the Registry read/write commands. Problem? I've been using ME (and MEP now) since 2001 as an inexpensive and powerful tool for software test automation. (I even quit a job over Macro Express; long story...) Most of my Registry use has been keeping count of test iterations, last values parsed, and innumerable conditional flags for runtime. You've already pushed beyond the envelope of my experience with the combination of clipboard and registry. Although I cannot think of any examples offhand, I'm sure there have been occasions in my macro scripts where the Registry commands didn't work the way I intended. I'd try a different set of macro commands and finally achieve my intended result. That, for me, is one of the sweetest things about ME: usually there's numerous ways to perform a task with ME, and if one don't work, the next one will. For the record, though, I never intended to lead you to believe the Registry commands were the silver bullet to saving/restoring variables. Just a robust method for when I really need to save important variables between runs.
×
×
  • Create New...