Habland0

I would say that UDF is superseded by

This is what I want to achieve: If I assign negative coordinates to MyLabel1 so it gets positioned in the upper menu, it gets hidden behind the menubar. How can I put it "on top"?

Caret to start: _GUICtrlEdit_SetSel($hEdit, 0, 0) Caret to end: _GUICtrlEdit_SetSel($hEdit, 0, -1) _GUICtrlEdit_SetSel($hEdit, -1, -1) ; Deselect

Pretty clever workaround by removing the forced attributes and then @SW_SHOW it anyway. I suppose this way Windows still assumes the control is not visible and therefor no focus stealing occurs. Smashing Edit: does have the drawback that the RichEdit control loses the ability to autoscroll or show any scrollbars (even when the required styles are added). Nevertheless, thanks for enlightening me on this issue. It's great to see different approaches.

This is what I have trouble with replicating. When I execute this line on the text in my first example: _GUICtrlEdit_SetSel($hEdit, 158, 158) The caret is positioned before the letter "b". If I then press the left arrow key, the caret jumps to "a", whilst the right arrow key positions the caret in front of "c", just as you would expect. The same with: _GUICtrlEdit_InsertText($hEdit, " HELLO ", 60) This places the caret after the inserted text (" HELLO "). If you want to move it in front of the inserted text, simply execute another SetSel like this: _GUICtrlEdit_InsertText($hEdit, " HELLO ", 60) _GUICtrlEdit_SetSel($hEdit, 60, 60) Can you confirm that this behaviour is the same at your end? Because in none of the cases described above does the caret ever jump to the end of the text when I'm using the arrow keys to navigate.

Executing this sequence on script start works to prevent focus stealing by _GUICtrlRichEdit_AppendText(), but it's dirty. GUISetState(@SW_SHOW) GUISetState(@SW_MINIMIZE) GUISetState(@SW_RESTORE)

This example script jumps the caret to an arbitrary position in the text and inserts a string. #include <GuiEdit.au3> #include <GuiStatusBar.au3> #include <GuiConstantsEx.au3> #include <WindowsConstants.au3> _Main() Func _Main() Local $hEdit, $hGUI ; Create GUI $hGUI = GUICreate("Edit Set Sel", 400, 300) $hEdit = GUICtrlCreateEdit("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz", 2, 2, 394, 268, BitOR($ES_WANTRETURN, $WS_VSCROLL)) GUISetState() Sleep(3000) _GUICtrlEdit_SetSel($hEdit, 158, 158) Sleep(3000) _GUICtrlEdit_InsertText($hEdit, " HELLO ", 60) Do Until GUIGetMsg() = $GUI_EVENT_CLOSE GUIDelete() EndFunc ;==>_Main

I am writing text to a RichEdit control using _GUICtrlRichEdit_AppendText(). If my script currently doesn't have focus, the next call to_GUICtrlRichEdit_AppendText() causes the script to steal focus. However, if I then switch to another app again (thus causing my script to lose focus), the problem no longer occurs and any subsequent calls to _GUICtrlRichEdit_AppendText() are silently written to the RichEdit control. How can I make it so _GUICtrlRichEdit_AppendText() never steals focus in the first place? For fun I even set the window to @SW_HIDE and it still stole focus when I invoked _GUICtrlRichEdit_AppendText() Here is a script you can compile to quickly test it yourself: #include <GuiRichEdit.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> Global $hGui, $hRichEdit, $iMsg $hGui = GUICreate("Example (" & StringTrimRight(@ScriptName,4) &")", 320, 350, -1, -1) $hRichEdit = _GUICtrlRichEdit_Create($hGui, "", 10, 10, 300, 220, _ BitOR($ES_MULTILINE, $WS_VSCROLL, $ES_AUTOVSCROLL)) GUISetState() For $i = 0 To 5 _GUICtrlRichEdit_AppendText($hRichEdit, @CR & "Switch to another application and wait 5 seconds...") Sleep(5000) Next

I have found a solution for this. By calling the ShowScrollBar function in user32.dll. It must be called after each ListViewItem creation, else the window's default settings (i.e. no scrollbar) are restored. It causes some minor flickering though. DllCall("user32.dll", "bool", "ShowScrollBar", "hwnd", $hwnd, "int", $SB_VERT, "int", True) DllCall("user32.dll", "bool", "EnableScrollBar", "hwnd", $hwnd, "uint", $SB_VERT, "uint", $ESB_DISABLE_BOTH) EnableScrollBar function is used to disable the scrollbar. These functions can also be accessed through the GuiScrollBars UDF.

That'd be my last resort, but if there is a cleaner way to do it then I'm very interested to hear it.

#Include <GuiComboBox.au3> _GUICtrlComboBox_DeleteString($GUI[1], 1) ; Remove item 2

1. Is it possible to allow a selected ListView item to be copied to the clipboard when the user presses CTRL+C? 2. Does an equivalent of $LBS_DISABLENOSCROLL exist for ListView controls? (Shows a disabled vertical scroll bar for the list box when the box does not contain enough items to scroll.) 3. Items in the ListView can be dragged and there seems to be no flag to disable that behavior. I have managed to disable dragging by looking for the WM_NOTIFY $LVN_BEGINDRAG code and then issuing a MouseClick(Left), which immediately stops the drag, but this is obviously a dirty solution. Thanks!

I was reading that section this afternoon. It must have completely slipped my gaze, because I don't recall reading anything about dealing with booleans. I just looked it up again and found it immediately - thank you.

What is the most efficient manner of flipping a bool? Here is the shortest way I can think of: If $bool Then $bool = False Else $bool = True EndIf However some programming languages allow: $bool = !$bool (i.e. True = Not True, False = Not False) Is anything like this single line approach possible in AutoIt?