Timeline
Dec 22, 2016:
- 6:35 PM Ticket #3521 (Au3Check is not able to recognize Global variables declared inside ...) updated by
-
Replying to TheDcoder <TheDcoder@…>:
> I know that it is not unintentional but Au3Check should be able to detect such situations... There are times when you have to declare
Globalvariables inside functions, something like GUI_CreateMainWindow. Show example on the forum, and there we can discuss - 5:06 PM Ticket #3521 (Au3Check is not able to recognize Global variables declared inside ...) updated by
-
I know that it is not unintentional but Au3Check should be able to detect such situations... There are times when you have to declare
Globalvariables inside functions, something like GUI_CreateMainWindow. - 1:24 PM Ticket #2833 (macro @funcname) updated by
- Zinthose, I think you misunderstood the request or you're trying to implement it in the worst way possible. What the request is asking for is to have a macro that tells you the currently executing function, which I don't think would be at all useful because it's just as easy to include a variable set to the name of the function to do exactly the same thing, but would require a coder to have to think for themselves. Your request is trying to rerun the current function. I'm not sure of what you think you're attempting, but I don't see that as a smart way to do it.
- 1:16 PM Ticket #3521 (Au3Check is not able to recognize Global variables declared inside ...) closed by
- No Bug: This isn't a bug but poor programming. Au3Check reads the script line by line from the first line to the last. It doesn't execute the script. Because you're trying to access a global variable that hasn't been declared yet (at that point in the script read), you get an error.
- 11:01 AM Ticket #3521 (Au3Check is not able to recognize Global variables declared inside ...) created by
- Au3Check is not able to recognise Global variables declared inside …
Dec 21, 2016:
- 11:29 AM Ticket #2833 (macro @funcname) updated by
- If this is ever considered for actual implementation I believe that a macro @CallStack would be even more useful, returning an array of functions called in decreasing depth order (LIFO mode). If the associated overhead is going to block making that real, perhaps it's time to have an Opt() switching that on for those who need it.
- 6:41 AM Ticket #2833 (macro @funcname) updated by
- I'm surprised this hasn't been added yet. I'm working on some pretty insane deep nested functions and was trying to do something like This: […] This is to address an issue when resolving a variable name using Eval from a global array. The problem is any changes are saved to the local copy made with Eval and not the original variable from the global scope. I guess ideally I'd like to see Eval have a ByRef parameter to address my issue but I'd still like to see @FuncName implemented.
Dec 16, 2016:
- 10:29 PM Ticket #2580 (Aut2Exe failing to run multiple times on Windows XP prior to SP3) updated by
- Replying to anonymous: > ' > == == > 'babar ali virk
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
Note:
See TracTimeline
for information about the timeline view.
