SlowCoder74

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.

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.

So you can replicate my issue. What do you suppose would be the cause?

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().

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?

@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 = "[email protected]" $sEmailTo = "[email protected]" $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.

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.

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?

I was thinking it is a problem in the ControlMove function, as you said. I'm not sure why I used ControlMove instead of GUICtrlSetPos. Probably looked up how to move/resize, and that's what came up first.

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  

Thanks for your input guys. I definitely understand your stance on the subject. I am currently using AutoIt via Wine for development on my Linux machine at home. If it's for work, I take the code to work on Windows for testing. Since it was written on a cross-platform language, at least some of the functions should work on both platforms. I guess, keep in mind, that I'm not typically using it as a utility, like AutoHotKey, so some of the lower-level functions aren't necessarily needed. I'm using it at work for developing full-fledged applications, and at home, I'm developing graphical games.

I am self-teaching myself C++, due to its cross-platform portability between Windows/Linux, and C#, because it is the standard at my work. Let me tell ya ... * brain explodes *. Anyway, I believe AutoIt is coded in C++, right? Have you guys considered porting it over to Linux? I understand that AutoIt used to be open-source, but was changed to closed-source due to a disagreement with the devs of AutoHotKey. That's really too bad.

Yeah, I'd been adjusting the sleep throughout the dev/troubleshooting process. 50 is very high, and I settled on 10. I took your suggestion and wrapped the message management code into a do...until $nmsg = 0 loop, and it's working much better. Really, that's something I should have been able to come up with on my own, but sometimes I think things more complicated than they really are. Thanks for bringing me back to Earth.

Funkey, that was exactly what I was looking for. Thank you.

Looks good, and seems to work. I was of the understanding that Opt commands are set at compile time, and cannot be enabled/disabled multiple times throughout a program. For instance, I'm betting that since Opt("GUIOnEventMode",1) call is the first one the compiler sees in the code, that option is stuck on, and not actually disabled by the subsequent Opt("GUIOnEventMode",0) calls.

This looks like a really neat project! I'm following ...

As part of one of my projects at work that needs TCP communication, I decided to build my own TCP server/client pair. I tried to build it so that it is fairly self-managed, easy to implement into network projects, and contains a lot of useful inbuilt metrics. Supported metrics (supported both server and client side): - Number of current connections - Client and server connection test - Bytes sent / received / processed - Packets sent / received / processed - Number of clients connected - Sockets / IP address / computer name - Connection timestamp / elapsed time - Last packet received timestamp / elapsed time - Last packet sent timestamp / elapsed time Functionality (on top of standard TCP functions): - Configurable to send an initial "connection packet" upon connection, client or server-side. - Connection keep-alive packets at specific intervals - "Stale" connection disconnects for old, idle connections - Selective client broadcasting. On the server, clients can be individually selected to rebroadcast data received from them. - Automatic IP/socket/computer name detection - Connection state change detection. e.g. This facilitates updating a GUI connection list when clients have connected or disconnected. I would appreciate your constructive comments and suggestions. I am including the UDF, and sample server and client. Routines_TCP.au3 TCP Server.au3 TCP Client.au3

Yes, that is correct. I would like to know which local port is in use by the connected socket.

I'm going to go ahead and bump this, as it is exactly the same question I was going to ask. I'd like to know how I can retrieve the client's port.

Thank you. From reading those, it sounds like it was designed to act internally like sleep(), or it was designed to pause for ACKs or something, which it doesn't do (bug). In either case, for my purposes, it appears to be useless.