Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Old Topics related to the original "AutoGUI" ahk script editor.
User avatar
joedf
Posts: 8940
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by joedf » 07 Apr 2020, 09:35

Very nice work, it's "Font-astic" if I may say so myself. :+1:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]

User avatar
Alguimist
Posts: 428
Joined: 05 Oct 2015, 16:41
Contact:

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by Alguimist » 07 Apr 2020, 09:42

Hello, Boiler :D. I tested your script. It has a nice looking user interface, that resembles the ribbon concept, appropriate for this category of information handling (by the way: I have a ribbon designer under construction).

Some time ago I started to work on a partially similar feature in AutoGUI, intended only to provide the following functionality: reordering of controls and overview of control properties. I had to interrupt this task because, at that moment, it was a priority to remove the GUI designer from the code editor, making it a separate tool, which I have already accomplished in the version I'm current working on.

Suggestions: add a button to directly load another script from the main window. And a status bar that displays a brief description of the options. For example: when hovering the mouse over the checkbox "yp", the following text could be helpful in the status bar (or in a tooltip): "Applies the Y-coordinate of the previous control to the selected control". The button "Save" doesn't become enabled after reordering only. It should always be enabled. So, right after the groupbox "Update GUI script", or preferably at the opposite side of the bar, there should be the buttons "Open", "Save" and a checkbox for "AHK v2", since it may be trivial to convert the code to AHK v2 at this point, except that the original script may include libraries not yet compatible. More details: tray menu "Exit" icon uses an icon index which is not the same across Windows versions, which may cause the incorrect icon to be loaded or an error message to be displayed if the icon index goes beyond the valid range. Add the icon to the Icons folder or load it from its resource ID. It should also be noted that font can be applied to all controls in the preview window at once, generating a single line in the output code, as long as the Font Dialog has the preview window as target.

I'm now planning to make AutoGUI able to generate GUI code for other programming languages, all of which relying on absolute values, so I must adhere to some generic guidelines in the process of adapting AutoGUI to conform to this plan. It doesn't mean that the properties dialog, specific for AHK, could not be preserved, though, where options for relative coordinates may be implemented.

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 07 Apr 2020, 10:00

joedf wrote:
07 Apr 2020, 09:35
Very nice work, it's "Font-astic" if I may say so myself. :+1:
Thanks! I appreciate that! :)

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 07 Apr 2020, 10:33

Hey, Alguimist. Thank you for the detailed feedback! Very helpful! :thumbup:
Alguimist wrote: Suggestions: add a button to directly load another script from the main window.
That is a good suggestion. I'll add it, perhaps in a File menu along with other menu options.
Alguimist wrote: And a status bar that displays a brief description of the options. For example: when hovering the mouse over the checkbox "yp", the following text could be helpful in the status bar (or in a tooltip): "Applies the Y-coordinate of the previous control to the selected control".
A status bar is a good idea, but did you notice (since I see you said "or in a tooltip") that the checkboxes and buttons do have tooltips associated with them? Perhaps I need to reduce the hover delay so that they pop up more quickly. Do you think it is adequate with just the tooltips, especially if they pop up faster?
Alguimist wrote: The button "Save" doesn't become enabled after reordering only. It should always be enabled. So, right after the groupbox "Update GUI script", or preferably at the opposite side of the bar, there should be the buttons "Open", "Save" and a checkbox for "AHK v2", since it may be trivial to convert the code to AHK v2 at this point, except that the original script may include libraries not yet compatible.
OK. I'm not really up to speed on AHK v2 syntax yet since I've been waiting for it to be officially released. It doesn't seem like it's close to happening, so I guess now is as good a time as any to jump in.
Alguimist wrote: More details: tray menu "Exit" icon uses an icon index which is not the same across Windows versions, which may cause the incorrect icon to be loaded or an error message to be displayed if the icon index goes beyond the valid range. Add the icon to the Icons folder or load it from its resource ID.
I didn't realize that. I'll add the icon to the Icons folder.
Alguimist wrote: It should also be noted that font can be applied to all controls in the preview window at once, generating a single line in the output code, as long as the Font Dialog has the preview window as target.
Ah, I wasn't aware of that. That's useful to know. It seems that the "Fontalyzer" functionality is still useful in cases where a font applies to many but not all controls, though.
Alguimist wrote: I'm now planning to make AutoGUI able to generate GUI code for other programming languages, all of which relying on absolute values, so I must adhere to some generic guidelines in the process of adapting AutoGUI to conform to this plan. It doesn't mean that the properties dialog, specific for AHK, could not be preserved, though, where options for relative coordinates may be implemented.
Looking forward to seeing that. And if you end up adding options for relative coordinates directly into AutoGUI, I'm sure many including myself would find that valuable.

Thanks again for the input! :D

User avatar
haichen
Posts: 631
Joined: 09 Feb 2014, 08:24

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by haichen » 07 Apr 2020, 11:04

Alguimist wrote:
07 Apr 2020, 09:42
I'm now planning to make AutoGUI able to generate GUI code for other programming languages.
Very interesting. Do you plan to support Powershell?

User avatar
Alguimist
Posts: 428
Joined: 05 Oct 2015, 16:41
Contact:

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by Alguimist » 27 Apr 2020, 09:57

@boiler
"Do you think it is adequate with just the tooltips, especially if they pop up faster?"
Sorry, I didn't notice the tooltips. I don't know what is the proper guideline in this respect, so leave as it is.

@haichen
"Do you plan to support Powershell?"
I have not tested GUIs in PowerShell yet, I will check it out later. The other programming languages that I am considering to implement as generated code are: C (pure Win32 GUI and RC) and Pascal.

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 26 May 2020, 19:26

The first post has been updated with version 1.2 including the following changes, several as suggested by Alguimist:

- Added new Open File feature
- Welcome screen display now a selectable option
- Optionally remembers window position
- Added menu with File, Script, Options, Help
- Save As/Save always active allowing simple reordering to be saved
- Uses all local icons instead of calling them from the Windows files
- Button ribbon updated/improved

Regarding support for AHK v2 output, that is a planned future update.

Jstenoien
Posts: 1
Joined: 24 Mar 2020, 04:50
Contact:

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by Jstenoien » 11 Aug 2020, 10:22

Hello, trying to run Relativity.ahk and I'm getting this MsgBox:

---------------------------
Relativity.ahk
---------------------------
Error at line 362.

Line Text: Switch SubStr(target, 1, 1)
Error: This line does not contain a recognized action.

The program will exit.
---------------------------
OK
---------------------------

Deleted/redownloaded/etc and I'm getting the same error, any ideas what may be causing that?
Running AHK 1.1.30.00 64-bit

gregster
Posts: 8921
Joined: 30 Sep 2013, 06:48

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by gregster » 11 Aug 2020, 10:35

Jstenoien wrote:
11 Aug 2020, 10:22
Deleted/redownloaded/etc and I'm getting the same error, any ideas what may be causing that?
Running AHK 1.1.30.00 64-bit
Switch requires AHK v1.1.31+.

thebbandit
Posts: 45
Joined: 02 Jul 2019, 11:34

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by thebbandit » 13 Jun 2021, 08:48

very useful! I gave auto-GUI a shot a while back but found it was easier to just write the code manually because of the lack of relative positioning. And like you mentioned, making the conversion is a laborious process. Thank you for spending the time to code a solution to this!

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 13 Jun 2021, 09:09

Thanks for that feedback, @thebbandit!

thebbandit
Posts: 45
Joined: 02 Jul 2019, 11:34

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by thebbandit » 13 Jun 2021, 23:16

Found a simple issue to fix :)
When verifying the GUI file, it searches for "^; Generated by AutoGUI" when it should be "^; Generated by Auto-*GUI" so it can match with or without the dash

after using it a bit, very very useful!

Being able to re-order the elements and easily group them with sections makes things very straightforward, and the relative positioning is brilliant. Very complimentary script!

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 14 Jun 2021, 05:38

Thanks for letting me know that. Are you saying that Adventure refers to “Auto-GUI” instead of “AutoGUI” (as AutoGUI did) in the comment it produces? Or did AutoGUI sometimes use one or the other, possibly differing between versions? I haven’t installed and tried Adventure yet, but I will soon.

I may also change that line that verifies the GUI file to allow GUIs generated by SmartGUI Creator from SciTE4AutoHotkey since I believe I saw it generates GUI script files that are otherwise compatible with Relativity. After I confirm that, I’ll publish an update.

I’m glad you like the approach taken in Relativity. I considered different ways of doing it, and I thought this way was the most intuitive. Thank you!

thebbandit
Posts: 45
Joined: 02 Jul 2019, 11:34

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by thebbandit » 14 Jun 2021, 10:22

yep, at some point there was a dash added. I have the latest version from Adventure which comes with Auto-Gui 3.0.0.

That sounds like another good fit, verfying the stamp might be unnecessary. As long as it does not find a "bad" control then it should not matter if it has the line at the top right? :) :?:

and just to split hairs, when the error box appears. It has 3 possible reasons for being kicked back with an error, but it describes them all generally at once.

In this type of situation I would use a ternary to insert the correct error text into the msgbox.

Code: Select all

		MsgBox, 8257, Issue with source file, % (!goodSource?"The selected file does not appear be generated directly by AutoGUI's GUI Designer.`n":"") 
		. (!goodControlFound?"The file does not contain absolute-positioned controls.`n":"") 
		. (badControlFound?"The file contains relative-positioned controls.`n":"") 
		. "`nPlease select a valid input GUI script file."
Last edited by thebbandit on 14 Jun 2021, 10:45, edited 1 time in total.

User avatar
boiler
Posts: 16768
Joined: 21 Dec 2014, 02:44

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by boiler » 14 Jun 2021, 10:40

thebbandit wrote: That sounds like another good fit, verfying the stamp might be unnecessary. As long as it does not find a "bad" control then it should not matter if it has the line at the top right? :) :?:
I believe that verifying the stamp is important and valuable for a couple of reasons. For one, finding a "bad" control doesn't happen automatically, and I would either have to add a lot more checking of the controls (rather than assuming they conform to the expected format) or just allow errors to occur when it tries to act on them, which I think results in a much worse user experience. Also, whether the user purposely or inadvertently selects a regular script file instead of one in the expected format, I think it provides good feedback to tell them up front that they need to select the correct type of GUI script file. I wouldn't want them to find out just by things not working right, or even worse, let them possibly think that the application doesn't work well and abandon it.

thebbandit
Posts: 45
Joined: 02 Jul 2019, 11:34

Re: Relativity - Add relative positioning to controls in GUIs created by AutoGUI's GUI designer

Post by thebbandit » 14 Jun 2021, 10:57

boiler wrote:
14 Jun 2021, 10:40
thebbandit wrote: That sounds like another good fit, verfying the stamp might be unnecessary. As long as it does not find a "bad" control then it should not matter if it has the line at the top right? :) :?:
I believe that verifying the stamp is important and valuable for a couple of reasons. For one, finding a "bad" control doesn't happen automatically, and I would either have to add a lot more checking of the controls (rather than assuming they conform to the expected format) or just allow errors to occur when it tries to act on them, which I think results in a much worse user experience. Also, whether the user purposely or inadvertently selects a regular script file instead of one in the expected format, I think it provides good feedback to tell them up front that they need to select the correct type of GUI script file. I wouldn't want them to find out just by things not working right, or even worse, let them possibly think that the application doesn't work well and abandon it.
You make a very valid point! I edited my post with a little improvement to the error message, to give a better idea of what's wrong with the file if it has an issue.

Will definitely be using this alongside Auto-Gui to make my dialogue pop-ups from now on! :D Thank you @boiler and @Alguimist for these wonderful tools!

Post Reply

Return to “Old Topics”