Custom Query

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 3883)

Ticket Resolution Summary Owner Reporter
#3934 Completed _WinAPI_SetTimer TimerID must be nonzero Jpm KaFu
Description

"A nonzero timer identifier" should be added to the TimerID description in _WinAPI_SetTimer().

Otherwise if set to 0, the return value of the function is not the TimerID.

See also: https://www.autoitscript.com/forum/topic/209219-centered-fileopendialog-using-self-terminating-wm_timer-call/?do=findComment&comment=1509811

Maybe add a second example for this scenario without a callback function.

#include <GUIConstantsEx.au3>
#include <Misc.au3>
#include <WinAPISysWin.au3>
#include <WindowsConstants.au3>

Opt('TrayAutoPause', 0)

Global $g_iCount = 0
Local $iTimerID = 999

Local $hGUI = GUICreate("Example")
GUIRegisterMsg($WM_TIMER, "WM_TIMER")

$iTimerID = _WinAPI_SetTimer($hGUI, $iTimerID, 1000, 0)

Do
    Sleep(100)
Until _IsPressed('1B')

_WinAPI_KillTimer($hGUI, $iTimerID)


Func WM_TIMER($hWnd, $iMsg, $iwParam, $ilParam)
    #forceref $hWnd, $iMsg, $iwParam, $ilParam

    ConsoleWrite($g_iCount & @CRLF)
    $g_iCount += 1

    Return $GUI_RUNDEFMSG
EndFunc   ;==>WM_TIMER
#3932 Completed _WinAPI_GetRawInputData Helpfile Example Jpm KaFu
Description

Playing around with above example and wondering why nothing's happening I saw that the bitmap path do not work, when you test outside of installation dir.

Please replace

$g_ahPart[$i] = _WinAPI_LoadImage(0, @ScriptDir & '\Extras\Mice' & $i & '.bmp', $IMAGE_BITMAP, 0, 0, $LR_LOADFROMFILE)

with something like

$g_ahPart[$i] = _WinAPI_LoadImage(0, StringReplace(@AutoItExe, "autoit3.exe", "Examples\Helpfile") & '\Extras\Mice' & $i & '.bmp', $IMAGE_BITMAP, 0, 0, $LR_LOADFROMFILE)

or better path alternatives :).

Best Regards

#3930 No Bug DllStructs created in one scope gets dropped if chained with a function that returns a re-structured-by-pointer version of it AutoXenon
Description

Original thread: https://www.autoitscript.com/forum/topic/209074-dllstructs-created-in-one-scope-gets-dropped-if-chained-with-a-function-that-returns-a-re-structured-by-pointer-version-of-it

GUICreate('')
Local $unreliable_data, $reliable_data, $intermediate_ref, $labelunreliable = GUICtrlCreateLabel('',0,0,400,25), $labelreliable = GUICtrlCreateLabel('',0,30,400,25)
GUISetState()
HotKeySet('{esc}',quit)
While True
      $unreliable_data = parseStruct(createStruct())  ; struct technically goes out of scope, this saves a "slave struct" but the master struct gets dropped when it goes out of parseStruct's scope
      $intermediate_ref = createStruct()              ; struct scope gets transferred, this is a "master struct"
      $reliable_data = parseStruct($intermediate_ref) ; a "slave struct" of a master struct that is scoped here
      Sleep(100)                                      ; wait some time for garbage to get written into the freed memory 
      GUICtrlSetData($labelunreliable,DllStructGetData($unreliable_data,'msg'))
      GUICtrlSetData($labelreliable,DllStructGetData($reliable_data,'msg'))
WEnd


Func createStruct()
     Local $struct = DllStructCreate('char[16]')
     DllStructSetData($struct,1,'hello world')
     Return $struct
EndFunc

Func parseStruct($struct)
     Return DllStructCreate('char msg[16]',DllStructGetPtr($struct))
EndFunc

Func quit()
     Exit
EndFunc

The question is, should create-by-pointer structs count as valid references? I can imagine that if it is change to be so, it might cause headaches with ad-hoc throwaway "lens" structs unintentionally preventing the memory from being freed if the programmer is expecting it to not count as valid references. I guess it's up to you to decide on which tradeoff to pick.

Note: See TracQuery for help on using queries.