File Explorer randomly pops up

[Monoxide3009]

Hello All,

I write some fairly basic code for my company that simulates a user to speed up production and reduce type errors. Generally I have our internal program and a com connected spreadsheet. Programs I write typically run fine, but once in a while the file explorer pops up to the general location (this PC on win10). I have yet to determine why this happens, as it may happen once every 400 iterations or so. The problem with this is that it throws off the current iteration and things have to be fixed then the script needs restarted. I often give these scripts to people that have little computer knowledge, so it causes huge problems.

Does anyone know why this might happen or even a way to resolve/bypass it? I cant really give code examples because it can potentially happen on any of the scripts I have written. These scripts would do basic things like taking data form a spreadsheet, entering it directly into a program (using send), copying/pasting into the program, and function key presses. I would think it might be a possible conflict of a windows hotkey to bring up the file explorer, but I would expect something like that to happen regularly if not 'every' time.

Any thoughts/help would be appreciated.

[mikeyww]

Pressing #e summons Explorer. Is it possible that you are inadvertently generating that sequence?

[Monoxide3009]

Pressing #e summons Explorer. Is it possible that you are inadvertently generating that sequence?

I don't believe so. I have never used # for anything. In fact, I had to look up what # actually does.

What I am doing is running the same functions over and over (hundreds of times). There is no real variance between the iterations. This is why it perplexes me that it happens so intermittently.

Are there any other functions using more common keys that could summon file explorer?

EDIT - I also double checked the current spreadsheet I am working with. There are no # in it to accidentally cause a #e to exist. The only thing I can think of (if this were the case) is that I am copying a string that has #e in it, but that also seems unlikely. Though I am not sure how I would feasibly test that. Even still, copying the string shouldn't trigger it.

[mikeyww]

If you are simply sending #e then it will activate Explorer. You could log everything that you are sending into a single text file and then examine it. I am not sure whether there are other sequences that might also do this. Yes, if you copy the string #e and then paste it into the wrong place, it could happen. Executing the following code will illustrate this.

Code: Select all

someText = #e
Clipboard := someText
Send %Clipboard%

Another easy way to test is to keep the following script running, and see whether the problem recurs.

Code: Select all

#e::Return

This will trap the key so that it does nothing.

[Monoxide3009]

Code: Select all

#e::Return

This will trap the key so that it does nothing.

Thanks. I will give it a try.

[mikeyww]

Actually, I tested and note that the Return statement will stop keys that you press but not necessarily what is sent through Send (for example). Thus, you might still need to examine text that is being sent.

If you are sending plain text, you could also precede it with {Text}, which prevents modifiers and other special syntax from being interpreted. It just sends plain text. I would recommend making that change. Example that fixes the problem is below.

Code: Select all

someText = #e
Clipboard := someText
Send {Text}%Clipboard%

[Monoxide3009]

I just came back to say that the #e:: return didnt work, but you beat me to it. It happened again today when I wasnt paying attention so I wasnt able to catch anything (though most everything I run is supposed to be set it and forget it so I 'never' catch it).

As far as sending {text} I could try that, though the problem is nothing I intentionally send would have #e in it, so -if- that is the problem it would be randomly copied text that then gets moved elsewhere. Going through and checking each variable that is pulled to the clipboard would be a pretty huge undertaking for me, unless there is a super easy way to blanket address that type of scenario.

[mikeyww]

Might be easy to debug: for all Send statements, also FileAppend them to a text file. Do that for a day. You could then open the file and search for "#". Just an idea.

This is just a trivia point that might not apply here: #InputLevel allows the user to adjust which "artificial" keyboard and mouse events are ignored by hotkeys and hotstrings. It is sometimes handy when there is a need for one hotkey to trigger another.

[gregster]

Going through and checking each variable that is pulled to the clipboard would be a pretty huge undertaking for me, unless there is a super easy way to blanket address that type of scenario.

OnClipboardChange and FileAppend