Timeline



Mar 25, 2015:

11:08 PM Ticket #3004 (Anonymous Maps) updated by anonymous
OK, everything is clear now. Thank you clearing that up. Now that I've reread your posts with my refreshed perspective, I agree with all points.
10:45 PM Ticket #3004 (Anonymous Maps) updated by anonymous
Replying to jaberwacky: > I'm not exactly sure what you're saying with proposal 2 and 3. I'm saying that you're proposing three different things and that they should be considered separately. > Are you saying the idea is good but that the execution is bad? I think there were some problems and suggested possible refinements. Personally I support all three proposals. Replying to anonymous: > How does this make the language inconsistent? This only applies to maps and not arrays and not objects. Dot access does not imply object object orientation. I'm actually not trying to subtly sneak anything OO related into the language. I didn't even think about objects, they're a lost cause. I think that it's a bad idea to use one syntax for two different things: array and map creation. I don't like the current way to create a map: Local $map[] I'd prefer Local $map = {} or Local $map = Map () or Local $map = NewMap () or Local $map = @EmptyMap because they make it clear what is happening. But [] does not. Why should Local $array = [] (array initialization) and Local $map = ([]) (empty map expression) create different things?
4:51 PM Ticket #3004 (Anonymous Maps) updated by anonymous
Rewind... How does this make the language inconsistent? This only applies to maps and not arrays and not objects. Dot access does not imply object object orientation. I'm actually not trying to subtly sneak anything OO related into the language.
4:22 PM Ticket #3004 (Anonymous Maps) updated by jaberwacky
Replying to anonymous: > It makes AutoIt inconsistent and is not open for extensions. > Why not @EmptyMap? I'm not exactly sure what you're saying with proposal 2 and 3. Are you saying the idea is good but that the execution is bad? @EmptyMap Works for me.
1:22 PM Ticket #2831 (Function Binding) updated by anonymous
Replying to jchd18: This was closed because of a misunderstanding, please reopen.
1:13 PM Ticket #3004 (Anonymous Maps) updated by anonymous
Replying to jaberwacky: > As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error. It makes AutoIt inconsistent and is not open for extensions. Why not @EmptyMap?
5:21 AM Ticket #3004 (Anonymous Maps) updated by anonymous
Sorry for the double post.
5:20 AM Ticket #3004 (Anonymous Maps) updated by jaberwacky
As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error.
5:19 AM Ticket #3004 (Anonymous Maps) updated by jaberwacky
As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error.
12:41 AM Ticket #3004 (Anonymous Maps) updated by anonymous
This actually contains three proposals: 1. Allow maps as expressions in a "With" statement. Example: […] Maps and "Object-type variables" have the same syntax. That extension is only natural. 2. Create a shortcut for the expression in a With statement. Example: […] What about ..element? Saves at most one line, not intuitive, easy to miss, will confuse programmers and tools, strange semantics, might encourage overuse – probably a bad idea, but absolutely possible. [] is a bad idea, see point 3. .[] is really strange, probably hard to implement and makes you assume that $object is a map, althrough it may be an "Object-type variable". Maybe with an additional keyword or constant (@WithExpression). 3. Make [] the empty map. Example: […] Note that the parentheses in the third-last line are a necessary syntactic disambiguation. Without them, it would be a broken array initialization (see #2845), or ambiguous. The same is true for 2d array initializations. Again, this may save at most one line. It will confuse any programmer coming from any language where that is an expression for an empty array (JS, PHP, ...): they will use it thinking that it is an empty array, and will be legitimately surprised when their program breaks. Definitely a bad idea. Maybe with braces ({})?

Mar 24, 2015:

10:12 PM Ticket #3004 (Anonymous Maps) created by jaberwacky
So I have an idea which I think will make coding a little easier in …
12:38 PM Ticket #3003 (Using a function call in an array assignment causes 2 function calls) updated by jguinch
Also, this code is a good example of what happends : […]

Mar 23, 2015:

10:58 PM Ticket #3003 (Using a function call in an array assignment causes 2 function calls) created by jguinch
With this code : […] "myFunction" appears two times in the output …

Mar 22, 2015:

5:22 PM Ticket #2988 (_Excel_RangeFind fails without throwing error when searching inactive ...) updated by water
Fixed by revision [11253] in version: 3.3.13.21
5:21 PM Ticket #2988 (_Excel_RangeFind fails without throwing error when searching inactive ...) closed by water
Fixed: Fixed by revision [11252] in version: 3.3.13.21
5:07 PM Ticket #2993 (_Excel_RangeFind returns only last occurrence of string found Rather ...) closed by water
Fixed: Fixed by revision [11251] in version: 3.3.13.21
11:52 AM Ticket #3002 (Bug - _DateAdd('s', 1, '1970/01/01') Returns '1970/01/01') updated by jchd18
Oops, I never read the help file down to the last Remark line. BTW, this important remark about allowable date formats would be better placed in the $Date parameter description: "Input date in the format YYYY/MM/DD[ HH:MM:SS]" --> "Input date in any format described in _DateTimeSplit()". Sorry for the noise, but yes I still find it would be natural to expect the function to return dates under the same format used for input.
2:23 AM Ticket #3002 (Bug - _DateAdd('s', 1, '1970/01/01') Returns '1970/01/01') updated by guinness
jchd, It does accept - (see the StringSplit() in _DateTimeSplit() […] Unless you meant the output should be 2015-03-21 00:00:01 and not 2015/03/21 00:00:00
2:15 AM Ticket #2983 (_WinApi_GetString documentation error) closed by guinness
Fixed

Mar 21, 2015:

10:38 AM Milestone 3.3.13.20 completed
4:35 AM Ticket #3002 (Bug - _DateAdd('s', 1, '1970/01/01') Returns '1970/01/01') updated by jchd
I'm not sure this qualifies as 'bug' and I'd rather see this as a feature request, for when you supply a date only (without time), that doesn't always imply that you mean time = '00:00:00'. Yet commonly used library functions work the way to want and consider a default time part to be '00:00:00'. BTW if ever this is accepted, I'd like other would also consider another modification. Currently the function only works when the date separator is a slash (/), but the standard separator specified by ISO 8601 is a dash (-). It would be pretty beneficial to simply mask off the separator in the regexp, yet take care to use the same separator in output. […] The same change should be made to related _Date* functions, like _DateDiff and some others. The best witness that this change is indeed needed is that _DateIsValid accepts both separators! Note: I don't advocate to accept any more format variant described in ISO 8601.

Mar 20, 2015:

2:14 PM Ticket #3002 (Bug - _DateAdd('s', 1, '1970/01/01') Returns '1970/01/01') updated by mLipok
Modyfication I mean only by appropriate use this new internal function.
2:12 PM Ticket #3002 (Bug - _DateAdd('s', 1, '1970/01/01') Returns '1970/01/01') created by mLipok
Repro: […] solusion proposal: new internal function: […] …

Mar 19, 2015:

2:24 PM Image 028.png attached to Ticket #2481 by anonymous
Don't seen initial dir path in the dialog.

Mar 13, 2015:

5:29 PM Ticket #3000 (scriptline) updated by anonymous
Ok nevermind, looks like custom error handling won't be useful for me anyway. For me it returns -1, are you sure it is compiled script?

Mar 12, 2015:

2:03 PM Ticket #2988 (_Excel_RangeFind fails without throwing error when searching inactive ...) updated by water
Owner, Status changed
2:03 PM Ticket #2993 (_Excel_RangeFind returns only last occurrence of string found Rather ...) updated by water
Owner, Status changed
2:01 PM Ticket #2993 (_Excel_RangeFind returns only last occurrence of string found Rather ...) updated by water
The problem was caused by exiting the loop to search in the next sheet before increasing the index. Thus the first hit of the next sheet was overwriting the last hit of the previous sheet. This should work as well. Can you please confirm? […]
12:11 PM Ticket #2994 (Can't run _Excel_RangeFind example in 3.3.13.19) closed by water
Wont Fix: This is caused by the way AutoIt 3.3.13.19 handles COM errors. Up to 3.3.12.0 a COM error was returned by setting @error, with 3.3.13.19 the script crashes when you haven't set up a COM error handler. Up to 3.3.12.0 the script simply checked @error and then decided what to do. Now you need a COM error handler even when you wanted to ignore the error. I hope this change will be thought over before the release of the next production version. Now it is a huge overhead with little to none advantage compared to the "old" solution. The current Excel UDF in the repository has a COM error handler established for each function when called and dropped at the end.
9:04 AM Ticket #3000 (scriptline) updated by mLipok
in […] I use example from HelpFile and in Au3.3.10.2 and Au3.3.13.19 I get: […] And in helpFile you can read: @ScriptLineNumber Line number currently being executed. Useful for debug statements such as the calling line number for a function. (Not significant in compiled scripts) So it works but remember: "(Not significant in compiled scripts)" And this rule is also for ObjEvent.

Mar 11, 2015:

10:32 PM Ticket #2988 (_Excel_RangeFind fails without throwing error when searching inactive ...) updated by water
Component changed
10:31 PM Ticket #2993 (_Excel_RangeFind returns only last occurrence of string found Rather ...) updated by water
Component changed
10:02 PM Ticket #3000 (scriptline) updated by anonymous
I expect to return line number like in the default error message.
8:34 PM Ticket #3001 (Added AutoIt3x_64.dll to Excel Add-in list loads it as initial spreadsheet.) created by whittamr@…
Added AutoIt3x_64.dll to Excel Add-in list. Now the DLL loads as …
5:49 PM Ticket #3000 (scriptline) updated by mLipok
And what you are expect ? If you want to see a proper Line Number in compiled script then you must use Au3Stripper.exe […] btw. next time try to ask on the forum
10:32 AM Ticket #3000 (scriptline) updated by anonymous
[…] When I don't use my com error handler the script line number is returned in the error message even when the script is compiled.
9:14 AM Ticket #3000 (scriptline) updated by J-Paul Mesnage
not sure to understand can you a repro script Thanks
12:00 AM Ticket #3000 (scriptline) updated by TicketCleanup
Version changed
Automatic ticket cleanup.

Mar 10, 2015:

11:24 PM Ticket #3000 (scriptline) created by anonymous
When I don't set my own com error function and an error occurs the …
10:15 PM Ticket #2998 (Add key #03 to _IsPressed() in the Help file) closed by guinness
Completed: Added by revision [11236] in version: 3.3.13.20
10:08 PM Ticket #2986 (_GUICtrlListView_SetColumnOrderArray - typo in parameters description) closed by guinness
Fixed: Fixed by revision [11235] in version: 3.3.13.20

Mar 8, 2015:

10:29 AM Ticket #2996 (3.3.13.19 installer doesn't end-task file dependencies) closed by Jos
No Bug

Mar 6, 2015:

6:21 AM Ticket #2999 (FTP read fails because of exe file name and the path location) closed by J-Paul Mesnage
No Bug

Mar 5, 2015:

7:52 PM Ticket #2999 (FTP read fails because of exe file name and the path location) updated by TouchOdeath
Please disregard.. I had code that added a firewall block rule.. which makes perfect sense why renaming the filename was screwing me. woops
7:06 PM Ticket #2999 (FTP read fails because of exe file name and the path location) created by TouchOdeath
This is on Windows 7 Ultimate x64, if the file is named mtu.exe and it …
6:14 PM Ticket #2997 (Bug in PCRE) updated by jchd18
Yes it is. It also crept in PCRE2 (10.00 and 10.10RC2 exhibit the same bug). No doubt it will be fixed soon by Philip Hazel & co.
5:16 PM Ticket #2997 (Bug in PCRE) updated by J-Paul Mesnage
After a test 8.35 induce the regression if it is really a regression
5:00 PM Ticket #2998 (Add key #03 to _IsPressed() in the Help file) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
4:58 PM Ticket #2998 (Add key #03 to _IsPressed() in the Help file) created by Willichan <davidearlwilliams@…>
In the Help file, the listing of keys for _IsPressed() in the Misc.au3 …
4:23 PM Ticket #2997 (Bug in PCRE) updated by J-Paul Mesnage
In fact PCRE has been updated to 8.35 in 3.3.13.13 It can be related I will check
1:07 PM Ticket #2997 (Bug in PCRE) created by jchd18
A bug in recent releases of the PCRE library has been reported which …

Mar 3, 2015:

8:35 PM Ticket #2996 (3.3.13.19 installer doesn't end-task file dependencies) updated by Jos
We install the Beta in a fixed subdirectory of the production version for several reasons. No Bug and expected begaviour. When you don't like these defaults you can always download the ZIP version and do whatever you like as to where you locate ot as long as you don't complain about things not working. ;) As to the installer not being able to install a file on your D: disk, that has to be something on your installation as it is only trying to write a shortcut file. Jos
7:58 PM Ticket #2996 (3.3.13.19 installer doesn't end-task file dependencies) updated by jmichae3@…
I was using x64 tools as the choice.
7:57 PM Ticket #2996 (3.3.13.19 installer doesn't end-task file dependencies) created by jmichae3@…
1.install 3.3.8.1 into d:\autoit-3.3.8.1\ 2.install 3.3.13.19 into …

Feb 27, 2015:

5:37 PM Ticket #2995 (Create and pass array as parameter in the parameter itself) updated by Jos
This works fine already: […]
8:00 AM Ticket #2995 (Create and pass array as parameter in the parameter itself) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
7:44 AM Ticket #2995 (Create and pass array as parameter in the parameter itself) created by anonymous
Sorry for my English, I am using a translator. It would be very useful …

Feb 26, 2015:

3:10 AM Ticket #2994 (Can't run _Excel_RangeFind example in 3.3.13.19) created by BrewManNH
When you try to run any of the example scripts, from the help file for …

Feb 25, 2015:

11:25 PM Ticket #2993 (_Excel_RangeFind returns only last occurrence of string found Rather ...) created by ricrat51@…
It appears that the routine returns only the last occurrence of string …
10:09 PM Ticket #2628 (Add mode to StringRegExp) updated by MrCreatoR <mscreator@…>
Very good idea, or at least set @extended for flag 3, then we could calculate the position of each match in a loop (with StringLen).

Feb 24, 2015:

12:41 PM Ticket #2793 (SetError And SetExtended not integer value) updated by Melba23
Personally, I think this would be a good addition to the language. We are talking about @extended and not @error so I do not find the "MS numeric error code" argument particularly convincing. Being able to pass strings as well as numbers could be very useful. And Jon has only himself to blame for having implemented the FileFindNextFile @extended return in that way - if he had stuck to a numeric value (as is returned by the API) the question would not have arisen! M23
4:20 AM Ticket #2793 (SetError And SetExtended not integer value) updated by BrewManNH
Microsoft decided long ago that error codes would be numeric. No one seems to mind that, so I don't understand why you'd expect AutoIt to do something like this.
4:16 AM Ticket #2992 (Int, Dec, Number return incorrect results when used with binary and ...) closed by BrewManNH
No Bug

Feb 23, 2015:

4:11 PM Ticket #2992 (Int, Dec, Number return incorrect results when used with binary and ...) updated by BrewManNH
http://www.binaryconvert.com/result_double.html?hexadecimal=00000000000000FF You are doing it wrong.
1:58 PM Ticket #2992 (Int, Dec, Number return incorrect results when used with binary and ...) created by timsky
Forum bug report: …
Note: See TracTimeline for information about the timeline view.