LukeWCS

Hi Saw today that there is an update on this UDF, thanks TheXman. Tested with my mod manager, no problems found.

@Danp2 Thanks for the hint. It never occurred to me to look for it in "AutoIt Example Scripts" because "SciTe Jump" is part of the SciTe package and therefore part of the IDE. I've now implemented Jos' suggested change, which seems to me to be the better option for the future. @Musashi With what I've read from Jos now, I assume that this "internal" variable was an undocumented feature that was removed in 3.3.16.0. edit: Saw this morning that there is already a system here to mark threads as solved. Changes made accordingly.

@ad777 Thanks, problem solved. _SetVariables() Global Const $__sScriptDir = _GetInstalledSettingsDir() ; If AutoIt & SciTE are installed then use the application directory instead. Global $__WINVER _SciTE_Startup() But why does the missing variable declaration only appear in 3.3.16.0?

Hi Thanks to Jon and all who made the new version possible. I get the following error: --------------------------- AutoIt Error --------------------------- Line 2348  (File "C:\Program Files (x86)\AutoIt3\SciTE\SciTE Jump\SciTE Jump.au3"): Return $__WINVER >= 0x0600 Return ^ ERROR Error: Variable used without being declared. --------------------------- OK    --------------------------- I guess a new SciTe version is also necessary for the new AutoIt version?

Then it was a misunderstanding on my part, thanks for the clarification Jos. Perhaps that could also be due to the fact that I have to rely on a translator program. With some translation results, I sometimes don't know whether to laugh or cry. ^^ That means some details are lost. @Nine Now that I've understood the details, I'll change that for all of my current projects, because passing the function names as a string has always bothered me.

Thanks for the hint. It took me a few minutes to find it in Help. Even if I had remembered it, I would not have linked this section to the Factfinder problem. Which is probably related to the fact that the example shown there with "MsgBox" does not explain what this is good for. A more detailed example would actually have made sense here. I only know something similar from other languages as an "anonymous function". But this seems to be something else. I relate that to your two answers: From these two posts I can see that in this case you prefer the text variant plus au3stripper directive. And I wanted to know why you prefer that as I would rather prefer Nine's variant. In the help for the function that Factfinder uses it says: _Timer_SetTimer ($ hWnd [, $ iElapse = 250 [, $ sTimerFunc = "" [, $ iTimerID = -1]]]) And in the help for the function, which is about in my case, it says: GUISetOnEvent (specialID, "function" [, winhandle]) In both cases it is clearly a matter of a string that is to be passed in the parameter. So, of course, I assumed that this was the only variant. In the help, there is no indication that the function names can also be passed directly in the parameter, not just as text.

Very interesting. I didn't know that the function can be passed directly as a function name in this case. That is also one of the things that are not mentioned in the help. Or I haven't found it yet. ^^ @Jos You favor the function name as a string together with the definition of an au3stripper directive. Is there also a technical background for this, or is it personal preference? The background to my question: in one of my larger projects I have a large number of events and it would be very helpful for me if I could pass all the functions directly as function names for one simple reason: auto-completion. It is agony when I have to know exactly the function name that I want to call every time I define a new event. It would be much easier with autocomplete.

Yes, unfortunately. But it is also understandable. If I download a tool and upload it to VT for checking and then immediately get a dozen virus findings reported, I would think twice about whether I really want to start the EXE. Also because I'm an application programmer, not a security expert. That is why I have made several "assumptions" on this topic, which are simply based on my experience and research. I also used Inno Setup for our game project. Otherwise I have been using NSIS (Nullsoft Scriptable Install System) for a long time. But creating an installer just to get around the virus scanner problems is not ideal. Problems should be solved, not circumvented. Especially because one of the strengths of AI3 is its independence. Some of the suggestions made here would undermine this strength. Don't get me wrong, I'm interested in solutions. I can't answer by heart. But tonight I can look it up on the relevant PC. At least I still know which community the tool belongs to and where there were problems with the UDFs. And I also know for sure that this was not a standard UDF of the AI3 package, but either from here or from another AI3 forum. Since the tool definitely doesn't need a 64-bit environment, I didn't write any notes back then. At that time I had just tested it out of interest. Then there is another tool, which is no longer being developed anyhow. It's still used, but it has lost its relevance. I have now applied your tip and tested my current project with the 64 bit core. It all seems to be working. Then I will create the next update - in which more than 30KB of code has been added - with the 64 bit variant. According to the current VT report, there are "only" 12 false positives instead of 18. After all. But that's still way too much. ^^

I just tested it with the "Hello world" script as well as with one of my larger projects with about 4000 lines of code. The number of false positives is actually considerably smaller, even with my real project. What is that related to? However, I cannot apply this to every project. There are still 32Bit environments where my tools run. And I also have projects that have certain UDFs that don't work with 64Bit. And to make them compatible for 64Bit, I either don't have the time or the knowledge or both. I've just tested that too, at least in theory that would be an option. I say theoretically, because I use AI precisely because it is easy to use, because it has virtually no dependencies. If I now deliver the projects separately as a3x and with the interpreter, then I have to explain again how this is to be handled. That would be okay in special cases, but not with tools that are publicly available and downloaded by a correspondingly large number of users. One can of course consider what the lesser evil is. To lead endlessly long and endlessly tiring discussions about false positives with the users, or to explain to them how to get this "funny" a3x to work. ^^ As for the abbreviation: So when I'm with the neighbors (other communities) then I also use "AutoIt", because probably nobody knows what is meant by AI3 or associates something completely different with it. But when I'm practically at home (here in the forum), everyone should know what that means. As far as the actual problem is concerned: Of course you can "calm down" the AV scanner with one or the other trick. But from my point of view, the best option would still be if the AI3 programmer could decide for himself whether he wants to embed the script encrypted or unencrypted in the EXE. edit: And one of the options that I've been without for many years is UPX. From the standpoint of AV detection and transparency, UPX has long been a clear NoGo. In the case of most virus scanners, the presence of UPX alone causes a significant devaluation. From a technical point of view, UPX is also no longer relevant. The times when you had to fight for every KB are long gone. But UPX is only a tiny detail.

Since I created the Test EXE and opened this topic, I have updated the VT Report twice. This gives the following result: 12 false positives on first upload. (2020-10-03) 22 false positives at the first report update (a few days ago) 26 false positives in the second report update (2020-10-16) See link in the starting post. I suspect that the result depends primarily on 2 things: the actuality of the signature database of the individual AV scanners and the entropy of the encrypted script. The latter is probably also responsible, if the same source code is converted several times to an EXE, that the VT result can look different in each case. The result also shows that several AV scanners obviously use the same signature database. But that's more of a general problem and not a specific problem of AI. But it only exacerbates the problem because it increases the number of false positives over time.

Interesting, I have to take a look, thanks for the info. But if I redirect the output, the interactive possibilities of the output pane are lost. And I use this interactive function permanently. I also wrote my own version of ConsolWrite() for this purpose, which then outputs debug lines in the output pane, which I can double-click directly so that the editor jumps to the corresponding point in the code. Similar to Alt+D. In my version, however, the time including milliseconds is also output. As example: DebugWrite("context_openInExplorer") ConsoleWrite("context_openInExplorer") This code will write the follwoing to the output pane: So I can directly double-click on the line "Debug(930)...".

Yes. But my primary monitor is 24" 16:9 and my secondary is 19" 5:4. I want to use the primary for the code editor and my secondary for the output pane.

@mLipok I only see your posts now. Thanks for the tip, but the problem is that the output pane is on the right, but my secondary monitor is on the left. And I can't move the monitors, because it's not a normal table on which the monitors are, but a special computer table with appropriate spaces for certain peripherals.

This have nothing to do with my suggestion. I know this feature: "Save a copy of the Script_source in the EXE resources."

Hello everybody This is meant as a suggestion. I've been using AI since version 2 and use it especially for tasks where dependencies on runtime libraries would be a hindrance. For example for support tools. However, there is a big problem with the generated EXEs: false positives in a number of virus scanners. In my opinion, the cause of this is the fact that the scripts are encrypted and embedded in the generated EXE. Incidentally, this encryption also increases the entropy extremely, which is another cause of false detections. An effective way to increase the acceptance of AI programs and to reduce the problems with false postivies would be an option when creating the EXE that embeds the script unencrypted in the EXE. If that were optional, everyone could decide for themselves whether they want it or not. This would make it a lot easier for virus scanners as well as experienced programmers to analyze and classify an EXE generated by AI. Because the effectively executable part, i.e. the AI core, has long been established as trustworthy. If the actual program, i.e. the script, could also be read directly, this would ensure a high level of transparency and ultimately acceptance. Offering the source code does not solve the real problem. The following code serves as an example: MsgBox(0, "example", "Hello world") This example was converted to an EXE (without UPX) with AutoIt 3 and uploaded to VirusTotal. The report can be found under the following link. Please also have a look there in the comments. https://www.virustotal.com/gui/file/fe30f6bb70145512ce3fbfadabff7919fba084be6e22d7cc03e78445104a7151/detection edit 2020-10-03: Added example with link to a VT report edit 2020-10-04: Title formulated more precisely

@Jos All right, then I continue to use the version 2019.01.17.

@Jos Alright, release on standby. BTW, I did several tests and found no problems. All .json files are fine. I keep testing. A small problem, not a big deal: there is an undeclared variable $separator on lines 341 and 373.

Okay, then I will update now and test my program with the new JSON UDF version. Thanks again Jos.

@Jos Hmm.. but _Json(2019.07.15).zip is exactly the same as _Json(2019.01.17).zip. ^^

Yes, the dates are the same, but the json.au3 files are definitely different. I mean that post from you: This is not the same json.au3 as the one from the first post.

@Ward @Jos Hi As a feedback for both of you: On Nexus Mods I use in my program "QMod SAM" your JSON UDF and have there in the tab "description" a link to this topic set here. So also at this point: Thanks for this UDF! QMod SAM (see "Special Thanks:") P.S.: Jos, are your recent changes stable so far that I can take over your latest version? Currently I am using the official version of the startup post.

Ok, thanks for your answer Jos.

Hi Is it possible to "undock" the output pane so I can place it on a secondary screen? I want to have Scite maximized at my primary screen and the output pane maximized at my secondary screen. That would be very helpfully!

@Jos Yes, your workaround works as intended. Thank you. This is one of the most used functions for me. Just wondering that I'm the first who reported that. ^^

Hi Jos Thanks for the update. There is one problem: Alt+L doesn't work anymore. I have updated two AI3 dev environments on two Windows installations, one Win 7 and one win 10 and in both cases it's the same problem with Alt+L. If I press Alt+L then it opens only a very small windows but without any list, see attachment. I updated both environments from AI3 3.3.14.2 and Scite 3.7.3 to AI3 3.3.14.5 and Scite 4.1.0.