cag8f

Thanks for that. >> Since \R already involves an atomic group, it's pointless to enclose it in another atomic group. That's what I was thinking. >> Hence your pattern boils down to...a non empty line followed by a newline sequence. And the results--each element of the returned array contains one line of text, followed by a blank line--is consistent with this. Thanks.things. I have no idea where I got this expression. The code is from over a year ago, but none of it looks familiar. Atomic groups and newline sequences are things I've never used or learned before. So I assumed I asked this forum for help some time ago and was given this black-box regular expression which I just plugged in. But I (very hastily) looked through my old posts here and couldn't find anything. Oh well. On a side note, you posted your reply ~13 hours ago but I didn't receive an email notification. My settings are such that I should have received one. I also checked my spam filter, but nothing. Should I make a new post about this, either in this forum or another? edit: 1. I'll try replacing the string with simply .+\R to verify that they are equivalent. 2. Thanks for regex101.com--I'll check it out.

Hi all. I'm revisiting poorly commented code of mine from over a year ago. In one line I search a string for a regular expression and cannot figure out exactly what the code is searching for. The expression is: .+(?>\R) I've tried to piece it together from the StringRegExp() page. My educated guess is that it searches for newline characters in some capacity. Here is what I have so far: (?>\R): The (?>...) indicates an atomic non-capturing group, meaning in-part that string matches are not recorded for later reference. I'm not sure what the 'atomic' means though. The description says that this 'locks,' which I'm also unclear on. The \R matches any (Unicode) newline character. So is this component somehow searching for new lines? .+: I'm not sure how these are modifying the above, nor exactly how they work together. The . matches any single character except newline characters, unless (/S) is active. How can I check if /S is active? Would it be a parameter set in one of my options files? And the + seems to match 1 or more. This seems to make the preceding . redundant? The complete line of code is: $aArray = StringRegExp(_IEBodyReadText($oIE2), '.+(?>\R)', 3) I'm reading body text from an HTML page. I can successfully print out each element of this array. Each element contains one line of text, followed by a blank line. Hopefully that helps to confirm things. Thanks in advance.

Great, thanks guys. I don't plan on anything too complicated with this project, so I can stick with a 32 bit environment. But for the future, in case I do want to dabble in higher level 64 bit Autoit programming, is there some official Autoit documentation that describes when/how I need to modify script writing and/or compiling?

OK to follow up though, if an EXE compiled for an x86 system will work without issue on an x64 system, why is there a "compile for x64" option? Just for my edification at this point.

Good call, it appears so. As my AV, I'm using the latest version of Avast. Here are test results: 1. If I disable Avast, build the EXE, and run it, there is no issue. But if I then re-enable Avast and run the same EXE, I get the aforementioned error. 2. If I enable Avast, build the EXE, and run it, I get the aforementioned error. If I then disable Avast and run the same EXE, I get a different error box: Title: Path + Filename of EXE Message: Windows cannot find <path+filename>. Make sure you typed the name correctly, and then try again. And the EXE has been deleted. I know what is happening. I recently put Avast in silent mode, meaning it does not pop up any messages when it blocks files. So it's blocking this file, but I'm not receiving a notification. It is blocking aut2exe.exe during build--more specifically it is blocking a .tmp file created from aut2exe.exe during build. Then I get the aforementioned error when I try to run the EXE, presumably b/c the .tmp file is missing. I need to find a way to tell Avast that files created by aut2exe.exe are legitimate. Anyone know how to do that?

I've re-compiled many times by now--at least 10.

On my home laptop (also Win 7 Ultimate), the EXE (without the #include line) runs without issue. That is, when I run it, the expected message box appears, and it only runs once. Compare this to my work computer, where the same EXE will run twice, and result in an error message each time. Any idea how I can further troubleshoot to isolate the issue? Re-install autoit is my only idea.

I'll try it on another computer I guess and see what happens.

test.au3-->test.exe

I'm not sure. The title of the message box that appears is "AutiIt Error." Is there a way to troubleshoot further? Another anomaly that may or may not be related is that the EXE runs twice. I receive the error message once, then again after I press OK. Or if I don't press OK, the first box will disappear then the 2nd box will appear. If I add the #include line, the EXE also runs twice--I receive my desired message box twice (with the same behavior as the error box). When I then run the same EXE on a 64-bit system, I only receive one message box. Thoughts on all of that?

I have a very simple script to create a message box: MsgBox(0, "", "test") I can run it by itself, from scite, without issue. But when I compile it (using default options) and run the resulting EXE, I get an error, "Unable to open the script file." When I then add the message constant include line: #include <MsgBoxConstants.au3> to my code, compile, and run the resulting EXE, the error message goes away. Why is that line necessary for compiling, but not for running from within scite? OS is Win 7 32 bit.

Thanks. But when I click 'Compile,' a window opens up, and one of the options is "Output arch." There are 2 check boxes here: Compile X86 version. Compile X64 version. How do these fit into our discussion? Do I need to make sure to check the latter?

Thanks for the reply. This sounds like you are saying I *can* accomplish my goal (If I'm understanding this correctly). Specifically, the second sentence--isn't it saying that I can build (and test) my script in my 32-bit environment, and deploy it on a 64-bit machine without issue?

I am developing/testing a code on a system running Windows 7 32-bit. The goal is to eventually build an exe from the code and run it on a system running Windows 7 64-bit. If I do not have access to a 64-bit system, will I be able to accurately/comprehensively test my code to ensure that it will run properly on the 64-bit system? For example, is there a way, while testing on my 32-bit system, to somehow mimic the key conditions/characteristics of a 64-bit system? Or is there a way that I can build my code/exe in the 32-bit environment, and somehow instruct it to run "in a 32-bit manner" (whatever that means), even if on a 64-bit system? This may be more of a Windows question, but I decided to start here.

OK resolved for now. User error I guess. I had set Opt("PixelCoordMode", 0) Instead of Opt("PixelCoordMode", 1) Making that change gives me consistent colors. Thanks for everyone's help!

OK thanks for that info. The difference in colors is very small: 00FF00, 00DD00. So perhaps: 1. AU3info does uses a slightly different algorithm than pixelgetcolor() when calculating colors. Highly unlikely, and maybe not even possible. or 2. Since the colors are shades of themselves (lime green), they could be neighboring pixels. So perhaps the coordinate systems between my AU3info and pixelgetcolor() are slightly off. I will try to troubleshoot that more, perhaps by checking the coordinates/colors of the corner pixels. I'll post back here if anyone's interested.

@Malkey, thank you. I added that code though, but with the same results. @JohnOne. Thanks for your help. >> My guess is there is more to your code and it's calculation of x and y, and that is where your problem lies. For testing purposes, I've reduced my code down to one line: ConsoleWrite(hex(PixelGetColor($X,$Y), 6) & @CR) Anyone else have any ideas why this is happening?

No it does not. edit: should it have?

I tried all 3 and get the same results with each.

The colors, and use of Autoit to determine those colors, are the end result. I'm teaching an introductory programming class to high school students and wanted to do this as a lesson. But this is behavior I can't explain, so I'd like to understand what is happening before the lesson.

I'm using the Autoit Windows Information Tool to determine the pixel coordinate ($X, $Y) and color hex value (lime green, 0x00FF00). But when I then run a simple Autoit script to confirm this: hex(PixelGetColor($X, $Y) I am met with a different color hex value (0000DD00). Shouldn't the 2 hex values match? If so, am I doing something wrong? I found this old post describing a similar issue. '?do=embed' frameborder='0' data-embedContent>> I tried to follow the recommendations but encountered a problem. I made sure that the Coord Mode in AutoItInfo was set to 'screen,' but I couldn't find where to set Opt("PixelCoordMode", ?). It doesn't appear to be in the User Options or Global Options files. Thanks in advance.

Type on _Excel_ColumnToLetter.htm: Converts the column number to letter(s). #Include <Excel.au3> _ExcelColumnToLetter($iColumn) I believe last line should read "_Excel_ColumnToLetter($iColumn)"

Validation :-)

Yay!

Great, good work. Will I still be able to come back here in the next couple days for questions as I begin to use them :-)