Timeline
May 28, 2017:
- 8:56 PM Ticket #3552 (SciTE 3.7.3 bug: #Region & #EndRegion not working properly when it ...) updated by
- Lines starting with an # are ingnored by AutoIt3, so let's not make this more complex as it is. My reply merely stated why things are happening as experienced and didn't want to have/start a debate on code formatting in TRAC. :) Jos
- 8:17 PM Ticket #3552 (SciTE 3.7.3 bug: #Region & #EndRegion not working properly when it ...) updated by
- Try this: […] You will get: […] I know this is rather this case: […] But this is very strange to write anything else than Case in first line just after Switch. You must to agree with me that in this scenario #Region and #EndRegion are on different FoldingLevel. Also in this case: […] #Region and #EndRegion are on different Folding level and this could not be taken any way, this is just irrational. For me this is the same case: […] This is the same problem - different Folding Level. Would you accept this as a properly written code ?
- 7:52 PM Ticket #3552 (SciTE 3.7.3 bug: #Region & #EndRegion not working properly when it ...) updated by
- I would say there is basically nothing wrong with using it like that, but you need to remember that SciTE only does basic lexing and not syntax interpretation. In this case the Case statement will Close the previous Fold Header ( being a #region) en start a new Fold level, since that is what is needed for a Case line. So it is not a bug but agree it looks strange. Jos
- 6:58 PM Ticket #3552 (SciTE 3.7.3 bug: #Region & #EndRegion not working properly when it ...) closed by
- No Bug: This is a wrong use of AutoIt "syntax", and philosophies. Your region ranges are poorly defined. You can not, write anything between Switch and first Case, this just do not make any sense. I do not see any logic in this way of use Switch...Case...EndSwitch++#Region/#EndRegion Here are examples of proper way showing how to use #Region in this case: […] btw. Personally I prefer this kind of code descriptions: […]
- 6:00 PM Ticket #3554 (Ini functions should be documentated as containing limitations) updated by
-
Version changed
Automatic ticket cleanup. - 5:28 PM Ticket #3554 (Ini functions should be documentated as containing limitations) created by
- There's an old feature request #15 about fixing the various …[…]
- 3:52 PM Ticket #1814 (On InputBox, the language of buttons stays in English) updated by
- I've implemented it based on the latest AU3 source code I could find on GitHub, and following Jon's instructions for code submission. It takes the "OK"/"Cancel" button from Windows standard strings (same way Windows translates the buttons on message boxes). Here's a screen shot on a Portuguese machine: [[Image(...)]] Hope it's appreciated :)
May 25, 2017:
- 10:29 PM Ticket #3553 (_SQLite_Startup() - cannot use SQLite.dll without "_x64" suffix in 64 ...) updated by
- I get that but the point of adding the "conventional" _X64 suffix is to distinguish between 32- and 64-bit versions of the DLL, allowing them to coexist in the same directory. This makes building X86 or X64 applications completely transparent using the exact same source code.
- 6:46 PM Ticket #3553 (_SQLite_Startup() - cannot use SQLite.dll without "_x64" suffix in 64 ...) updated by
- my example is only example. It make possible to load "sqlite3.dll" without "_x64" suffix in 64 bit script. Original version error out not finding dll file in this case. Main point - make UDF use dll with was provided, and to not make any assumptions if provided file exist on provided full path.
- 10:01 AM Ticket #3553 (_SQLite_Startup() - cannot use SQLite.dll without "_x64" suffix in 64 ...) updated by
- _SQLite_Startup currently adds the _X64 suffix to the DLL name as needed. This way you can host both versions of the DLL in the same place and yet use the same source code for both X86 and X64. Changing the UDF as in your example would inconveniently require changing the DLL name in the code when compiling for the other architecture.
May 24, 2017:
- 7:00 PM Ticket #3553 (_SQLite_Startup() - cannot use SQLite.dll without "_x64" suffix in 64 ...) updated by
-
Version changed
Automatic ticket cleanup. - 6:12 PM Ticket #3553 (_SQLite_Startup() - cannot use SQLite.dll without "_x64" suffix in 64 ...) created by
- Now _SQLite_Startup() prohibit use dll without "_x64" in dll name in …
May 15, 2017:
- 9:14 AM Ticket #3112 (Function _Excel_RangeFind not working) updated by
- Replying to anonymous: > 14 months for now, and still version v3.3.14.2, and I have this error. Same here, this error is still present
May 9, 2017:
- 10:49 AM Ticket #3552 (SciTE 3.7.3 bug: #Region & #EndRegion not working properly when it ...) created by
- […] The option to collapse/uncollapse the whole region is not …
May 7, 2017:
- 8:34 PM Ticket #3551 (Simple Guidance For You In Sedumoxal.) closed by
- No Bug
- 12:50 PM Ticket #3551 (Simple Guidance For You In Sedumoxal.) created by
- The experience that dieting does not help and the feeling of impotence …
May 6, 2017:
- 6:00 PM Ticket #3550 (New Date And Time Function) updated by
-
Version changed
Automatic ticket cleanup. - 5:18 PM Ticket #3550 (New Date And Time Function) created by
- Can date-time conversion related function like strftime(format, …
- 1:17 PM Ticket #3549 (GUI Reference - OnEvent Mode: missing include in code sample) created by
- Section: GUI Reference Article: GUI OnEvent Mode Topic: Advanced …
May 2, 2017:
- 4:17 AM Ticket #3548 (How Bellavei Cream Is Going To Change Your health Strategies.) closed by
- Rejected
Apr 30, 2017:
- 9:06 PM Ticket #3547 (@ErrorStdOut or $ErrorStdOut for /ErrorStdOut) updated by
- ...and maybe a hash tag and/or Opt() for the suppression of the error GUI popup, as it would make sense, given the opportunity for error to be handled, if the given hash or Opt() is purposely declared in the script. Just as after time a #NoTrayIcon was accepted as OK to have.
- 8:49 PM Ticket #3547 (@ErrorStdOut or $ErrorStdOut for /ErrorStdOut) updated by
- Replying to mLipok: > Just as a reference/releated request: Just as a reference, yes. Just in case, I'll make an argument ( I'd really like this request implemented ) > https://www.autoitscript.com/trac/autoit/ticket/2488 what he asked for is nonsense in my view. OnAutoitExit() runs regardless. > https://www.autoitscript.com/trac/autoit/ticket/2919 what he asked for is already there. OK Exit 0, not OK Exit 1, that is the returned errorlevel We can use the rest of the Exit from 2 upwards for our own expected errors. @ExitCode should reflect that. @ExitMethod is as it should be. Therefore, these other 2 requests are not related to this one, other than is OnAutoitExit() I hope that the request for an @ErrorStdOut is considered.
- 8:50 AM Ticket #3548 (How Bellavei Cream Is Going To Change Your health Strategies.) created by
Apr 29, 2017:
- 7:29 PM Ticket #3547 (@ErrorStdOut or $ErrorStdOut for /ErrorStdOut) updated by
- Just as a reference/releated request: https://www.autoitscript.com/trac/autoit/ticket/2488 https://www.autoitscript.com/trac/autoit/ticket/2919
- 7:26 PM Ticket #2559 (Array incorrect number of subscripts) updated by
- " Would it be possible to add not only the Line number (which is esp. in large scripts quite hard to track because of comments etc.) but also the failing script line itself below the custom error message for Info? That would make it much easier to debug. " In compiled script there is only one line per entire script. In non compiled scirpt you should use @Jpm suggestion to click in Error Message in SciTE console. Also @guinness and mine sugestion to use Obfuscator , or currently rather Au3Stripper.exe is the solution you may use to fined where the issue in your scirpt is located. After this I think this request could be closed.
Note:
See TracTimeline
for information about the timeline view.
