AutoHotkey Community

It can be done with a simple one-liner. Why should the interpreter and documentation be inflated with these small but completely redundant functions? For matters of convenience, there are solutions that don't involve adding more redundant built-in functions, or waiting for someone else to do it for...

lexikos wrote: ↑

07 May 2024, 06:58

Code: Select all

FileOpen(path, "w").Write(text)

Thank you for your simple solution!
However, I advocate FileWrite for semantic consistency
- where there is FileRead and FileAppend, there should be FileWrite.
These three represent the basic operations we do with files.
It is not complete without any one.

In other languages, it's easy to write text to a file. But in AutoHotkey, there's no direct way. We have to write such functions by hand: FileWrite(text, path) { if FileExist(path) FileDelete(path) FileAppend(text, path) } AutoHotkey already has FileRead and FileAppend functions, and should have Fil...

You're right, but my code is still compilable and executable.
And at first glance, nothing seems wrong.
Should we report a syntax error?

Thank you for your insightful discussion! I understand.

I argue that Click() returns 5369740240 is a bug because of the documentation: If the flow of execution within a function reaches the function's closing brace prior to encountering a Return, the function ends and returns a blank value (empty string) to its caller. A blank value is also returned when...

I have tested many functions that don't have an return value in the documentation. They all return "", only Click is an magic number.

A similar problem is does not work as expected. It shows 0 once.
My version is v2.0.12.

My version is v2.0.12

In the document of Click (https://www.autohotkey.com/docs/v2/lib/Click.htm), there is no return value mentioned.
So Click should return empty string just like MouseClick, not a magic number 5369740240.

When we press MButton, it still throws an error unexpectedly.
For comparison, the following code are OK:

You're right. I see.

just me wrote: ↑

09 Apr 2024, 15:36

A_ScreenDPI
In a system with multiple display monitors, this value is the same for all monitors.

?

That's not a contradiction. A_ScreenDPI is the same for all monitors indeed.
My issue is that A_ScreenDPI should be updated when changing main monitor.

My version is 2.0.12.

My version is 2.0.12.

The key to reproduce this bug are the different zooms. If both are 200%, everything is OK.

The code for reproducibility is ~LButton:: ToolTip(A_ScreenWidth "," A_ScreenHeight "," A_ScreenDPI) I have two monitors. For monitor 1, the size is 2560×1600 and the zoom is 200%. For monitor 2, the size is 3840×2160 and the zoom is 175%. First, I set monitor 1 as the main monitor and start the scr...

when run ~!= Up::Ctrl the key history is A4 038 d 2.31 LAlt BB 00D d 0.14 = BB 00D h u 0.05 = 11 01D i u 0.00 Control A4 038 u 0.03 LAlt where the Control only be up and never be down. when run #HotIf 1 == 1 ~!= Up::Ctrl the key history is A4 038 d 1.84 LAlt BB 00D d 0.36 = BB 00D h u 0.06 = 11 01D ...

Alt and AltGr are not the same thing. AltGr is always on the right. What keyboard layout are you using? I'm in China and I use US keyboard layout, so I don't have the AltGr key. When executing !]:: Send("^{Insert}a") my AutoHotkey history is A5 138 d 3.50 RAlt DD 01B d 0.31 ] A2 01D i d 0.00 LContr...

I am dubious. The hotkey !]:: would not execute if you held AltGr, because the system treats AltGr as Alt+Ctrl. Pressing AltGr+] would have the same effect as without the script, which is not to select all. On the US International layout, it is to produce » . Even !»:: doesn't execute if I press Al...