Timeline
Dec 7, 2016:
- 5:02 PM Ticket #3520 (Unexpected parameter type limit of _GUICtrlTreeView_GetItemParam) updated by
- Replying to Jpm: > Can yo more precise on what should be change where(?). > the _GuiCtrlTreeview_* must work on ID when AutoIt builtin are used to create the item > and Hwnd when created by _GUICtrlTreeView_* are used Because treeview and items both may created by AutoIt internal functions or _GUICtrlTreeView_* functions, $hWnd and $hItem may be a handle or an ID. To supporting all 2*2=4 cases, _GUICtrlTreeView_* functions should consider their conversions independently. For example, _GUICtrlTreeView_GetFirstChild uses two if statements to adjust $hWnd and $hItem. However, _GUICtrlTreeView_GetItemParam returns False when $hWnd is an ID and $hItem is not an ID. I think it can ignore GUICtrlGetHandle failure, like the implementation in in _GUICtrlTreeView_GetItemHandle. By the way, _GUICtrlTreeView_GetParentParam has the same structure of code and the same problem.
Dec 5, 2016:
- 10:30 PM Ticket #3097 (AutoIt crash with Objects) updated by
- +? does using the 64bit compiler completely resolve this issue? "c:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe"
- 6:23 PM Ticket #3520 (Unexpected parameter type limit of _GUICtrlTreeView_GetItemParam) updated by
- Can yo more precise on what should be change where(?). the _GuiCtrlTreeview_* must work on ID when AutoIt builtin are used to create the item and Hwnd when created by _GUICtrlTreeView_* are used
Dec 4, 2016:
- 6:14 PM Ticket #3520 (Unexpected parameter type limit of _GUICtrlTreeView_GetItemParam) created by
- When $hWnd is not of type HWND (and $hItem is not 0), …
Dec 2, 2016:
- 10:01 PM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) closed by
- Fixed: Fixed by revision [11831] in version: 3.3.15.1
- 6:26 PM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) updated by
- I understand, The Function and the doc need to be fixed as passing @aParts[] and $aPartsWidth[] can be conflictual Definitly if no Parts, the widths must be sum up Not sure what to do with Widths not positive
- 5:04 PM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) updated by
- i do not have mach time left... […]
- 10:07 AM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) updated by
- I still don't undrstand just follow Ticket creation guidelines as I don't have a cristal ball to reproduce
- 10:05 AM Ticket #3519 (_GUICtrlStatusBar_SetText() - cannot set text to the last part, if it ...) closed by
- No Bug: So your definition is wrong it must be $StatusBar_PartsWidth[8]
- 4:22 AM Ticket #3519 (_GUICtrlStatusBar_SetText() - cannot set text to the last part, if it ...) updated by
- works: […] not works: […]
- 4:19 AM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) updated by
- Hi, I invented $cParts myself for purpose of countering bug in _GUICtrlStatusBar_SetParts(). Basically it calculates right edge of parts from parts width. on a side note - is may english so bad?
Dec 1, 2016:
- 7:36 AM Ticket #3519 (_GUICtrlStatusBar_SetText() - cannot set text to the last part, if it ...) updated by
- Please follow guidekines for writing a ticket as I cannot reproduce what you are saying with what you wrote
- 6:34 AM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) updated by
- Hi, I don't know where you get such $cParts has I cannot see any change in this area PLease use the standard Delivery or the beta
Nov 30, 2016:
- 5:51 PM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) closed by
- Fixed: Fixed by revision [11822] in version: 3.3.15.1
Nov 29, 2016:
- 4:11 PM Ticket #3519 (_GUICtrlStatusBar_SetText() - cannot set text to the last part, if it ...) created by
- function cannot set text to the last part, if it defined with "-1" in …
- 4:06 PM Ticket #3518 (_GUICtrlStatusBar_SetParts() - cannot set parts from $aPartWidth) created by
- As summary says - function cannot properly set parts based on width …
- 8:17 AM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) updated by
- Thanks, I was figuring out your pb. As thre is no way to be sure that input data can be decrypted if internal conversion is done during encryption. It is the user responsability do do it. I will change the doc to reflect what has to be done. see the following example to do the right handling […]
- 5:28 AM Ticket #3514 (Add a treeview UDF calling $TVGN_LASTVISIBLE) updated by
- Replying to TicketCleanup: > Automatic ticket cleanup. Even 3.3.15.0 doesn't support this function or something similar, too.
Nov 28, 2016:
- 9:14 PM Ticket #3517 (VLC .exe not working with Windows 10) closed by
- No Bug: This seems to be a support request, not a bug report, so please come to the forum and post your questions there. Jos
- 8:24 PM Ticket #3517 (VLC .exe not working with Windows 10) created by
- When trying to run VLC player exe with silent parameter Windows 10 …
- 8:14 PM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) updated by
- Replying to Jpm: > Can you provide a repro script so I can verify what should be done in the doc? > > Thanks Please run the code at the end of this comment. I do the same as the documentation, encrypting without explicit StringToBinary call and decrypting with BinaryToString using default encoding. My machine reports 59/56 for two lengths. Thanks! #include <Crypt.au3> #include <MsgBoxConstants.au3> $plaintext = "Hello! ជំរាបសួរ! Allô! Привет! 您好！مرحبا! હેલો! שלום! こんにちは！" $ciphertext = _Crypt_EncryptData($plaintext, "test", $CALG_RC4) $result = BinaryToString(_Crypt_DecryptData($ciphertext, "test", $CALG_RC4)) MsgBox($MB_OK, "Result", $result & @LF & _ "Length original: " & StringLen($plaintext) & @LF & _ "Length after decryption: " & StringLen($result))
Nov 26, 2016:
- 10:39 PM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) updated by
- Sidenote: strings really should be converted to UTF8 before encryption and back from UTF8 after decryption, so that portability is achieved in all use cases (non-codepage chars in plaintext string or different codepages between encryption and decryption machines). Maybe the doc should mention that and perhaps give a multi-lingual example (e.g. plaintext = "Hello! ជំរាបសួរ! Allô! Привет! 您好！مرحبا! હેલો! שלום! こんにちは！").
Nov 25, 2016:
- 3:45 PM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) updated by
-
Component changed
In fact the doc say implicitly that the parameters are variants ($v*) so it is the user responsability to give string or binary. I understand that for chinease "characters" it seems better to use Binary as the AutoIt strings (UCS2) is not enough to handle all Chinese "characters" Can you provide a repro script so I can verify what should be done in the doc? Thanks
Nov 21, 2016:
- 11:09 AM Ticket #3515 (Assigning directly a value to an element of an array in array) updated by
- It could be useful if the syntax: […] was accepted by Au3Check and correctly parsed by AutoIt3. In fact, it will be useless for simple arrays, but it will be fundamental for array in array. By now, the syntax […] is accepted only for reading values and this code returns the same error too: […]
Nov 20, 2016:
- 9:39 PM Ticket #3515 (Assigning directly a value to an element of an array in array) updated by
- That error comes from au3check, not autoit3. Don't think this format is supported anyways and doesn't work when ran without au3check. Jos
- 8:16 PM Ticket #3516 (Specify types of parameters of _Crypt_EncryptData) created by
- The input $vData and $vKey of _Crypt_EncryptData must be bytes rather …
- 10:20 AM Ticket #3515 (Assigning directly a value to an element of an array in array) created by
- If you want to assign a value to an element of an array contained in …
Note:
See TracTimeline
for information about the timeline view.
