Lucid

Ward, Is there any chance you could take a look into your AES.au3 code and see what it would take to get it to work when compiling to an x64 executable? I ran into an issue when using RTFC's CodeCryptor (https://www.autoitscript.com/forum/topic/155538-codecrypter-encrypt-your-script/). Everything works just fine when compiling to x86. It's just x64 that's causing me an issue (and of course, the bit of code I'm working on HAS to be x64). Thanks for all the hard work you did on everything! It's helped a TON!

RTFC, thanks for the speedy reply! Right now I just have a super small bit of code that needs to be encrypted. So I don't think speed will be an issue. Do you have any suggestions on alternate algorithms that would work well with CodeCrypter? At least something to help me get my utility out the door and buy me time to try and track down Ward and ask him about the AES.au3 stuff...

I'm running into a problem using MCFinclude.au3 and am hoping RTFC or someone can shed some light... If I add the MCFinclude.au3 to an AutoIt script on my 64-bit Windows 10 box, it blows up when running as a 64-bit process. For example, if I use this piece of code: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Outfile=testing_x86.exe #AutoIt3Wrapper_Outfile_x64=testing_x64.exe #AutoIt3Wrapper_Compile_Both=y #AutoIt3Wrapper_UseX64=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <MCFinclude.au3> Msgbox(64, "test", "testing, testing, 1,2,3...") When I just select Tools | Go, I get the message that Autoit has stopped working, and a return code of -1073741819 Any idea of what I might need to adjust in order to get this working under 64-bit Windows 10? And it's only if I select to compile it as an x64 target. x86 seems just fine (or just commenting out the include). Thanks for all the hard work on this UDF!

I poked around on the forum, and asked Dr. Google his advice, but I'm coming up empty, and am not able to figure something out. So I was hoping someone here could shed some light for me. I'm trying to use GDI+ to create a custom GUI that sort of mimics the borderless alert notification window that is seen on Windows 10 (see included pic). I can get some embedded images to show, but I can't seem to get embedded images + text + a close "X" button to all show/work at the same time. I know there's the Metro GUI UDF, but I'm wanting just the bare bones code, and don't need a full UDF. So does anyone happen to have an example, or can give me some advice? Thanks! (going back to digging into other examples I previously found)

mLipok, thanks for the example and links! That helped me get it figured out.

First off, sorry if this is something that has been answered somewhere on the forum. I've been poking around for a while and have come up empty. My brain also is not wanting to wrap around an issue I'm having. I've got a large number of XML data that I have to parse in order to pull out specific bits of info from each. I can't seem to figure out the code to get the child nodes I need (my XML lingo is a little fuzzy too) Here is an example of the XML I'm trying to read: <?xml version="1.0" encoding="UTF-8"?><computer><general><id>000</id><name>MyMachine</name></general><software><licensed_software><name>Adobe Acrobat Pro XI</name><name>Adobe Acrobat X</name><name>Adobe Illustrator CS6</name><name>Google Chrome</name><name>Microsoft Office</name></licensed_software></software></computer> And here is a code snippet I've been messing with to try and figure out what my problem/solution is: Local $oXML = ObjCreate("Microsoft.XMLDOM") $oXML.setProperty("SelectionLanguage", "XPath") ;$oXML.loadxml(<DataReturnedFromAnotherQueryFromREST>) ;I'm reading from a stream and not an actual file in production $oXML.load("MySampleFile.xml") ;Loading an actual file is just for testing purposes Local $oItem = "" Local $oSoftware = $oXML.selectNodes("//software/licensed_software") For $oItem In $oSoftware ConsoleWrite("This spits out a glob of squished together info: " & $oItem.text & @CRLF) Next So how do I pull out each "name" node so they're separate and not globbed together? I've tried using selectSingleNode and some other variations, and I can't seem to get what I need. Can someone shed some light on what I'm overlooking (I have a feeling it's pretty simple). Thanks!

Nevermind! Totally my fault - got a number in the wrong spot in my test. Thanks UEZ! I think I'm able to move forward and try understanding/adapting your code.

Thanks for the speedy reply UEZ! I guess I'm not being clear. So what I'm trying to figure out how to do is to make an image semi-transparent on top of the background of the GUI (so you can see the background through the semi-transparent image). In the included pics, you can see that the red Torus ring is 100% in the one, but in the other the ring is like 55% transparent and the blue background shows through. How can I accomplish this with GDI+ using a PNG file? Thanks! And sorry for not being clear enough in my first post.

Sorry for not being clear. I'm looking to be able to alter the transparency of the image, but keep the background of the GUI visible. So in UEZ's example, if I add "GUISetBkColor(0x000000, $hGUI)" I don't see the black background I'd expect to see. I've been trying to work my way through the code and understand what it's doing, but I'm coming up with a few blanks. How can I have a semi-transparent image on top of the GUI, but still be able to see the GUI background? Thanks!

I'm having problems getting my brain to work, and I can't find anything to help me get moving on the web - so I was hoping someone here could nudge me in the right direction. I'm trying to be able to change the opacity of a bitmap using GDI+ (the source files are all .PNG). So at times it's fully opaque, and others it's faded out. Below is a sample bit of code. How can I get the bitmap to look semi-transparent? Thanks! #include <GUIConstantsEx.au3> #include <GDIPlus.au3> #include <GUIConstants.au3> #include <ColorConstantS.au3> #include <WinAPIGdi.au3> #include <WindowsConstants.au3> AutoItSetOption("MustDeclareVars", 1) _GDIPlus_Startup() Local $hGUI = GUICreate("test", 400, 300, -1, -1, $WS_POPUP, $WS_EX_LAYERED) GUISetBkColor(0x000000, $hGUI) Local $hImage = _GDIPlus_ImageLoadFromFile("AnyPNGFile.png") Local $iWidth = _GDIPlus_ImageGetWidth($hImage) Local $iHeight = _GDIPlus_ImageGetHeight($hImage) Local $hBitmap = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hImage) ; how can I dynamically change the opacity of the bitmap? Local $hPicCtrl = GUICtrlCreatePic("", 0, 0, $iWidth, $iHeight) _SetBitmapToCtrl($hPicCtrl, $hBitmap) GUICtrlSetState ($hPicCtrl, $GUI_SHOW) GUISetState(@SW_SHOW, $hGUI) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE _GDIPlus_Shutdown() Exit EndSwitch WEnd Func _SetBitmapToCtrl($CtrlId, $hBitmap) Local Const $STM_SETIMAGE = 0x0172 Local Const $IMAGE_BITMAP = 0 Local Const $SS_BITMAP = 0xE Local Const $GWL_STYLE = -16 Local $hWnd = GUICtrlGetHandle($CtrlId) If $hWnd = 0 Then Return SetError(1, 0, 0) ; set SS_BITMAP style to control Local $oldStyle = DllCall("user32.dll", "long", "GetWindowLong", "hwnd", $hWnd, "int", $GWL_STYLE) If @error Then Return SetError(2, 0, 0) DllCall("user32.dll", "long", "SetWindowLong", "hwnd", $hWnd, "int", $GWL_STYLE, "long", BitOR($oldStyle[0], $SS_BITMAP)) If @error Then Return SetError(3, 0, 0) Local $oldBmp = DllCall("user32.dll", "hwnd", "SendMessage", "hwnd", $hWnd, "int", $STM_SETIMAGE, "int", $IMAGE_BITMAP, "int", $hBitmap) If @error Then Return SetError(4, 0, 0) If $oldBmp[0] <> 0 Then _WinAPI_DeleteObject($oldBmp[0]) Return 1 EndFunc

I can change the value and such just fine. And the code works just fine on one test machine running Windows PE (and my older code has run on several hundred instances of Windows PE without a hiccup). It just seems to blow up on another, newer test PC running the exact same 64-bit Windows PE environment (32-bit seems to be just fine on both machines). If I compile with an older version of Autoit, it works just fine on both machines. So just getting a success on a single machine isn't an indicator that the x64 compiled code is working. Sorry, all I can say is that to me, this seems to point at either the hardware or Autoit as being the culprit. I'm functioning fine after dropping back to the older Autoit, so I just wanted to share the above for anyone else experiencing weirdness too. And if anyone has any ideas they want me to try, I'm happy to do so.

After doing more tests, it seems that the AD UDF is fine, but there's a bug or something when using Autoit 3.3.14.2 with SciTE 3.6.0 that only shows up in a specific scenarios/machines. I went back and compiled my test code with an older version of Autoit and SciTE and it worked just fine: https://www.autoitscript.com/forum/topic/178622-odd-math-results/ So thanks Water for helping me at least get to the bottom of the weirdness! Guess I'll just stick with compiling with older AutoIt for the time being...

czardas, the code in my first post IS the code that causes the error. And yes, I know it's aggravating and seems odd that it blows up - it works on one machine, but not another. I went back and did more tests and think this is some sort of bug with using Autoit 3.3.14.2 with SciTE 3.6.0. If I compile that same code from my first post using AutoIt 3.3.12.0 with SciTE 3.4.4 it works just fine with no errors.

The error message that pops up is: TITLE: AutoIt v3: Test.exe - Application Error MESSAGE: The exception Illegal Instruction An attempt was made to execute an illegal instruction. (0xc000001d) occurred in the application at location 0x00007FF6CE279FD1. Click OK to terminate the program

I'm hoping someone can shed some light on something for me... I've got a larger block of code that is hiccupping, and I narrowed it down to what seems to be an offending piece of math. If I compile the following code for x64, and I run it under 64-bit Windows PE, it works just fine on a Dell OptiPlex 980. However, if I boot up into the exact same 64-bit Windows PE environment on a new Dell OptiPlex 7020, it causes an illegal exception. What gives? Is there some sort of hardware, RAM, or BIOS setting that makes the math not work out, or spit out some odd integer that the message box can't handle or something? I'm weak on high level math, so maybe I'm overlooking something obvious? Can anyone help shed some light on this? Thanks! #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Outfile_x64=Test.exe #AutoIt3Wrapper_UseX64=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** Global $iHigh = 669650608 * 2 ^ 32 MsgBox(64, "testing", $iHigh)I'm using Autoit 3.3.14.2 with SciTE 3.6.0

Man, this is driving me nuts... So if I compile the following code as x64, it blows up in my 64-bit Windows PE environment: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Outfile_x64=Test.exe #AutoIt3Wrapper_UseX64=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** Global $iHigh = 669650608 * 2 ^ 32 MsgBox(64, "testing", $iHigh)I basically, snagged the numbers from my main script when it was blowing up and just plopped that number down: $iResultLow + $iResultHigh = 669650608 Any idea what this means? Or how I can maybe get around whatever is causing this?

No, if I compile that code as: Global $iHigh = 0 * 2 ^ 32 MsgBox(64, "testing", $iHigh)in a standalone x64 executable, it works just fine in my 64-bit Windows PE environment and spits out "0". BUT if I edit the __AD_LargeInt2Double function and plop in this bit of code at the top, it blows up: Local $iResultLow, $iResultHigh MsgBox(64, "testing", "testing next line...") Local $iHighTest = 0 * 2 ^ 32 MsgBox(64, "testing", $iHighTest)And I tried adding that code to another area of my main script (so it wasn't in your "AD.au3" script file) and it blew up there too. So I'm totally confused now as to what may be going wrong. Any ideas?

While my grasp on higher math and the variety of integers is weak, it seems that my current problem with the __AD_LargeInt2Double function is when the $iHigh value is zero. So would it make sense to add this code snippet to the first part of that function? If $iHigh = 0 Then Return $iLow EndIfWould that still return the desired result for the calls made to this function?

I'm running Autoit 3.3.14.2 and SciTE 3.6.0

Hmm good question. Don't know why I didn't tweak the function to test the final math in the first place. Soooo.. In the __AD_LargeInt2Double function I changed the last few lines to this: .... EndIf MsgBox(64, "test", "test the final math") $iValue_Test = $iResultLow + $iResultHigh * 2 ^ 32 MsgBox(64, "test", "returning") Return $iValue_Testand it causes an illegal instruction error on this line: $iValue_Test = $iResultLow + $iResultHigh * 2 ^ 32 (my MsgBox about "returning" doesn't display) So it doesn't like something about that equation. Suggestions?

If I compile for x86 and run under 32-bit Windows PE, it works just fine. I have to use 64-bit executables in 64-bit Windows PE (no 32-bit subsystem on the PE version I'm using). I did some more quick testing, and if I tweak the __AD_LargeInt2Double function to this: Func __AD_LargeInt2Double($iLow, $iHigh) Local $iResultLow, $iResultHigh If $iLow < 0 Then $iResultLow = 2 ^ 32 + $iLow Else MsgBox(64, "test", $iLow) $iResultLow = $iLow EndIf If $iHigh < 0 Then $iResultHigh = 2 ^ 32 + $iHigh Else MsgBox(64, "test", $iHigh) $iResultHigh = $iHigh EndIf MsgBox(64, "test", "returning") Return $iResultLow + $iResultHigh * 2 ^ 32 EndFunc ;==>__AD_LargeInt2Doubleit spits out "669650608" and "0", and then crashes when it returns to the _AD_GetObjectProperties function - when running as a compiled x64 executable. My grasp of converting integers isn't that great, so not sure if that helps or not. Ideas? Suggestions?

I compiled as x64.

I realize that this isn't probably the ideal environment for this UDF, but... I'm running into an odd issue when running things within 64-bit Windows PE on a brand new Dell OptiPlex machine with an SSD. For some reason, I get an illegal exception error on this line within the AD UDF in my compiled executable: $aObjectProperties[$iCount3][1] = __AD_LargeInt2Double($vPropertyValue.LargeInteger.LowPart, $vPropertyValue.LargeInteger.HighPart) If I slap in a few MsgBox statements, I can see that it seems to blow up when returning from the "__AD_LargeInt2Double" function. I just don't understand why. And it doesn't happen all of the time. Maybe 7 out of 10 times. Oh, and I've snagged the latest version of the AD UDF and am using the latest (non-beta) versions of Autoit and SciTE. Can anyone shed some light on this and maybe point me in a direction to do more research? Thanks!

I've got a 64-bit Windows PE image (that doesn't have the ADSI plugin installed), and I was wondering if there's an easy way to get Water's UDF to work (version 1.4.2.0) so I can communicate with Active Directory from within it? The AdFind.exe utility from Joeware works on my 32-bit WinPE image (so I know it's possible to connect to AD), but since that's only 32-bit it's not filling the void for me in my 64-bit WinPE environment. Oh, and my Autoit code works just fine in a full OS of course (or even a WinPE image with the old ADSI plugin) - just not in this slimmed down, ADSI-less, 64-bit WinPE image. Anyone run into this type of scenario and can shed some light on how I can stick with just pure Autoit code? $iResult = _AD_Open($sAccountName, $sAccountPassword, $sDNSDomain, $sPrimaryDomainControllerFQDN, $sConfiguration, $iUseSSL) Returns 0 @‌error = 2 @‌extended = -2147221005 Thanks! P.S. I'm still sort of new to Autoit, so maybe I'm overlooking something obvious...

Thanks for the code adjustment! It looks to give me the code I need to wrangle with. As for why I want it... I'm adding some buttons that won't normally be used, but that I still want available. So think 1 image instead of 2 in the example you posted. Default = 50%, Hover = 100%, and Pressed = 0%.