AutoHotkey Community

@Alguimist
I noticed a few errors in Windows.xml.
GWLP_WNDPROC (not GWL_WNDPROC)
GWLP_HINSTANCE
GWLP_HWNDPARENT
GWLP_USERDATA
GWLP_ID
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowlongptra#parameters

kczx3 wrote: ↑

30 Sep 2019, 07:30

Yes, though at times it doesn't seem quite as long. Actually, right now I have 11 tabs open in AutoGUI. They all show the same delay except for Installer.ahk (from AHK installation). That one for whatever reason seems to load quicker and almost normal loading time.

Some of the possible reasons for this delay in the exhibition of the Explorer menu:
• Most probably a security software is affecting the performance, considering that Installer.ahk is not affected by the issue.
• A shell context menu extension handler may (also) be responsible.
• AutoHotkey is not digitally signed and/or not installed on a trusted location and a software policy or security software is in effect. If this is the case, you may try one or more of the following steps as a way to diagnose the problem: 1) Check if some other unsigned software that is able to display the shell context menu, 7-Zip File Manager, for example, has a delay when showing the menu. 2) Create a temporary copy of an AHK script file in Program Files and test the Explorer menu for this file in AutoGUI. 3) Reinstall AHK with the option "UI Access" enabled. Then run AutoGUI with AutoHotkeyU64_UIA.exe, which is signed by a local certificate.
• The files are on a hard disk that wakes up of a power plan configuration that turns off the device after a few minutes (less likely).

As a side note, you may significantly speed up menu display in any window with these settings:
• Somewhere in the system settings, appearance and performance, disable the option "Fade or slide menus into view".
• Set MenuShowDelay to a lower value or 0 in the registry key HKEY_CURRENT_USER\Control Panel\Desktop.

@teadrinker: Thanks for reporting. I will soon add these constants to the database. You may notice in WinUser.h that both constants are defined as -4, but GWL_WNDPROC is undefined when targeting 64-bit Windows. The "P" variant was added to be in accordance with the name of GetWindowLongPtr. There are many constants with multiple names in the WinAPI headers. For example: IDI_INFORMATION and IDI_ASTERISK, MFT_RADIOCHECK and MF_USECHECKBITMAPS...

Alguimist wrote: ↑

11 Oct 2019, 04:36

Some of the possible reasons for this delay in the exhibition of the Explorer menu:

Looks like the biggest impact is due to the files being accessed and modified from my Google Drive folder on my PC. If I open one that is in Documents locally then it seems to be quicker for the most part. I will disable it for now. Survived fine without it before

Thanks for your detailed investigation!

@Alguimist if you're interested, here's a diff of my include\editor.ahk that has a few modifications. I had to zip it to upload it.

• SetEndAtLastLine(false)
• Sci[n].AssignCmdKey(SCK_HOME, SCI_VCHOMEWRAP) (instead of SCI_HOMEWRAP)
• Vertical line drawn at column 120
• selection is made partially transparent so syntax highlighting shows through
• adjusted matching brace styling
• several syntax elements made italicized
• indentation highlight guide
• modified auto insertion of quotes
• toggleComment puts a space after the semicolon (cuz it drives me crazy not having a small gap)

Thanks, @kczx3!

I'm about to release a new version of AutoGUI with some bug fixes, so I cannot add any of these changes right now, except Scintilla styling. After that, I will finish some details regarding theme customization with values loaded from XML files. You will no longer have to define selection alpha and italics directly in the script.

Some of the features you propose are a matter of preference ("ExtraScrolling", edge line, comment style and even SCI_VCHOMEWRAP), so they cannot be made default settings, but I will arrange for them to be in the settings file.

Version 2.6.2:
• Fixed: bug in the opening of "UTF-8 without BOM" files containing double-byte characters.
• Fixed: "highlight identical text" being affected by the search flags of Find/Replace.

Download

I've just downloaded Autogui v2.6.2 and when I open it, an error message appears as follows:
"AutoGUI has not been adapted to High-DPI display scaling. The program will exit."
How can I fix this?
I'm using the last version of AHK (1.1.32.00) on Windows 10, x64.

Try to comment these lines in AutoGUI.ahk:

Thank you, rommmcek!

is there a way to reconnect the designer?

@jappagtakhan:
Once the GUI Designer is disconnected from the current tab, the code becomes editable and there's no way to re-establish the connection of the GUI Designer with that document again. Every modification in the preview window causes the whole script to be completely generated up to the signature line.

nice bro!
thanks

Hi, I have created a GUI, but it is not finished yet. I saved the script for it. My problem now is that I cannot edit the GUI anymore. Any ideas how to make the old GUI accessible again?

_Rapid_ wrote: ↑

05 May 2020, 05:57

Hi, I have created a GUI, but it is not finished yet. I saved the script for it. My problem now is that I cannot edit the GUI anymore. Any ideas how to make the old GUI accessible again?

At the bottom of the file menu.
You can do it with import gui.
Shortcut You can do it with import Ctrl + I

Thanks for your answer. I thought that the GUI can be imported like this. The interesting thing is that I see the GUI, but the code is absolutely incomplete (only the code of the tab is shown, all other code is missing). My GUI consists of a tab control and some group boxes. Also the editing of the GUI doesn't work that well anymore, when I try to move an object on the GUI with the mouse, it moves below the cursor, i.e. the object to be moved is about 200px away from my mouse position.

Even if I add more GUI elements to the current GUI, the code does not update!

I made an example to show what I mean. So this is my test GUI that I havew created: If I want to import the existing GUI the remaining code is:
So as you can see most of the code was deleted by the import. The question is why?

_Rapid_ wrote: ↑

06 May 2020, 01:39

Thanks for your answer. I thought that the GUI can be imported like this. The interesting thing is that I see the GUI, but the code is absolutely incomplete (only the code of the tab is shown, all other code is missing). My GUI consists of a tab control and some group boxes. Also the editing of the GUI doesn't work that well anymore, when I try to move an object on the GUI with the mouse, it moves below the cursor, i.e. the object to be moved is about 200px away from my mouse position.

Even if I add more GUI elements to the current GUI, the code does not update!

I made an example to show what I mean. So this is my test GUI that I havew created:

Code: Select all

; Generated by AutoGUI 2.6.2
#SingleInstance Force
#NoEnv
SetWorkingDir %A_ScriptDir%
SetBatchLines -1

Gui Add, Tab3, x0 y0 w706 h779, Tab 1|Tab 2|Tab 3
Gui Tab, 1
Gui Add, Button, x48 y72 w155 h34, &OK
Gui Add, Button, x231 y234 w80 h24, &OK
Gui Tab, 2
Gui Add, CheckBox, x134 y124 w120 h23, CheckBox
Gui Add, CheckBox, x331 y332 w120 h23, CheckBox
Gui Tab, 3
Gui Add, Radio, x56 y96 w120 h23, Radio Button
Gui Add, Radio, x210 y427 w120 h23, Radio Button
Gui Tab

Gui Show, w689 h763, Window
Return

GuiEscape:
GuiClose:
    ExitApp

If I want to import the existing GUI the remaining code is:

Code: Select all

; Generated by AutoGUI 2.6.2
#SingleInstance Force
#NoEnv
SetWorkingDir %A_ScriptDir%
SetBatchLines -1

Gui Add, Tab3, x0 y0 w706 h779, Tab 1|Tab 2|Tab 3

Gui Show, w689 h763, Window
Return

GuiEscape:
GuiClose:
    ExitApp

So as you can see most of the code was deleted by the import. The question is why?

Yes, this method does not give great results. But in most cases this method is better than restarting.