SlowCoder74

I appreciate everyone's input! I will look into the options. I admit, it's obvious I'm ignorant of all of AutoIT's tricks, but I'm learning. It's much more powerful than what I was led to believe when I first began using it. At this time, it is my most used programming tool, and I am using it to build many applications and tools at my work, including some that are rather large. It's much more than just a scripting language.

@Blinky, You are correct that I can check in the main loop. I was hoping for a more direct method, using a trigger to control the checks. @JLogan3o13, here's the sample that demonstrates my question: (And yes, it's using GuiCtrlCreateInput) #include <ButtonConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #Region ### START Koda GUI section ### Form= $Form2 = GUICreate("Form2", 171, 132, 234, 361) $Input1 = GUICtrlCreateInput("Input1", 16, 16, 145, 21) $Button1 = GUICtrlCreateButton("Button1", 48, 48, 65, 33) GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $Input1 msgbox(0,"","data entered") EndSwitch WEnd

I know I can validate entered data after the fact (e.g. user clicks Ok), but I'd like to prevent a user from entering invalid characters in the first place. Looks like GUIGetMsg() only triggers when the input box loses focus AND the text has been changed, but not just when the text has been changed. Ideas?

bump (10 days later)

Beautiful, guys! thank you!

My sample code: Opt("MouseCoordMode",2) #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> $frmWallboard=GUICreate("Wallboard", 1024, 768, 1, 1) GUISetState(@SW_SHOW) ; ... code for a bunch of dynamically created labels all over the screen ... $Label1 = GUICtrlCreateLabel("Label1", 0, 0, 500, 500) ;sample label ;*************************** ;*** DRAW OPTIONS BUTTON *** ;*************************** $btnOptions = GUICtrlCreateButton("Options", 8, 8, 81, 25) GUICtrlSetFont(-1, 8, 800, 0, "MS Sans Serif") GUICtrlSetColor(-1, 0x000080) GUICtrlSetState(-1, $GUI_HIDE) GUICtrlSetState(-1,$GUI_ONTOP) ;if remarked, button is visible, but nonresponsive. If not remarked, button works, but is invisible until clicked. $iOptionsBtnLeft = 8 $iOptionsBtnTop = 8 $iOptionsBtnWidth = 81 $iOptionsBtnHeight = 25 $OptionsMenu = GUICtrlCreateContextMenu($btnOptions) $blah = GUICtrlCreateMenuItem("Minimize to taskbar",$OptionsMenu) ;*********************** ;*** MAIN EVENT LOOP *** ;*********************** While 1 ;GET GUI MESSAGES $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $btnOptions msgbox(0,"","You clicked the Options button") EndSwitch ;IS MOUSE OVER OPTIONS BUTTON? if MouseGetPos(0) >=$iOptionsBtnLeft and MouseGetPos(0) <= $iOptionsBtnLeft + $iOptionsBtnWidth and _ MouseGetPos(1) >=$iOptionsBtnTop and MouseGetPos(1) <= $iOptionsBtnTop + $iOptionsBtnHeight Then if ControlCommand($frmWallboard,"",$btnOptions,"IsVisible") = 0 Then GUICtrlSetState($btnOptions,$GUI_SHOW) ;GUICtrlSetState(-1,$GUI_ONTOP) EndIf Else if ControlCommand($frmWallboard,"",$btnOptions,"IsVisible") = 1 Then GUICtrlSetState($btnOptions,$GUI_HIDE) EndIf WEnd The button context menu works, as long as there is no label underneath. There are mixed results if the label is present. Note the comment I made about using GUICtrlSetState(-1,$GUI_ONTOP) in the code. Thanks.

It's great that the warnings appear in SCite to show where there are potential issues. There are times, however, when they get in the way of viewing my code. Is there a way to clear them? I don't necessarily want to disable them, but it would be nice to be able to reset them. That doesn't appear to be an option in the View menu.

Ah, not sure what I hadn't thought of that! I just used the ControlFocus() and that allowed it to work. You get a cookie!

I'd thought of creating a separate function like what you've proposed. But I would like to know why it isn't working in the first place.

heh ... yeah, it's just dummy data. Not actually pausing anything.

My test code: #NoTrayIcon Opt("TrayMenuMode", 1+2) ;remove 'script paused' and 'exit' from tray menu #include <ButtonConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #Region ### START Koda GUI section ### Form= $Form1 = GUICreate("Form1", 312, 222, 494, 647) $btnPause = GUICtrlCreateButton("Pause", 24, 16, 57, 25) GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### $TrayPause = TrayCreateItem("Pause") $TrayClose = TrayCreateItem("Close") TraySetState() local $bPaused = False While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $btnPause $bPaused = Not $bPaused if $bPaused = True Then GUICtrlSetData($btnPause,"Resume") Else GUICtrlSetData($btnPause,"Pause") EndIf EndSwitch ;GET TRAY MESSAGES $TrayMsg = TrayGetMsg() Switch $TrayMsg Case $TrayClose Exit Case $TrayPause ControlClick($Form1,"",$btnPause) EndSwitch WEnd When I click the Pause from the system tray menu, it does not toggle the pause button on the form. I'm unable to determine why. In one of the apps I'm developing, it will work the first time, but only once. I can click the button itself and it toggles as expected.

I know with the newest release came the ability to have 0-element arrays (yay!). It may be that documentation is just lagging behind a little, but in case it was missed ... _ArrayDelete documention (both installed and online) says: I did a quick check using the following code: #include <array.au3> Global $aMyArray[1] msgbox(0,"",UBound($aMyArray)) _ArrayDelete($aMyArray,0) msgbox(0,"",UBound($aMyArray)) and it appears that _ArrayDelete brings the array to 0 elements.

I actually already have the StringSize UDF, which thusfar I've used to determine the size of a label the would be created. Works nicely for that. Will now have to look into it for vertical centering. Thanks!

Using $SS_CENTERIMAGE allows me to vertically center the text in a label, but seems to disable multiline functionality. $SS_LEFT/RIGHT/CENTER seem to be ok. Is there a way I can combine vertical centering and multiline?

Yay! Yoohoo! Alright! Cheer! Forcing nonempty arrays has been one of the very few banes of my AutoIT experience! Thank you for fixing that! Downloading the newest release now ...

Here's an issue I ran into with _ArrayAdd. Maybe not problem so much, but something I thought needed a workaround ... #include <Array.au3> local $aMyArray[1] _ArrayAdd($aMyArray,"blah") Since you can't create an array with 0 elements in AutoIT, using _ArrayAdd in this fashion completely ignores the first element. I built my own version that does not, and I believe it conforms more with intended AutoIT array usage. Func _ArrayAddValue(ByRef $aArray,$sValue = "") ;adds an element (redim) to 1D array, and assigns value to it ;if a non-array variable is provided, it will be converted (original data lost) to array, with value assigned to element [0] ;$aArray - array to add element and value to ;$sValue - value to assign to added element local $bIsNewArray = False if Not IsArray($aArray) Then ;create array Dim $aArray[1] $bIsNewArray = True EndIf if $bIsNewArray = False then ReDim $aArray[UBound($aArray) + 1] $aArray[UBound($aArray) - 1] = $sValue EndFunc New version of calling code would look like: local $aMyArray _ArrayAddValue($aMyArray,"blah") Note that the newly initialized variable is NOT initially an array, which allows the _ArrayAddValue to add a value to the [0] element. Thoughts?

Well, I never actually had to change anything. The issue (if it existed in the first place) seems to have disappeared. Thank you!

Yep, that's right. When I execute this simple IF statement, it comes out true! if 0 = "FFFFFF" then msgbox(0,"","same") As expected, issuing if 0 = "0" then msgbox(0,"","same") comes out true. But if 0 = "1" then msgbox(0,"","same") if 1 = "FFFFFF" then msgbox(0,"","same") are both false. If I understand AutoIT's variable typing system, numbers (e.g. 1 without quotes) can be compared to numeric strings (e.g. "1" with quotes) and come out true. But how is 0 = "FFFFFF"? I missed something, right?

I appreciate the way AutoIT handles errors. If a function fails, it's basically the same as "on error ... resume next". Very nice. But watch out! In some cases you may not know where a point of failure is due to AutoIT's internal error handling. So you want to use @error for critical function calls to catch those errors.

Let me just punch that into my test app and see what happens ... ... tickety clickety click ... Ok, that doesn't make the window topmost. I can drag the window underneath other topmost windows.

I am writing another utility for my job that pulls data from a server and displays it on agent desktops. It is critical that the information window remain on top of all other windows, including other windows that want to fight for "top position". I placed my WinSetOnTop within my main loop. It works nicely for me, 0 issues. However, some of the agents have mentioned that since I deployed in beta, focus from their other application windows seems to get stolen. Strange thing is it only seems to happen every once in a while. Anyone have any ideas about this?

No problem. I appreciate your listening, and I understand your responses. Thanks!

No, I haven't read the beta help. I prefer to work in the current release, and allow others to find the bugs. I don't think the code is strictly unreadable, as by breaking out the number values (1+2+4), they can be viewed in the command help by pressing F1. The variables, however, are not as easily found. Yes! This means you do intend to include the variables in the flag lists/remarks of the next help version? I agree. Everyone has their own methods for doing things, and I think I follow most principles pretty well. I'm not expecting any great changes to the BCP with my name in lights, just consideration for alternate methods of doing things, depending on circumstances. In the end, I try to be contributory to forums to which I visit. Kind of hard here, where everyone has thought of everything already.

Good morning all! I was perusing through your BCP. I wanted to make a comment about the Magic Numbers portion. I agree that giving values a "name" via a variable often helps to identify the meaning. But I'd also like to add that I very often have lines that may embed multiple or long functions, and I actually find it easier to use the number+number+number method, rather than using the actual variables, to save space. I'll use msgbox as an example: iVar = msgbox(3+16,"title","my message") which says I want "Yes, No, Cancel" buttons, and a stop sign icon. If I forget what 3 and 16 are, I can just pull up msgbox in help to quickly find them. It's great that you have the representative variables, but it would be nice to see them listed on the help pages for those of use who prefer to use them.

Ok, there were 2 problems with my code, then. I didn't understand that it was looking for the value of the element. And based on that lack of understanding, I was misinterpreting the parameters of the _IEFormElementRadioSelect command. Thank you, everyone, for your help!