
SlowCoder74
Active Members-
Posts
178 -
Joined
-
Last visited
-
Days Won
1
SlowCoder74 last won the day on December 22 2012
SlowCoder74 had the most liked content!
SlowCoder74's Achievements

Prodigy (4/7)
6
Reputation
-
SlowCoder74 reacted to a post in a topic: Find Display Resolution
-
Another late entry ... Chimaera, thank you for your research into the descriptions! I will add to your rep points. I guess there's no way to retrieve this type of information via dll call. I will be adding this into my library.
-
SlowCoder74 reacted to a post in a topic: WinGetTrans not always working?
-
WinGetTrans not always working?
SlowCoder74 replied to SlowCoder74's topic in AutoIt General Help and Support
Alright. Well, I'm gonna role with it. My project code verifies the window exists before checking the transparency. So I modified it so that if it receives -1 from _WinGetTrans(), then it pretends to be 255. It's working well, so I'm happy. But I would still like to know why the alternating values, if anyone is able to come up with an explanation. -
WinGetTrans not always working?
SlowCoder74 replied to SlowCoder74's topic in AutoIt General Help and Support
So you can replicate my issue. What do you suppose would be the cause? -
WinGetTrans not always working?
SlowCoder74 replied to SlowCoder74's topic in AutoIt General Help and Support
I'm not talking specifically of your code. I'm talking about the inconsistent return values when the code I showed in post 4 is executed multiple times, without changing anything. Steps to reproduce: 1. Open a blank Notepad window. 2. Paste the code in post 4 to Scite and run multiple times. As is, with the WinSetTrans() at 254, it the value returned from _WinGetTrans() is consistently returned as 254. 3. Change the WinSetTrans() to 255, and run multiple times. At 255, I get -1 and 255 alternately returned to me each time I run. Seems to me, the code should consistently error, or provide the same result every time. Not the case here. This is why, either my assumptions about setting transparency are incorrect, or there is a bug in the dll call, or WinSetTrans(). -
WinGetTrans not always working?
SlowCoder74 replied to SlowCoder74's topic in AutoIt General Help and Support
I think I figured out the the bug ... Take this code: Func _WinGetTrans($iHwnd) Local $val = DllStructCreate("int") Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $iHwnd, "ulong_ptr", 0, "int_ptr", DllStructGetPtr($val), "ulong_ptr", 0) If @error Or Not $aRet[0] Then Return -1 Return DllStructGetData($val, 1) EndFunc $hWnd = WinGetHandle("Untitled - Notepad") WinSetTrans($hWnd,"",254) MsgBox(0,"",_WinGetTrans($hWnd)) If I use WinSetTrans($hWnd,"",255), the return value seems to alternate between 255 and the error code (-1) each time I execute. Any other transparency value seems to return the value normally. Simply setting the trans value to 254 allows my project to run as expected. Is this a bug in AutoIt's WinSetTrans() function, or the dllcall? -
WinGetTrans not always working?
SlowCoder74 replied to SlowCoder74's topic in AutoIt General Help and Support
@InunoTaishou, That's a no-go. It sees the window (provides handle), but the values are N/A and false, respectively. At the same time, my following test code is working, returning 128: Func _WinGetTrans($iHwnd) Local $val = DllStructCreate("int") Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $iHwnd, "ulong_ptr", 0, "int_ptr", DllStructGetPtr($val), "ulong_ptr", 0) If @error Or Not $aRet[0] Then Return -1 Return DllStructGetData($val, 1) EndFunc $hWnd = WinGetHandle("Untitled - Notepad") WinSetTrans($hWnd,"",128) MsgBox(0,"",_WinGetTrans($hWnd)) -
I'm working with the code found on page If I open an application window, e.g. "Untitled - Notepad", and use the code, I get an expected transparency value. But when I attempt to implement the code in a project, passing a window handle to it, it doesn't pick it up. Within the function I verified the window handle is passed correctly, and that the associated window still exists (WinExists()). I also verified the dllcall is not @erroring. It looks like the Not $aRet[0] is where it's dying, so the data isn't being returned by dllcall. Since the code does work in testing, what might lead up to the dllcall failing in some circumstances? My project does involve updating windows' states, such as minimize, normal, and transparency. Edit: Adding the code I'm testing with: Func WinGetTrans($iHwnd) if Not WinExists($iHwnd) then msgbox(0,"WinExists - " & $iHwnd, "not exist") ; testing Local $val = DllStructCreate("int") Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $iHwnd, "ulong_ptr", 0, "int_ptr", DllStructGetPtr($val), "ulong_ptr", 0) If @error Or Not $aRet[0] Then Return -1 Return DllStructGetData($val, 1) EndFunc
-
Doesn't look like there's a lot of info on the board for this, so ... Here's my code snippet: $sEmailFrom = "myemail@here.com" $sEmailTo = "goingto@somewhereelse.com" $sEmailSubject = "test" Local $oEmail = ObjCreate("CDO.Message") With $oEmail .From = $sEmailFrom .To = $sEmailTo .Subject = $sEmailSubject EndWithFor some reason, it results in "error: missing separator character before keyword" on the ".To = " line. This code was successfully compiling last August, and I haven't touched it since. I am currently using 3.3.12.
-
How to determine if computer is locked/unlocked?
SlowCoder74 replied to iXX's topic in AutoIt General Help and Support
I know this thread is a little old, but I'm concurring that guinness' example works for me, under Windows 7 64bit, running Autoit 3.3.12.0, as user GUI (no psexec). -
ISI360, this is wonderful! I'd heard about the project some time ago, but hadn't played with it. I've only done a cursory look so far, but it looks like an excellent IDE ... with the forms builder included! Thank you for your hard work.
- 995 replies
-
- isn autoit studio
- isn
-
(and 3 more)
Tagged with:
-
Melba, I would expect nothing less than a near-instant reply from you. The bug report you linked only seems to cite GUICtrlSetBkColor(), not GUICtrlSetColor(). Is GUICtrlSetColor() also affected in the same scope? (I know that sounds like a dumb question, as I'm having problems with it, but one can never be too sure.)
-
I spent quite a while trying to figure out why I couldn't set an icon to my button, using BrewManNH's sample below. Then I decided to strip the code until I determined why it wouldn't draw. I found that apparently _GUICtrlButton_SetImageList() doesn't work if GUICtrlSetColor() is used on the same control. BrewManNH's sample: My test code: #include <ButtonConstants.au3> #include <ComboConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <TabConstants.au3> #include <WindowsConstants.au3> #include <GuiButton.au3> #include <guiimagelist.au3> #Region ### START Koda GUI section ### $frmMain = GUICreate("", 730, 530, -1, -1) $btnClose = GUICtrlCreateButton("Close", 560, 472, 161, 24) GUICtrlSetFont(-1, 8, 800, 0, "MS Sans Serif") ;GUICtrlSetColor(-1, 0x800000) GUISetState() #EndRegion ### END Koda GUI section ### $hImage = _GUIImageList_Create(16, 16, 5) _GUIImageList_AddIcon($hImage, "Cancel.ico") _GUICtrlButton_SetImageList($btnClose, $hImage) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd Why is this a problem? Well, my project has buttons inside group controls. The group controls have the title text set in a different color. Since controls within the group controls take on the colors of their parents by default, I have to set the color of each child control individually. In doing that, _GUICtrlButton_SetImageList() breaks. Any ideas?
-
mLipok reacted to a post in a topic: YATCP (Yet another TCP) client/server UDF
-
Luigi reacted to a post in a topic: YATCP (Yet another TCP) client/server UDF
-
Computer name containing the running script
SlowCoder74 replied to Tippex's topic in AutoIt General Help and Support
I guess I'm a bit confused. Is it returning the mapped drive (e.g. X:blah)? If so, could you just use DriveMapGet("X:") to get the UNC resource path of the mapped drive? That should contain the server name, which you could then just parse out of the string. It works for me in Windows 7 and 2008. -
Returning to this after a while ... I was able to reproduce the problem. It appears to be related to moving/resizing using ControlMove. The code below creates an input control of a certain size/location. ControlMove moves and resizes the control. If you minimize and restore the window, you'll see that the control has reverted to it's original size/location. I'm using AutoIt 3.3.10.2 Update: More testing shows that if I add GUICtrlSetResizing($Input1, $GUI_DOCKALL) AFTER the ControlMove it will retain the new size/location. #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> Opt("GUIResizeMode",$GUI_DOCKALL) ;prevent moving of controls when resizing window #Region ### START Koda GUI section ### Form= $Form1 = GUICreate("Form1", 231, 182, 309, 270) $Input1 = GUICtrlCreateInput("Input1", 8, 8, 145, 21) GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### ControlMove($Form1,"",$Input1,16,16,150,30) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd